doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc4518.txt b/doc/rfc/rfc4518.txt
new file mode 100644
index 0000000..f886bdf
--- /dev/null
+++ b/doc/rfc/rfc4518.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                        K. Zeilenga
+Request for Comments: 4518                           OpenLDAP Foundation
+Category: Standards Track                                      June 2006
+
+
+             Lightweight Directory Access Protocol (LDAP):
+                  Internationalized String Preparation
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The previous Lightweight Directory Access Protocol (LDAP) technical
+   specifications did not precisely define how character string matching
+   is to be performed.  This led to a number of usability and
+   interoperability problems.  This document defines string preparation
+   algorithms for character-based matching rules defined for use in
+   LDAP.
+
+1.  Introduction
+
+1.1.  Background
+
+   A Lightweight Directory Access Protocol (LDAP) [RFC4510] matching
+   rule [RFC4517] defines an algorithm for determining whether a
+   presented value matches an attribute value in accordance with the
+   criteria defined for the rule.  The proposition may be evaluated to
+   True, False, or Undefined.
+
+      True      - the attribute contains a matching value,
+
+      False     - the attribute contains no matching value,
+
+      Undefined - it cannot be determined whether the attribute contains
+                  a matching value.
+
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 1]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For instance, the caseIgnoreMatch matching rule may be used to
+   compare whether the commonName attribute contains a particular value
+   without regard for case and insignificant spaces.
+
+1.2.  X.500 String Matching Rules
+
+   "X.520: Selected attribute types" [X.520] provides (among other
+   things) value syntaxes and matching rules for comparing values
+   commonly used in the directory [X.500].  These specifications are
+   inadequate for strings composed of Unicode [Unicode] characters.
+
+   The caseIgnoreMatch matching rule [X.520], for example, is simply
+   defined as being a case-insensitive comparison where insignificant
+   spaces are ignored.  For printableString, there is only one space
+   character and case mapping is bijective, hence this definition is
+   sufficient.  However, for Unicode string types such as
+   universalString, this is not sufficient.  For example, a case-
+   insensitive matching implementation that folded lowercase characters
+   to uppercase would yield different results than an implementation
+   that used uppercase to lowercase folding.  Or one implementation may
+   view space as referring to only SPACE (U+0020), a second
+   implementation may view any character with the space separator (Zs)
+   property as a space, and another implementation may view any
+   character with the whitespace (WS) category as a space.
+
+   The lack of precise specification for character string matching has
+   led to significant interoperability problems.  When used in
+   certificate chain validation, security vulnerabilities can arise.  To
+   address these problems, this document defines precise algorithms for
+   preparing character strings for matching.
+
+1.3.  Relationship to "stringprep"
+
+   The character string preparation algorithms described in this
+   document are based upon the "stringprep" approach [RFC3454].  In
+   "stringprep", presented and stored values are first prepared for
+   comparison so that a character-by-character comparison yields the
+   "correct" result.
+
+   The approach used here is a refinement of the "stringprep" [RFC3454]
+   approach.  Each algorithm involves two additional preparation steps.
+
+   a) Prior to applying the Unicode string preparation steps outlined in
+      "stringprep", the string is transcoded to Unicode.
+
+   b) After applying the Unicode string preparation steps outlined in
+      "stringprep", the string is modified to appropriately handle
+      characters insignificant to the matching rule.
+
+
+
+Zeilenga                    Standards Track                     [Page 2]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   Hence, preparation of character strings for X.500 [X.500] matching
+   [X.501] involves the following steps:
+
+      1) Transcode
+      2) Map
+      3) Normalize
+      4) Prohibit
+      5) Check Bidi (Bidirectional)
+      6) Insignificant Character Handling
+
+   These steps are described in Section 2.
+
+   It is noted that while various tables of Unicode characters included
+   or referenced by this specification are derived from Unicode
+   [Unicode] data, these tables are to be considered definitive for the
+   purpose of implementing this specification.
+
+1.4.  Relationship to the LDAP Technical Specification
+
+   This document is an integral part of the LDAP technical specification
+   [RFC4510], which obsoletes the previously defined LDAP technical
+   specification [RFC3377] in its entirety.
+
+   This document details new LDAP internationalized character string
+   preparation algorithms used by [RFC4517] and possible other technical
+   specifications defining LDAP syntaxes and/or matching rules.
+
+1.5.  Relationship to X.500
+
+   LDAP is defined [RFC4510] in X.500 terms as an X.500 access
+   mechanism.  As such, there is a strong desire for alignment between
+   LDAP and X.500 syntax and semantics.  The character string
+   preparation algorithms described in this document are based upon
+   "Internationalized String Matching Rules for X.500" [XMATCH] proposal
+   to ITU/ISO Joint Study Group 2.
+
+1.6.  Conventions and Terms
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14 [RFC2119].
+
+   Character names in this document use the notation for code points and
+   names from the Unicode Standard [Unicode].  For example, the letter
+   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
+   In the lists of mappings and the prohibited characters, the "U+" is
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 3]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   left off to make the lists easier to read.  The comments for
+   character ranges are shown in square brackets (such as "[CONTROL
+   CHARACTERS]") and do not come from the standard.
+
+   Note: a glossary of terms used in Unicode can be found in [Glossary].
+   Information on the Unicode character encoding model can be found in
+   [CharModel].
+
+   The term "combining mark", as used in this specification, refers to
+   any Unicode [Unicode] code point that has a mark property (Mn, Mc,
+   Me).  Appendix A provides a definitive list of combining marks.
+
+2.  String Preparation
+
+   The following six-step process SHALL be applied to each presented and
+   attribute value in preparation for character string matching rule
+   evaluation.
+
+      1) Transcode
+      2) Map
+      3) Normalize
+      4) Prohibit
+      5) Check bidi
+      6) Insignificant Character Handling
+
+   Failure in any step causes the assertion to evaluate to Undefined.
+
+   The character repertoire of this process is Unicode 3.2 [Unicode].
+
+   Note that this six-step process specification is intended to describe
+   expected matching behavior.  Implementations are free to use
+   alternative processes so long as the matching rule evaluation
+   behavior provided is consistent with the behavior described by this
+   specification.
+
+2.1.  Transcode
+
+   Each non-Unicode string value is transcoded to Unicode.
+
+   PrintableString [X.680] values are transcoded directly to Unicode.
+
+   UniversalString, UTF8String, and bmpString [X.680] values need not be
+   transcoded as they are Unicode-based strings (in the case of
+   bmpString, a subset of Unicode).
+
+   TeletexString [X.680] values are transcoded to Unicode.  As there is
+   no standard for mapping TeletexString values to Unicode, the mapping
+   is left a local matter.
+
+
+
+Zeilenga                    Standards Track                     [Page 4]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For these and other reasons, use of TeletexString is NOT RECOMMENDED.
+
+   The output is the transcoded string.
+
+2.2.  Map
+
+   SOFT HYPHEN (U+00AD) and MONGOLIAN TODO SOFT HYPHEN (U+1806) code
+   points are mapped to nothing.  COMBINING GRAPHEME JOINER (U+034F) and
+   VARIATION SELECTORs (U+180B-180D, FF00-FE0F) code points are also
+   mapped to nothing.  The OBJECT REPLACEMENT CHARACTER (U+FFFC) is
+   mapped to nothing.
+
+   CHARACTER TABULATION (U+0009), LINE FEED (LF) (U+000A), LINE
+   TABULATION (U+000B), FORM FEED (FF) (U+000C), CARRIAGE RETURN (CR)
+   (U+000D), and NEXT LINE (NEL) (U+0085) are mapped to SPACE (U+0020).
+
+   All other control code (e.g., Cc) points or code points with a
+   control function (e.g., Cf) are mapped to nothing.  The following is
+   a complete list of these code points: U+0000-0008, 000E-001F, 007F-
+   0084, 0086-009F, 06DD, 070F, 180E, 200C-200F, 202A-202E, 2060-2063,
+   206A-206F, FEFF, FFF9-FFFB, 1D173-1D17A, E0001, E0020-E007F.
+
+   ZERO WIDTH SPACE (U+200B) is mapped to nothing.  All other code
+   points with Separator (space, line, or paragraph) property (e.g., Zs,
+   Zl, or Zp) are mapped to SPACE (U+0020).  The following is a complete
+   list of these code points: U+0020, 00A0, 1680, 2000-200A, 2028-2029,
+   202F, 205F, 3000.
+
+   For case ignore, numeric, and stored prefix string matching rules,
+   characters are case folded per B.2 of [RFC3454].
+
+   The output is the mapped string.
+
+2.3.  Normalize
+
+   The input string is to be normalized to Unicode Form KC
+   (compatibility composed) as described in [UAX15].  The output is the
+   normalized string.
+
+2.4.  Prohibit
+
+   All Unassigned code points are prohibited.  Unassigned code points
+   are listed in Table A.1 of [RFC3454].
+
+   Characters that, per Section 5.8 of [RFC3454], change display
+   properties or are deprecated are prohibited.  These characters are
+   listed in Table C.8 of [RFC3454].
+
+
+
+
+Zeilenga                    Standards Track                     [Page 5]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   Private Use code points are prohibited.  These characters are listed
+   in Table C.3 of [RFC3454].
+
+   All non-character code points are prohibited.  These code points are
+   listed in Table C.4 of [RFC3454].
+
+   Surrogate codes are prohibited.  These characters are listed in Table
+   C.5 of [RFC3454].
+
+   The REPLACEMENT CHARACTER (U+FFFD) code point is prohibited.
+
+   The step fails if the input string contains any prohibited code
+   point.  Otherwise, the output is the input string.
+
+2.5.  Check bidi
+
+   Bidirectional characters are ignored.
+
+2.6.  Insignificant Character Handling
+
+   In this step, the string is modified to ensure proper handling of
+   characters insignificant to the matching rule.  This modification
+   differs from matching rule to matching rule.
+
+   Section 2.6.1 applies to case ignore and exact string matching.
+   Section 2.6.2 applies to numericString matching.
+   Section 2.6.3 applies to telephoneNumber matching.
+
+2.6.1.  Insignificant Space Handling
+
+   For the purposes of this section, a space is defined to be the SPACE
+   (U+0020) code point followed by no combining marks.
+
+       NOTE - The previous steps ensure that the string cannot contain
+              any code points in the separator class, other than SPACE
+              (U+0020).
+
+   For input strings that are attribute values or non-substring
+   assertion values:  If the input string contains no non-space
+   character, then the output is exactly two SPACEs.  Otherwise (the
+   input string contains at least one non-space character), the string
+   is modified such that the string starts with exactly one space
+   character, ends with exactly one SPACE character, and any inner
+   (non-empty) sequence of space characters is replaced with exactly two
+   SPACE characters.  For instance, the input strings
+   "foo<SPACE>bar<SPACE><SPACE>", result in the output
+   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".
+
+
+
+
+Zeilenga                    Standards Track                     [Page 6]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   For input strings that are substring assertion values: If the string
+   being prepared contains no non-space characters, then the output
+   string is exactly one SPACE.  Otherwise, the following steps are
+   taken:
+
+   -  If the input string is an initial substring, it is modified to
+      start with exactly one SPACE character;
+
+   -  If the input string is an initial or an any substring that ends in
+      one or more space characters, it is modified to end with exactly
+      one SPACE character;
+
+   -  If the input string is an any or a final substring that starts in
+      one or more space characters, it is modified to start with exactly
+      one SPACE character; and
+
+   -  If the input string is a final substring, it is modified to end
+      with exactly one SPACE character.
+
+   For instance, for the input string "foo<SPACE>bar<SPACE><SPACE>" as
+   an initial substring, the output would be
+   "<SPACE>foo<SPACE><SPACE>bar<SPACE>".  As an any or final substring,
+   the same input would result in "foo<SPACE>bar<SPACE>".
+
+   Appendix B discusses the rationale for the behavior.
+
+2.6.2.  numericString Insignificant Character Handling
+
+   For the purposes of this section, a space is defined to be the SPACE
+   (U+0020) code point followed by no combining marks.
+
+   All spaces are regarded as insignificant and are to be removed.
+
+   For example, removal of spaces from the Form KC string:
+       "<SPACE><SPACE>123<SPACE><SPACE>456<SPACE><SPACE>"
+   would result in the output string:
+       "123456"
+   and the Form KC string:
+       "<SPACE><SPACE><SPACE>"
+   would result in the output string:
+       "" (an empty string).
+
+2.6.3.  telephoneNumber Insignificant Character Handling
+
+   For the purposes of this section, a hyphen is defined to be a
+   HYPHEN-MINUS (U+002D), ARMENIAN HYPHEN (U+058A), HYPHEN (U+2010),
+   NON-BREAKING HYPHEN (U+2011), MINUS SIGN (U+2212), SMALL HYPHEN-MINUS
+   (U+FE63), or FULLWIDTH HYPHEN-MINUS (U+FF0D) code point followed by
+
+
+
+Zeilenga                    Standards Track                     [Page 7]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   no combining marks and a space is defined to be the SPACE (U+0020)
+   code point followed by no combining marks.
+
+   All hyphens and spaces are considered insignificant and are to be
+   removed.
+
+   For example, removal of hyphens and spaces from the Form KC string:
+       "<SPACE><HYPHEN>123<SPACE><SPACE>456<SPACE><HYPHEN>"
+   would result in the output string:
+       "123456"
+   and the Form KC string:
+       "<HYPHEN><HYPHEN><HYPHEN>"
+   would result in the (empty) output string:
+       "".
+
+3.  Security Considerations
+
+   "Preparation of Internationalized Strings ("stringprep")" [RFC3454]
+   security considerations generally apply to the algorithms described
+   here.
+
+4.  Acknowledgements
+
+   The approach used in this document is based upon design principles
+   and algorithms described in "Preparation of Internationalized Strings
+   ('stringprep')" [RFC3454] by Paul Hoffman and Marc Blanchet.  Some
+   additional guidance was drawn from Unicode Technical Standards,
+   Technical Reports, and Notes.
+
+   This document is a product of the IETF LDAP Revision (LDAPBIS)
+   Working Group.
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3454]     Hoffman, P. and M. Blanchet, "Preparation of
+                 Internationalized Strings ("stringprep")", RFC 3454,
+                 December 2002.
+
+   [RFC4510]     Zeilenga, K., "Lightweight Directory Access Protocol
+                 (LDAP): Technical Specification Road Map", RFC 4510,
+                 June 2006.
+
+
+
+
+
+Zeilenga                    Standards Track                     [Page 8]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
+                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
+                 2006.
+
+   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
+                 3.2.0" is defined by "The Unicode Standard, Version
+                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
+                 61633-5), as amended by the "Unicode Standard Annex
+                 #27: Unicode 3.1"
+                 (http://www.unicode.org/reports/tr27/) and by the
+                 "Unicode Standard Annex #28: Unicode 3.2"
+                 (http://www.unicode.org/reports/tr28/).
+
+   [UAX15]       Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+                 Unicode Normalization Forms, Version 3.2.0".
+                 <http://www.unicode.org/unicode/reports/tr15/tr15-
+                 22.html>, March 2002.
+
+   [X.680]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "Abstract
+                 Syntax Notation One (ASN.1) - Specification of Basic
+                 Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
+
+5.2.  Informative References
+
+   [X.500]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Overview of concepts, models and
+                 services," X.500(1993) (also ISO/IEC 9594-1:1994).
+
+   [X.501]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
+                 2:1994).
+
+   [X.520]       International Telecommunication Union -
+                 Telecommunication Standardization Sector, "The
+                 Directory: Selected Attribute Types", X.520(1993) (also
+                 ISO/IEC 9594-6:1994).
+
+   [Glossary]    The Unicode Consortium, "Unicode Glossary",
+                 <http://www.unicode.org/glossary/>.
+
+   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
+                 #17, Character Encoding Model", UTR17,
+                 <http://www.unicode.org/unicode/reports/tr17/>, August
+                 2000.
+
+
+
+
+Zeilenga                    Standards Track                     [Page 9]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   [RFC3377]     Hodges, J. and R. Morgan, "Lightweight Directory Access
+                 Protocol (v3): Technical Specification", RFC 3377,
+                 September 2002.
+
+   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
+                 Access Protocol (LDAP): String Representation of Search
+                 Filters", RFC 4515, June 2006.
+
+   [XMATCH]      Zeilenga, K., "Internationalized String Matching Rules
+                 for X.500", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 10]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+Appendix A.  Combining Marks
+
+   This appendix is normative.
+
+   This table was derived from Unicode [Unicode] data files; it lists
+   all code points with the Mn, Mc, or Me properties.  This table is to
+   be considered definitive for the purposes of implementation of this
+   specification.
+
+         0300-034F 0360-036F 0483-0486 0488-0489 0591-05A1
+         05A3-05B9 05BB-05BC 05BF 05C1-05C2 05C4 064B-0655 0670
+         06D6-06DC 06DE-06E4 06E7-06E8 06EA-06ED 0711 0730-074A
+         07A6-07B0 0901-0903 093C 093E-094F 0951-0954 0962-0963
+         0981-0983 09BC 09BE-09C4 09C7-09C8 09CB-09CD 09D7
+         09E2-09E3 0A02 0A3C 0A3E-0A42 0A47-0A48 0A4B-0A4D
+         0A70-0A71 0A81-0A83 0ABC 0ABE-0AC5 0AC7-0AC9 0ACB-0ACD
+         0B01-0B03 0B3C 0B3E-0B43 0B47-0B48 0B4B-0B4D 0B56-0B57
+         0B82 0BBE-0BC2 0BC6-0BC8 0BCA-0BCD 0BD7 0C01-0C03
+         0C3E-0C44 0C46-0C48 0C4A-0C4D 0C55-0C56 0C82-0C83
+         0CBE-0CC4 0CC6-0CC8 0CCA-0CCD 0CD5-0CD6 0D02-0D03
+         0D3E-0D43 0D46-0D48 0D4A-0D4D 0D57 0D82-0D83 0DCA
+         0DCF-0DD4 0DD6 0DD8-0DDF 0DF2-0DF3 0E31 0E34-0E3A
+         0E47-0E4E 0EB1 0EB4-0EB9 0EBB-0EBC 0EC8-0ECD 0F18-0F19
+         0F35 0F37 0F39 0F3E-0F3F 0F71-0F84 0F86-0F87 0F90-0F97
+         0F99-0FBC 0FC6 102C-1032 1036-1039 1056-1059 1712-1714
+         1732-1734 1752-1753 1772-1773 17B4-17D3 180B-180D 18A9
+         20D0-20EA 302A-302F 3099-309A FB1E FE00-FE0F FE20-FE23
+         1D165-1D169 1D16D-1D172 1D17B-1D182 1D185-1D18B
+         1D1AA-1D1AD
+
+Appendix B.  Substrings Matching
+
+   This appendix is non-normative.
+
+   In the absence of substrings matching, the insignificant space
+   handling for case ignore/exact matching could be simplified.
+   Specifically, the handling could be to require that all sequences of
+   one or more spaces be replaced with one space and, if the string
+   contains non-space characters, removal of all leading spaces and
+   trailing spaces.
+
+   In the presence of substrings matching, this simplified space
+   handling would lead to unexpected and undesirable matching behavior.
+   For instance:
+
+   1) (CN=foo\20*\20bar) would match the CN value "foobar";
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 11]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   2) (CN=*\20foobar\20*) would match "foobar", but
+      (CN=*\20*foobar*\20*) would not.
+
+   Note to readers not familiar with LDAP substrings matching: the LDAP
+   filter [RFC4515] assertion (CN=A*B*C) says to "match any value (of
+   the attribute CN) that begins with A, contains B after A, ends with C
+   where C is also after B."
+
+   The first case illustrates that this simplified space handling would
+   cause leading and trailing spaces in substrings of the string to be
+   regarded as insignificant.  However, only leading and trailing (as
+   well as multiple consecutive spaces) of the string (as a whole) are
+   insignificant.
+
+   The second case illustrates that this simplified space handling would
+   cause sub-partitioning failures.  That is, if a prepared any
+   substring matches a partition of the attribute value, then an
+   assertion constructed by subdividing that substring into multiple
+   substrings should also match.
+
+   In designing an appropriate approach for space handling for
+   substrings matching, one must study key aspects of X.500 case
+   exact/ignore matching.  X.520 [X.520] says:
+
+      The [substrings] rule returns TRUE if there is a partitioning of
+      the attribute value (into portions) such that:
+
+         -  the specified substrings (initial, any, final) match
+            different portions of the value in the order of the strings
+            sequence;
+
+         -  initial, if present, matches the first portion of the value;
+
+         -  final, if present, matches the last portion of the value;
+
+         -  any, if present, matches some arbitrary portion of the
+            value.
+
+   That is, the substrings assertion (CN=foo\20*\20bar) matches the
+   attribute value "foo<SPACE><SPACE>bar" as the value can be
+   partitioned into the portions "foo<SPACE>" and "<SPACE>bar" meeting
+   the above requirements.
+
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 12]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+   X.520 also says:
+
+      [T]he following spaces are regarded as not significant:
+
+         -  leading spaces (i.e., those preceding the first character
+            that is not a space);
+
+         -  trailing spaces (i.e., those following the last character
+            that is not a space);
+
+         -  multiple consecutive spaces (these are taken as equivalent
+            to a single space character).
+
+   This statement applies to the assertion values and attribute values
+   as whole strings, and not individually to substrings of an assertion
+   value.  In particular, the statements should be taken to mean that if
+   an assertion value and attribute value match without any
+   consideration to insignificant characters, then that assertion value
+   should also match any attribute value that differs only by inclusion
+   nor removal of insignificant characters.
+
+   Hence the assertion (CN=foo\20*\20bar) matches
+   "foo<SPACE><SPACE><SPACE>bar" and "foo<SPACE>bar" as these values
+   only differ from "foo<SPACE><SPACE>bar" by the inclusion or removal
+   of insignificant spaces.
+
+   Astute readers of this text will also note that there are special
+   cases where the specified space handling does not ignore spaces that
+   could be considered insignificant.  For instance, the assertion
+   (CN=\20*\20*\20) does not match "<SPACE><SPACE><SPACE>"
+   (insignificant spaces present in value) or " " (insignificant spaces
+   not present in value).  However, as these cases have no practical
+   application that cannot be met by simple assertions, e.g., (cn=\20),
+   and this minor anomaly can only be fully addressed by a preparation
+   algorithm to be used in conjunction with character-by-character
+   partitioning and matching, the anomaly is considered acceptable.
+
+Author's Address
+
+   Kurt D. Zeilenga
+   OpenLDAP Foundation
+
+   EMail: Kurt@OpenLDAP.org
+
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 13]
+
+RFC 4518       LDAP: Internationalized String Preparation      June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Zeilenga                    Standards Track                    [Page 14]
+