[Pkg-samba-maint] r3219 - in branches/samba/upstream-3.5/source4: heimdal/lib/wind ldap_server/devdocs

bubulle at alioth.debian.org bubulle at alioth.debian.org
Tue Jan 12 21:04:45 UTC 2010


Author: bubulle
Date: 2010-01-12 21:04:43 +0000 (Tue, 12 Jan 2010)
New Revision: 3219

Removed:
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3454.txt
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3490.txt
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3491.txt
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3492.txt
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4013.txt
   branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4518.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2307.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2696.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2849.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2891.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc3296.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4510.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4511.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4512.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4513.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4514.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4515.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4516.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4517.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4518.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4519.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4520.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4521.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4522.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4523.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4524.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4525.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4526.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4527.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4528.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4529.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4530.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4531.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4532.txt
   branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4533.txt
Log:
Load samba-3.5.0rc1 into branches/samba/upstream-3.5.

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3454.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3454.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3454.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,5099 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3454                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                           December 2002
-
-
-        Preparation of Internationalized Strings ("stringprep")
-
-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 (2002).  All Rights Reserved.
-
-Abstract
-
-   This document describes a framework for preparing Unicode text
-   strings in order to increase the likelihood that string input and
-   string comparison work in ways that make sense for typical users
-   throughout the world.  The stringprep protocol is useful for protocol
-   identifier values, company and personal names, internationalized
-   domain names, and other text strings.
-
-   This document does not specify how protocols should prepare text
-   strings.  Protocols must create profiles of stringprep in order to
-   fully specify the processing options.
-
-Table of Contents
-
-   1. Introduction....................................................3
-     1.1 Terminology..................................................4
-     1.2 Using stringprep in protocols................................4
-   2. Preparation Overview............................................6
-   3. Mapping.........................................................7
-     3.1 Commonly mapped to nothing...................................7
-     3.2 Case folding.................................................8
-   4. Normalization...................................................9
-   5. Prohibited Output..............................................10
-     5.1 Space characters............................................11
-     5.2 Control characters..........................................11
-     5.3 Private use.................................................12
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-     5.4 Non-character code points...................................12
-     5.5 Surrogate codes.............................................13
-     5.6 Inappropriate for plain text................................13
-     5.7 Inappropriate for canonical representation..................13
-     5.8 Change display properties or deprecated.....................13
-     5.9 Tagging characters..........................................14
-   6. Bidirectional Characters.......................................14
-   7. Unassigned Code Points in Stringprep Profiles..................15
-     7.1 Categories of code points...................................16
-     7.2 Reasons for difference between stored strings and queries...17
-     7.3 Versions of applications and stored strings.................18
-   8. References.....................................................19
-     8.1 Normative references........................................19
-     8.2 Informative references......................................19
-   9. Security Considerations........................................19
-     9.1 Stringprep-specific security considerations.................19
-     9.2 Generic Unicode security considerations.....................20
-   10. IANA Considerations...........................................21
-   11. Acknowledgements..............................................22
-   A. Unicode repertoires............................................23
-     A.1 Unassigned code points in Unicode 3.2.......................23
-   B. Mapping Tables.................................................31
-     B.1 Commonly mapped to nothing..................................31
-     B.2 Mapping for case-folding used with NFKC.....................32
-     B.3 Mapping for case-folding used with no normalization.........61
-   C. Prohibition tables.............................................78
-     C.1 Space characters............................................78
-       C.1.1 ASCII space characters..................................78
-       C.1.2 Non-ASCII space characters..............................79
-     C.2 Control characters..........................................79
-       C.2.1 ASCII control characters................................79
-       C.2.2 Non-ASCII control characters............................79
-     C.3 Private use.................................................80
-     C.4 Non-character code points...................................80
-     C.5 Surrogate codes.............................................80
-     C.6 Inappropriate for plain text................................80
-     C.7 Inappropriate for canonical representation..................81
-     C.8 Change display properties or are deprecated.................81
-     C.9 Tagging characters..........................................81
-   D. Bidirectional tables...........................................81
-     D.1 Characters with bidirectional property "R" or "AL"..........81
-     D.2 Characters with bidirectional property "L"..................82
-   Authors' Addresses................................................90
-   Full Copyright Statement..........................................91
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-1. Introduction
-
-   Application programs can display text in many different ways.
-   Similarly, a user can enter text into an application program in a
-   myriad of fashions.  Internationalized text (that is, text that is
-   not restricted to the narrow set of US-ASCII characters) has many
-   input and display behaviors that make it difficult to compare text in
-   a consistent fashion.
-
-   This document specifies a framework of processing rules for Unicode
-   text.  Other protocols can create profiles of these rules; these
-   profiles will allow users to enter internationalized text strings in
-   applications and have the highest chance of getting the content of
-   the strings correct.  In this case, "correct" means that if two
-   different people enter what they think is the same string into two
-   different input mechanisms, the strings should match on a character-
-   by-character basis.
-
-   This framework does not describe how data is transcoded from other
-   character sets into Unicode.  In systems that uses non-Unicode
-   character sets, the transcoding algorithm is a critical part of
-   enabling secure and "correct" operation of internationalized text
-   strings.
-
-   In addition to helping string matching, profiles of stringprep can
-   also exclude characters that should not normally appear in text that
-   is used in the protocol.  The profile can prevent such characters by
-   changing the characters to be excluded to other characters, by
-   removing those characters, or by causing an error if the characters
-   would appear in the output.  For example, because the backspace
-   character can cause unpredictable display results, a profile can
-   specify that a string containing a backspace character would cause an
-   error.
-
-   A profile of stringprep converts a single string of input characters
-   to a string of output characters, or returns an error if the output
-   string would contain a prohibited character.  Stringprep profiles
-   cannot both emit a string and return an error.
-
-   Stringprep profiles cannot account for all of the variations that
-   might occur or that a user might expect.  In particular, a profile
-   will not be able to account for choice of spellings in all languages
-   for all scripts because the number of alternative spellings of words
-   and phrases is immense.  Users would probably expect all spelling
-   equivalents to be made equivalent, or none of them to be.  Examples
-   of spelling equivalents include "theater" vs. "theatre", and
-   "hemoglobin" vs. "h<U+00E6>moglobin" in American vs. British English.
-   Other examples are simplified Chinese spellings of names (for
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   example,"<U+7EDF><U+4E00><U+7801>") vs. the equivalent traditional
-   Chinese spelling (for example, "<U+7D71><U+4E00><U+78BC>").
-   Language-specific equivalences such as "Aepfel" vs. "<U+00C4>pfel",
-   which are sometimes considered equivalent in German, may not be
-   considered equivalent in other languages.
-
-1.1 Terminology
-
-   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, RFC 2119
-   [RFC2119].
-
-   Note: A glossary of terms used in Unicode and ISO/IEC 10646 can be
-   found in [Glossary].  Information on the 10646/Unicode character
-   encoding model can be found in [CharModel].
-
-   Character names in this document use the notation for code points and
-   names from the Unicode Standard [Unicode3.2] and ISO/IEC 10646
-   [ISO10646].  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 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
-   standards.
-
-1.2 Using stringprep in protocols
-
-   The stringprep protocol does not stand on its own; it has to be used
-   by other protocols at precisely-defined places in those other
-   protocols.  For example, a protocol that has strings that come from
-   the entire ISO/IEC 10646 [ISO10646] character repertoire might
-   specify that only strings that have been processed with a particular
-   profile of stringprep are legal.  Another example would be a protocol
-   that does string comparison as a step in the protocol; that protocol
-   might specify that such comparison is done only after processing the
-   strings with a specific profile of stringprep.
-
-   When two protocols that use different profiles of stringprep
-   interoperate, there may be conflict about what characters are and are
-   not allowed in the final string.  Thus, protocol developers should
-   strongly consider re-using existing profiles of stringprep.
-
-   When developers wish to allow users as wide of a range of characters
-   as possible in input text strings, they should, where possible, cause
-   stringprep to convert characters from the input string to a canonical
-   form instead of prohibiting them.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   Although it would be easy to use the stringprep process to "correct"
-   perceived mis-features or bugs in the current character standards,
-   stringprep profiles SHOULD NOT do so.
-
-   A profile of stringprep can create tables different from those in the
-   appendixes of this document, but it will be an exception when they
-   do.  The intention of stringprep is to define the tables and have the
-   profiles of stringprep select among those defined tables.
-
-   A profile of stringprep MUST include all of the following:
-
-   - The intended applicability of the profile
-
-   - The character repertoire that is the input and output to stringprep
-     (which is Unicode 3.2 for this version of stringprep)
-
-   - The mapping tables from this document used (as described in section
-     3)
-
-   - Any additional mapping tables specific to the profile
-
-   - The Unicode normalization used, if any (as described in section 4)
-
-   - The tables from this document of characters that are prohibited as
-     output (as described in section 5)
-
-   - The bidirectional string testing used, if any (as described in
-     section 6)
-
-   - Any additional characters that are prohibited as output specific to
-     the profile
-
-   Each profile MUST state the character repertoire on which the profile
-   will operate.  Appendix A lists the Unicode repertoires that can be
-   selected.  No repertoire is ever complete, and it is expected that
-   characters will be added to the Unicode repertoire for the
-   foreseeable future.  Section 7 of this document describes how to
-   handle characters that are assigned in later versions of the Unicode
-   repertories.  Subsections of appendix A also list unassigned code
-   points for each repertoire.
-
-   This document is for Unicode version 3.2, and should not be
-   considered to automatically apply to later Unicode versions.  The
-   IETF, through an explicit standards action, may update this document
-   as appropriate to handle later Unicode versions.
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   This document lists the unassigned code points in the range 0 to
-   10FFFF for Unicode 3.2 in appendix A.  The list in appendix A MUST be
-   used by implementations of this specification.  If there are any
-   discrepancies between the list in appendix A and the Unicode 3.2
-   specification, the list in appendix A always takes precedence.
-
-   Each profile of stringprep MUST be registered with IANA.  The
-   registration procedure is described in the IANA Considerations
-   appendix; basically, the IESG must review each profile of stringprep.
-   Protocol developers are strongly encouraged to look through the IANA
-   profile registry when creating new profiles for stringprep, and to
-   re-use logic from earlier profiles where possible in new profiles.
-   In some cases, an existing profile can be reused by a different
-   protocol.
-
-2. Preparation Overview
-
-   The steps for preparing strings are:
-
-   1) Map -- For each character in the input, check if it has a mapping
-      and, if so, replace it with its mapping.  This is described in
-      section 3.
-
-   2) Normalize -- Possibly normalize the result of step 1 using Unicode
-      normalization.  This is described in section 4.
-
-   3) Prohibit -- Check for any characters that are not allowed in the
-      output.  If any are found, return an error.  This is described in
-      section 5.
-
-   4) Check bidi -- Possibly check for right-to-left characters, and if
-      any are found, make sure that the whole string satisfies the
-      requirements for bidirectional strings.  If the string does not
-      satisfy the requirements for bidirectional strings, return an
-      error.  This is described in section 6.
-
-   The above steps MUST be performed in the order given to comply with
-   this specification.
-
-   The mappings described in section 3, and the optional Unicode
-   normalization described in section 4, can be one-to-none, one-to-one,
-   one-to-many, many-to-one, or many-to-many.  That is, some characters
-   might be eliminated or replaced by more than one character, and the
-   output of this step might be shorter or longer than the input.
-   Because of this, the system using stringprep MUST be prepared to
-   receive a longer or shorter string than the one input in the
-   stringprep algorithm.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-3. Mapping
-
-   Each character in the input stream MUST be checked against a mapping
-   table.  The mapping table SHOULD come from this document, although
-   the mapping table MAY be added to or altered by the profile.  The
-   mapping tables are subsections of appendix B.
-
-   The lists in appendix B MUST be used by implementations of this
-   specification.  If there are any discrepancies between the lists in
-   appendix B and subsections below, the lists in appendix B always
-   takes precedence.
-
-   For any individual character, the mapping table MAY specify that a
-   character be mapped to nothing, or mapped to one other character, or
-   mapped to a string of other characters.
-
-   Mapped characters are not re-scanned during the mapping step.  That
-   is, if character A at position X is mapped to character B, character
-   B which is now at position X is not checked against the mapping
-   table.
-
-3.1 Commonly mapped to nothing
-
-   The following characters are simply deleted from the input (that is,
-   they are mapped to nothing) because their presence or absence in
-   protocol identifiers should not make two strings different.  They are
-   listed in Table B.1.
-
-   Some characters are only useful in line-based text, and are otherwise
-   invisible and ignored.
-
-   00AD; SOFT HYPHEN
-   1806; MONGOLIAN TODO SOFT HYPHEN
-   200B; ZERO WIDTH SPACE
-   2060; WORD JOINER
-   FEFF; ZERO WIDTH NO-BREAK SPACE
-
-   Some characters affect glyph choice and glyph placement, but do not
-   bear semantics.
-
-   034F; COMBINING GRAPHEME JOINER
-   180B; MONGOLIAN FREE VARIATION SELECTOR ONE
-   180C; MONGOLIAN FREE VARIATION SELECTOR TWO
-   180D; MONGOLIAN FREE VARIATION SELECTOR THREE
-   200C; ZERO WIDTH NON-JOINER
-   200D; ZERO WIDTH JOINER
-   FE00; VARIATION SELECTOR-1
-   FE01; VARIATION SELECTOR-2
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   FE02; VARIATION SELECTOR-3
-   FE03; VARIATION SELECTOR-4
-   FE04; VARIATION SELECTOR-5
-   FE05; VARIATION SELECTOR-6
-   FE06; VARIATION SELECTOR-7
-   FE07; VARIATION SELECTOR-8
-   FE08; VARIATION SELECTOR-9
-   FE09; VARIATION SELECTOR-10
-   FE0A; VARIATION SELECTOR-11
-   FE0B; VARIATION SELECTOR-12
-   FE0C; VARIATION SELECTOR-13
-   FE0D; VARIATION SELECTOR-14
-   FE0E; VARIATION SELECTOR-15
-   FE0F; VARIATION SELECTOR-16
-
-3.2 Case folding
-
-   If a profile is going to map characters for case-insensitive
-   comparison, that profile SHOULD map using either appendix B.2 or
-   appendix B.3.  appendix B.2 is for profiles that also use Unicode
-   normalization form KC, while appendix  B.3 is for profiles that do
-   not use Unicode normalization.  These tables map from uppercase to
-   lowercase characters.  Note that this could have been "change all
-   lowercase characters into uppercase characters".  However, the
-   upper-to-lower folding was chosen because there is a tradition of
-   using lowercase in current Internet applications and protocols.
-
-   If a profile creates its own mapping tables for case folding, they
-   SHOULD be based on [UTR21], and SHOULD map from uppercase characters
-   to lowercase.  The "CaseFolding.txt" file from the Unicode database
-   SHOULD be used to prepare the mapping table. The profile SHOULD do
-   full case mapping (that is, using statuses C, F, and I).
-
-   If the profile is using Unicode normalization form KC (as described
-   in section 4 of this document), it is important to note that there
-   are some characters that do not have mappings in [UTR21] but still
-   need processing.  These characters include a few Greek characters and
-   many symbols that contain Latin characters.  The list of characters
-   to add to the mapping table can determined by the following
-   algorithm:
-
-   b = NormalizeWithKC(Fold(a));
-   c = NormalizeWithKC(Fold(b));
-   if c is not the same as b, add a mapping for "a to c".
-
-   Because NormalizeWithKC(Fold(c)) always equals c, the table is stable
-   from that point on.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 8]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   Appendix B.3 is derived from the CaseFolding-3.txt file associated
-   with Unicode 3.2; appendix B.2 is based on appendix B.3 with the
-   additional characters added from the algorithm above.
-
-   Authors of profiles of this document need to consider the effects of
-   changing the mapping of any currently-assigned character when
-   updating their profiles.  Adding a new mapping for a currently-
-   assigned character, or changing an existing mapping, could cause a
-   variance between the behavior of systems that have been updated and
-   systems that have not been updated.
-
-4. Normalization
-
-   The output of the mapping step is optionally normalized using one of
-   the Unicode normalization forms, as described in [UAX15].  A profile
-   can specify one of two options for Unicode normalization:
-
-   - no normalization
-
-   - Unicode normalization with form KC
-
-   A profile MAY choose to do no normalization.  However, such a profile
-   can easily yield results that will be surprising to typical users,
-   depending on the input mechanism they use.  For example, some input
-   mechanisms enter compatibility characters that look exactly like the
-   underlying characters, but have different code points.  Another
-   example of where Unicode normalization helps create predictable
-   results is with characters that have multiple combining diacritics:
-   normalization orders those diacritics in a predictable fashion.
-
-   On the other hand, Unicode normalization requires fairly large tables
-   and somewhat complicated character reordering logic.  The size and
-   complexity should not be considered daunting except in the most
-   restricted of environments, and needs to be weighed against the
-   problems of user surprise from comparing unnormalized strings.  Note
-   that the tables used for normalization are not given in this
-   document, but instead must be derived from the Unicode database, as
-   described in [UAX15].
-
-   There is a third form of normalization, Unicode normalization with
-   form C.  If a profile is going to use a Unicode normalization, it
-   MUST use Unicode normalization form KC.  Form KC maps many
-   "compatibility characters" to their equivalents.  Some user interface
-   systems make it possible to enter compatibility characters instead of
-   the base equivalents.  Thus, using form KC instead of form C will
-   cause more strings that users would expect to match to actually
-   match.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 9]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   A profile that specifies Unicode normalization MUST use the
-   normalization in [UAX15] that is associated with the version of the
-   Unicode character set specified for the profile.
-
-   The composition process described in [UAX15] requires a fixed
-   composition version of Unicode to ensure that strings normalized
-   under one version of Unicode remain normalized under all future
-   versions of Unicode.
-
-   The IETF is relying on Unicode not to change the normalization of
-   currently-assigned characters in future versions of normalization.
-   If a future version of the normalization tables changes the
-   normalized value of an existing character, authors of profiles of
-   this document have to look at the changes very carefully before they
-   update their normalization tables.  Such a change could cause a
-   variance between the behavior of systems that have been updated and
-   systems that have not been updated.
-
-5. Prohibited Output
-
-   Before the text can be emitted, it MUST be checked for prohibited
-   code points.  There are a variety of prohibited code points, as
-   described in this section.  A profile of this document MAY use all or
-   some of the tables in appendix C.
-
-   The stringprep process never emits both an error and a string.  If an
-   error is detected during the checking for prohibited code points,
-   only an error is returned.
-
-   Note that the subsections below describe how the tables in appendix C
-   were formed.  They are here for people who want to understand more,
-   but they should be ignored by implementors.  Implementations that use
-   tables MUST map based on the tables themselves, not based on the
-   descriptions in this section of how the tables were created.
-
-   The lists in appendix C MUST be used by implementations of this
-   specification.  If there are any discrepancies between the lists in
-   appendix C and subsections below, the lists in appendix C always take
-   precedence.
-
-   Some code points listed in one section may also appear in other
-   sections.
-
-   It is important to note that a profile of this document MAY prohibit
-   additional characters.
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 10]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   Each subsection of this section has a matching subsection in appendix
-   C.  For example, the characters listed in section 5.1 are listed in
-   appendix C.1.
-
-5.1 Space characters
-
-   Space characters can make accurate visual transcription of strings
-   nearly impossible and could lead to user entry errors in many ways.
-   Note that the list below is split into two tables in appendix C:
-   Table C.1.1 contains the ASCII code points, while Table C.1.2
-   contains the non-ASCII code points.  Most profiles of this document
-   that want to prohibit space characters will want to include both
-   tables.
-
-   0020; SPACE
-   00A0; NO-BREAK SPACE
-   1680; OGHAM SPACE MARK
-   2000; EN QUAD
-   2001; EM QUAD
-   2002; EN SPACE
-   2003; EM SPACE
-   2004; THREE-PER-EM SPACE
-   2005; FOUR-PER-EM SPACE
-   2006; SIX-PER-EM SPACE
-   2007; FIGURE SPACE
-   2008; PUNCTUATION SPACE
-   2009; THIN SPACE
-   200A; HAIR SPACE
-   200B; ZERO WIDTH SPACE
-   202F; NARROW NO-BREAK SPACE
-   205F; MEDIUM MATHEMATICAL SPACE
-   3000; IDEOGRAPHIC SPACE
-
-5.2 Control characters
-
-   Control characters (or characters with control function) cannot be
-   seen and can cause unpredictable results when displayed.  Note that
-   the list below is split into two tables in appendix C: Table C.2.1
-   contains the ASCII code points, while Table C.2.2 contains the non-
-   ASCII code points.  Most profiles of this document that want to
-   prohibit control characters will want to include both tables.
-
-   0000-001F; [CONTROL CHARACTERS]
-   007F; DELETE
-   0080-009F; [CONTROL CHARACTERS]
-   06DD; ARABIC END OF AYAH
-   070F; SYRIAC ABBREVIATION MARK
-   180E; MONGOLIAN VOWEL SEPARATOR
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 11]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   200C; ZERO WIDTH NON-JOINER
-   200D; ZERO WIDTH JOINER
-   2028; LINE SEPARATOR
-   2029; PARAGRAPH SEPARATOR
-   2060; WORD JOINER
-   2061; FUNCTION APPLICATION
-   2062; INVISIBLE TIMES
-   2063; INVISIBLE SEPARATOR
-   206A-206F; [CONTROL CHARACTERS]
-   FEFF; ZERO WIDTH NO-BREAK SPACE
-   FFF9-FFFC; [CONTROL CHARACTERS]
-   1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
-
-5.3 Private use
-
-   Because private-use characters do not have defined meanings, they are
-   likely to be prohibited.  The private-use characters are:
-
-   E000-F8FF; [PRIVATE USE, PLANE 0]
-   F0000-FFFFD; [PRIVATE USE, PLANE 15]
-   100000-10FFFD; [PRIVATE USE, PLANE 16]
-
-5.4 Non-character code points
-
-   Non-character code points are code points that have been allocated in
-   ISO/IEC 10646 but are not characters.  Because they are already
-   assigned, they are guaranteed not to later change into characters.
-
-   FDD0-FDEF; [NONCHARACTER CODE POINTS]
-   FFFE-FFFF; [NONCHARACTER CODE POINTS]
-   1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-   2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-   3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-   4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-   5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-   6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-   7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-   8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-   9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-   AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-   BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-   CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-   DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-   EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-   FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-   10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 12]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   The non-character code points are listed in the PropList.txt file
-   from the Unicode database.
-
-5.5 Surrogate codes
-
-   The following code points are permanently reserved for use as
-   surrogate code values in the UTF-16 encoding, will never be assigned
-   to characters in the Unicode repertoire, and are therefore
-   prohibited:
-
-   D800-DFFF; [SURROGATE CODES]
-
-5.6 Inappropriate for plain text
-
-   The following characters do not appear in regular text.
-
-   FFF9; INTERLINEAR ANNOTATION ANCHOR
-   FFFA; INTERLINEAR ANNOTATION SEPARATOR
-   FFFB; INTERLINEAR ANNOTATION TERMINATOR
-   FFFC; OBJECT REPLACEMENT CHARACTER
-
-   Although the replacement character (U+FFFD) might be used when a
-   string is displayed,  it doesn't make sense for it to be part of the
-   string itself.  It is often displayed by renderers to indicate "there
-   would be some character here, but it cannot be rendered".  For
-   example, on a computer with no Asian fonts, a string with three
-   ideographs might be rendered with three replacement characters.
-
-   FFFD; REPLACEMENT CHARACTER
-
-5.7 Inappropriate for canonical representation
-
-   The ideographic description characters allow different sequences of
-   characters to be rendered the same way, which makes them
-   inappropriate for strings that have to have a single canonical
-   representation.
-
-   2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-
-5.8 Change display properties or are deprecated
-
-   The following characters can cause changes in display or the order in
-   which characters appear when rendered, or are deprecated in Unicode.
-
-   0340; COMBINING GRAVE TONE MARK
-   0341; COMBINING ACUTE TONE MARK
-   200E; LEFT-TO-RIGHT MARK
-   200F; RIGHT-TO-LEFT MARK
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 13]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   202A; LEFT-TO-RIGHT EMBEDDING
-   202B; RIGHT-TO-LEFT EMBEDDING
-   202C; POP DIRECTIONAL FORMATTING
-   202D; LEFT-TO-RIGHT OVERRIDE
-   202E; RIGHT-TO-LEFT OVERRIDE
-   206A; INHIBIT SYMMETRIC SWAPPING
-   206B; ACTIVATE SYMMETRIC SWAPPING
-   206C; INHIBIT ARABIC FORM SHAPING
-   206D; ACTIVATE ARABIC FORM SHAPING
-   206E; NATIONAL DIGIT SHAPES
-   206F; NOMINAL DIGIT SHAPES
-
-5.9 Tagging characters
-
-   The following characters are used for tagging text and are invisible.
-
-   E0001; LANGUAGE TAG
-   E0020-E007F; [TAGGING CHARACTERS]
-
-6. Bidirectional Characters
-
-   Most characters are displayed from left to right, but some are
-   displayed from right to left.  This feature of Unicode is called
-   "bidirectional text", or "bidi" for short.  The Unicode standard has
-   an extensive discussion of how to reorder glyphs for display when
-   dealing with bidirectional text such as Arabic or Hebrew.  See [UAX9]
-   for more information.  In particular, all Unicode text is stored in
-   logical order.
-
-   A profile MAY choose to ignore bidirectional text.  However, ignoring
-   bidirectional text can cause display ambiguities.  For example, it is
-   quite easy to create two different strings with the same characters
-   (but in different order) that are correctly displayed identically.
-   Therefore, in order to avoid most problems with ambiguous
-   bidirectional text display, profile creators should strongly consider
-   including the bidirectional character handling described in this
-   section in their profile.
-
-   The stringprep process never emits both an error and a string.  If an
-   error is detected during the checking of bidirectional strings, only
-   an error is returned.
-
-   [Unicode3.2] defines several bidirectional categories; each character
-   has one bidirectional category assigned to it.  For the purposes of
-   the requirements below, an "RandALCat character" is a character that
-   has Unicode bidirectional categories "R" or "AL"; an "LCat character"
-   is a character that has Unicode bidirectional category "L".  Note
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 14]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   that there are many characters which fall in neither of the above
-   definitions; Latin digits (<U+0030> through <U+0039>) are examples of
-   this because they have bidirectional category "EN".
-
-   In any profile that specifies bidirectional character handling, all
-   three of the following requirements MUST be met:
-
-   1) The characters in section 5.8 MUST be prohibited.
-
-   2) If a string contains any RandALCat character, the string MUST NOT
-      contain any LCat character.
-
-   3) If a string contains any RandALCat character, a RandALCat
-      character MUST be the first character of the string, and a
-      RandALCat character MUST be the last character of the string.
-
-   Note that requirement 3 prohibits strings such as <U+0627><U+0031>
-   ("aleph 1") but allows strings such as <U+0627><U+0031><U+0628>
-   ("aleph 1 beh").  [UAX9] goes into great detail about the display
-   order of strings that contain particular categories of characters in
-   particular sequences.
-
-   Table D.1 lists the characters that belong to Unicode bidirectional
-   categories "R" and "AL".  Table D.2 lists all the characters that
-   belong to Unicode bidirectonal category "L".  These tables are
-   derived from [Unicode3.2].
-
-7. Unassigned Code Points in Stringprep Profiles
-
-   This section describes two different types of strings in typical
-   protocols where internationalized strings are used: "stored strings"
-   and "queries".  Of course, different Internet protocols use strings
-   very differently, so these terms cannot be used exactly in every
-   protocol that needs to use stringprep.  In general, "stored strings"
-   are strings that are used in protocol identifiers and named entities,
-   such as names in digital certificates and DNS domain name parts.
-   "Queries" are strings that are used to match against strings that are
-   stored identifiers, such as user-entered names for digital
-   certificate authorities and DNS lookups.
-
-   All code points not assigned in the character repertoire named in a
-   stringprep profile are called "unassigned code points".  Stored
-   strings using the profile MUST NOT contain any unassigned code
-   points.  Queries for matching strings MAY contain unassigned code
-   points.  Note that this is the only part of this document where the
-   requirements for queries differs from the requirements for stored
-   strings.
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 15]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   Using two different policies for where unassigned code points can
-   appear removes the need for versioning in protocols that use
-   stringprep profiles.  This is very useful since it makes the overall
-   processing simpler and does not impose a "protocol" to handle
-   versioning.  It is expected that the ISO/IEC 10646 and Unicode
-   repertoires will be updated fairly frequently; at the time that this
-   document is being written, it has happened approximately once a year.
-   Each time a new version of a repertoire appears, a new version of a
-   profile MAY be created.  Some end users will want to use the new code
-   points as soon as they are defined.
-
-   The list of unassigned code points MUST be given in a profile, and
-   that list MUST be used by implementations of the profile.
-
-   The goal of the requirements in this section is to prevent
-   comparisons between two strings that were both permitted to contain
-   unassigned code points.  When two strings X and Y are compared and
-   string Y was prepared in a way that permits unassigned code points, a
-   negative result to the comparison is not definitive; it's possible
-   that the strings don't match even though they would match if a more
-   recent version of the profile were used for Y.  However, if both X
-   and Y were prepared in a way that permits unassigned code points,
-   something worse can happen: even a positive result for the comparison
-   is not definitive.  It is possible that the strings do match even
-   though they would not match if a more recent version of the profile
-   were used (one that prohibits a code point appearing in both X and
-   Y).
-
-   Due to the way that versioning is handled in this section, stored
-   strings that are embedded in structures that cannot be changed (such
-   as the signed parts of digital certificates) MUST NOT contain any
-   unassigned code points.
-
-7.1 Categories of code points
-
-   Each code point in a repertoire named by a profile of stringprep can
-   be categorized by how it acts in the process described in earlier
-   sections of this document:
-
-      AO      Code points that can be in the output
-
-      MN      Code points that cannot be in the output because they
-              never appear as output from mapping or normalization
-
-      D       Code points that cannot be in the output because they are
-              disallowed in the prohibition step
-
-      U       Unassigned code points
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 16]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   A subsequent version of a profile that references a newer version of
-   a repertoire with new code points will inherently have some code
-   points move from category U to either D, MN, or AO.  For backwards
-   compatibility, a subsequent version of a profile MUST NOT move code
-   points from any other category.  That is, current AO, MN, or D code
-   points MUST NOT ever change to a different category.
-
-   Stored strings MUST NOT contain any code points outside of AO for the
-   latest version of a profile.  That is, they are forbidden to contain
-   code points from the MN, D, or U categories.
-
-   Applications creating queries MUST treat U code points as if they
-   were AO when preparing the query to be entered in the process
-   described by a profile of stringprep.  Those applications MAY
-   optionally have a preprocessor that provide stricter checks: treating
-   unassigned code points in the input as errors, or warning the user
-   about the fact that the code point is unassigned in the version of a
-   profile that the software is based on; such a choice is a local
-   matter for the software.
-
-7.2 Reasons for the difference between stored strings and queries
-
-   Different software using different versions of a stringprep profile
-   need to interoperate with maximal compatibility.  The scheme
-   described in this section (stored strings MUST NOT contain unassigned
-   code points, queries MAY include unassigned code points) allows that
-   compatibility without introducing any known security or
-   interoperability issues.
-
-   The list below shows what happens if a query contains a code point
-   from category U that is allowed in a newer version of a profile.  The
-   query either matches the string that was intended, or matches no
-   string at all.  In this list, the query comes from an application
-   using version "oldVersion" of a profile, the stored string was
-   created using version "newVersion" of the same profile, and the code
-   point X was in category U in oldVersion, and has changed category to
-   AO, MN, or D.  There are 3 possible scenarios:
-
-   1. X is assigned to AO -- In newVersion, X is in category AO.
-      Because the application passed X through, it gets back a positive
-      match with the stored string.  There is one exceptional case,
-      where X is a combining mark.
-
-      The order of combining marks is normalized, so if another
-      combining mark Y has a lower combining class than X then XY will
-      be put in the canonical order YX.  (Unassigned code points are
-      never reordered, so this doesn't happen in oldVersion).  If the
-      query contains YX, the query will get positive match with the
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 17]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-      stored string.  However, no string can be stored with XY, so a
-      query with XY will get a negative answer to the test for matching.
-
-   2. X is assigned to MN -- In newVersion, X is normalized to code
-      point "nX" and therefore X is now put in category MN.  This cannot
-      exist in any stored string, so any query containing X will get a
-      negative answer to the test for matching.  Note, however, if the
-      query had contained the letter nX, it would have positively
-      matched.
-
-   3. X is assigned to D -- In newVersion, X is in category D.  This
-      cannot exist in any stored string, so any query containing X will
-      get a negative answer to the test for matching.
-
-   In none of the cases does the query get data for a stored string
-   other than the one it actually tried to match against.
-
-   Profiles are stable between versions in the following sense: If a
-   string S has been prepared using newVersion, then it will not change
-   if it is subsequently prepared using oldVersion.
-
-7.3 Versions of applications and stored strings
-
-   Another way to see that this versioning system works is to compare
-   what happens when an application uses a newer or older version of a
-   profile.
-
-   Newer query application -- Suppose that a querying application is
-   using version newVersion and the stored string was created using
-   version oldVersion.  This case is simple: there will be no characters
-   in the stored string that cannot be queried by the application
-   because the new profile uses a superset of the code points used for
-   making the stored string.
-
-   Newer stored string -- Suppose that a querying application is using
-   oldVersion and the stored string was created using a profile that
-   uses newVersion.  Because the querying application let unassigned
-   code points pass through, the user can query on stored strings that
-   use code points in newVersion.  No stored strings can have code
-   points that are unassigned in newVersion, since that is illegal.  In
-   order to get a match, the querying application has to enter the
-   unassigned code points in the proper order, and has to use unassigned
-   code points that would make it through both the mapping and the
-   normalization steps.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 18]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-8. References
-
-8.1 Normative references
-
-   [UAX15]      Mark Davis and Martin Duerst. Unicode Standard Annex
-                #15:  Unicode Normalization Forms, Version 3.2.0.
-                <http://www.unicode.org/unicode/reports/tr15/tr15-
-                22.html>.
-
-   [Unicode3.2] 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/).
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-8.2 Informative references
-
-   [CharModel]  Unicode Technical Report;17, Character Encoding Model.
-                <http://www.unicode.org/unicode/reports/tr17/>.
-
-   [Glossary]   Unicode Glossary, <http://www.unicode.org/glossary/>.
-
-   [ISO10646]   ISO/IEC, "Information Technology - Universal Multiple-
-                Octet Coded Character Set (UCS) - Part 1: Architecture
-                and Basic Multilingual Plane", ISO/IEC 10646-1:2000,
-                October 2000.
-
-   [RFC2434]    Narten, T. and H. Alvestrand, "Guidelines for IANA
-                Considerations", BCP 26, RFC 2434, October 1998.
-
-   [UAX9]       The Unicode Consortium. Unicode Standard Annex #9, The
-                Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [UTR21]      Mark Davis. Case Mappings. Unicode Technical Report 21.
-                <http://www.unicode.org/unicode/reports/tr21/>.
-
-9. Security Considerations
-
-   Stringprep is used with Unicode characters.  There are security
-   considerations that are specific to stringprep, and others that are
-   generic to using Unicode.
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 19]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-9.1 Stringprep-specific security considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.  User
-   applications can help disambiguate some similar-looking characters by
-   showing the user when a string changes between scripts.
-
-   Most profiles of stringprep can cause changes in strings that are
-   input to stringprep.  Because of this, protocols that have sets of
-   non-allowed characters or sequences MUST check for the non-allowed
-   characters or sequences after the stringprep processing.
-
-   This document does not mandate the checking of bidirectional
-   characters in section 6.  If the requirements in section 6 are not
-   used in a profile of stringprep, it is easy to create many strings
-   whose characters are in different order but are displayed
-   identically.  This can cause security-related user confusion similar
-   to look-alike characters, as described above.
-
-   Stringprep does not do anything to assure that any algorithms
-   translating characters from non-Unicode into Unicode produce the same
-   output in all implementations.
-
-   Some Unicode codepoints are invisible.  Protocols that allow these
-   characters (that is, do not map them out or prohibit them in
-   stringprep) can cause users confusion when two identical-looking
-   strings do not match.
-
-9.2 Generic Unicode security considerations
-
-   Using Unicode characters explicitly forces applications to use
-   multi-octet characters.  Converting an application from one that uses
-   single-octet characters to one that uses multi-octet characters must
-   be done very carefully, particularly in an application that checks
-   for values of characters or sorts characters.
-
-   Protocols that use stringprep usually also use encodings of Unicode,
-   such as UTF-8 or UTF-16.  Some applications using those encodings
-   have been known to not check for illegal or ill-formed sequences in
-   the encodings, and thereby have not detected sequences of octets that
-   would have been detected if they used just ASCII.  For example, in
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 20]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   UTF-8 the octet sequence "0xC0 0xAB" is an illegal formation of
-   U+002B (plus sign).  All programs should reject any string that is an
-   illegal or ill-formed octet sequence for the encoding being used.
-
-   Both Unicode normalization and conversion between Unicode encodings
-   can cause strings to grow or shrink.  Programs that used fixed-size
-   buffers, or that make assumptions that buffers will always be greater
-   than or less than particular sizes, are likely to fail in insecure
-   fashions when using Unicode normalization or encoding conversions.
-
-   Covering an extensive list of security threats and considerations on
-   the use of current and future versions of Unicode is outside of the
-   scope of this document.
-
-10. IANA Considerations
-
-   Stringprep profiles MUST have IETF consensus as described in
-   [RFC2434].  Each profile MUST be reviewed by the IESG before it is
-   registered.  The IESG MAY change a profile before registration.
-
-   IANA has set up a registry of stringprep profiles.  This registry is
-   a single text file that lists the known profiles.  Each entry in the
-   registry has three fields:
-
-   - Profile name
-
-   - RFC in which the profile is defined
-
-   - Indicator whether or not this is the newest version of the profile
-
-   Each version of a profile will remain listed in the registry forever.
-   That is, if a new version of a profile supersedes an earlier version,
-   both versions will continue to be listed in the registry, but the
-   current version indicator will be turned off for the earlier version
-   and turned on for the newer version.
-
-   It is probably harmful if a large number of profiles of stringprep
-   proliferate.  Therefore, the IESG may reject proposals for new
-   profiles and instead suggest that protocols reuse existing profiles.
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 21]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into the first document of this
-   document.  Mark Davis and Patrik Faltstrom were particularly helpful
-   in some of the ideas, such as the versioning description.
-
-   The IDN nameprep design team made many useful changes to the first
-   document.  That team and its advisors include:
-
-   Asmus Freytag
-   Cathy Wissink
-   Francois Yergeau
-   James Seng
-   Marc Blanchet
-   Mark Davis
-   Martin Duerst
-   Patrik Faltstrom
-   Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-   Jonathan Rosenne
-   Kent Karlsson
-   Scott Hollenbeck
-   Dave Crocker
-   Erik Nordmark
-   Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 22]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-A. Unicode repertoires
-
-   The following is the only repertoire covered in this document:
-
-   Unicode 3.2, as defined in [Unicode3.2].
-
-A.1 Unassigned code points in Unicode 3.2
-
-   ----- Start Table A.1 -----
-   0221
-   0234-024F
-   02AE-02AF
-   02EF-02FF
-   0350-035F
-   0370-0373
-   0376-0379
-   037B-037D
-   037F-0383
-   038B
-   038D
-   03A2
-   03CF
-   03F7-03FF
-   0487
-   04CF
-   04F6-04F7
-   04FA-04FF
-   0510-0530
-   0557-0558
-   0560
-   0588
-   058B-0590
-   05A2
-   05BA
-   05C5-05CF
-   05EB-05EF
-   05F5-060B
-   060D-061A
-   061C-061E
-   0620
-   063B-063F
-   0656-065F
-   06EE-06EF
-   06FF
-   070E
-   072D-072F
-   074B-077F
-   07B2-0900
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 23]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0904
-   093A-093B
-   094E-094F
-   0955-0957
-   0971-0980
-   0984
-   098D-098E
-   0991-0992
-   09A9
-   09B1
-   09B3-09B5
-   09BA-09BB
-   09BD
-   09C5-09C6
-   09C9-09CA
-   09CE-09D6
-   09D8-09DB
-   09DE
-   09E4-09E5
-   09FB-0A01
-   0A03-0A04
-   0A0B-0A0E
-   0A11-0A12
-   0A29
-   0A31
-   0A34
-   0A37
-   0A3A-0A3B
-   0A3D
-   0A43-0A46
-   0A49-0A4A
-   0A4E-0A58
-   0A5D
-   0A5F-0A65
-   0A75-0A80
-   0A84
-   0A8C
-   0A8E
-   0A92
-   0AA9
-   0AB1
-   0AB4
-   0ABA-0ABB
-   0AC6
-   0ACA
-   0ACE-0ACF
-   0AD1-0ADF
-   0AE1-0AE5
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 24]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0AF0-0B00
-   0B04
-   0B0D-0B0E
-   0B11-0B12
-   0B29
-   0B31
-   0B34-0B35
-   0B3A-0B3B
-   0B44-0B46
-   0B49-0B4A
-   0B4E-0B55
-   0B58-0B5B
-   0B5E
-   0B62-0B65
-   0B71-0B81
-   0B84
-   0B8B-0B8D
-   0B91
-   0B96-0B98
-   0B9B
-   0B9D
-   0BA0-0BA2
-   0BA5-0BA7
-   0BAB-0BAD
-   0BB6
-   0BBA-0BBD
-   0BC3-0BC5
-   0BC9
-   0BCE-0BD6
-   0BD8-0BE6
-   0BF3-0C00
-   0C04
-   0C0D
-   0C11
-   0C29
-   0C34
-   0C3A-0C3D
-   0C45
-   0C49
-   0C4E-0C54
-   0C57-0C5F
-   0C62-0C65
-   0C70-0C81
-   0C84
-   0C8D
-   0C91
-   0CA9
-   0CB4
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 25]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0CBA-0CBD
-   0CC5
-   0CC9
-   0CCE-0CD4
-   0CD7-0CDD
-   0CDF
-   0CE2-0CE5
-   0CF0-0D01
-   0D04
-   0D0D
-   0D11
-   0D29
-   0D3A-0D3D
-   0D44-0D45
-   0D49
-   0D4E-0D56
-   0D58-0D5F
-   0D62-0D65
-   0D70-0D81
-   0D84
-   0D97-0D99
-   0DB2
-   0DBC
-   0DBE-0DBF
-   0DC7-0DC9
-   0DCB-0DCE
-   0DD5
-   0DD7
-   0DE0-0DF1
-   0DF5-0E00
-   0E3B-0E3E
-   0E5C-0E80
-   0E83
-   0E85-0E86
-   0E89
-   0E8B-0E8C
-   0E8E-0E93
-   0E98
-   0EA0
-   0EA4
-   0EA6
-   0EA8-0EA9
-   0EAC
-   0EBA
-   0EBE-0EBF
-   0EC5
-   0EC7
-   0ECE-0ECF
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 26]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0EDA-0EDB
-   0EDE-0EFF
-   0F48
-   0F6B-0F70
-   0F8C-0F8F
-   0F98
-   0FBD
-   0FCD-0FCE
-   0FD0-0FFF
-   1022
-   1028
-   102B
-   1033-1035
-   103A-103F
-   105A-109F
-   10C6-10CF
-   10F9-10FA
-   10FC-10FF
-   115A-115E
-   11A3-11A7
-   11FA-11FF
-   1207
-   1247
-   1249
-   124E-124F
-   1257
-   1259
-   125E-125F
-   1287
-   1289
-   128E-128F
-   12AF
-   12B1
-   12B6-12B7
-   12BF
-   12C1
-   12C6-12C7
-   12CF
-   12D7
-   12EF
-   130F
-   1311
-   1316-1317
-   131F
-   1347
-   135B-1360
-   137D-139F
-   13F5-1400
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 27]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1677-167F
-   169D-169F
-   16F1-16FF
-   170D
-   1715-171F
-   1737-173F
-   1754-175F
-   176D
-   1771
-   1774-177F
-   17DD-17DF
-   17EA-17FF
-   180F
-   181A-181F
-   1878-187F
-   18AA-1DFF
-   1E9C-1E9F
-   1EFA-1EFF
-   1F16-1F17
-   1F1E-1F1F
-   1F46-1F47
-   1F4E-1F4F
-   1F58
-   1F5A
-   1F5C
-   1F5E
-   1F7E-1F7F
-   1FB5
-   1FC5
-   1FD4-1FD5
-   1FDC
-   1FF0-1FF1
-   1FF5
-   1FFF
-   2053-2056
-   2058-205E
-   2064-2069
-   2072-2073
-   208F-209F
-   20B2-20CF
-   20EB-20FF
-   213B-213C
-   214C-2152
-   2184-218F
-   23CF-23FF
-   2427-243F
-   244B-245F
-   24FF
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 28]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   2614-2615
-   2618
-   267E-267F
-   268A-2700
-   2705
-   270A-270B
-   2728
-   274C
-   274E
-   2753-2755
-   2757
-   275F-2760
-   2795-2797
-   27B0
-   27BF-27CF
-   27EC-27EF
-   2B00-2E7F
-   2E9A
-   2EF4-2EFF
-   2FD6-2FEF
-   2FFC-2FFF
-   3040
-   3097-3098
-   3100-3104
-   312D-3130
-   318F
-   31B8-31EF
-   321D-321F
-   3244-3250
-   327C-327E
-   32CC-32CF
-   32FF
-   3377-337A
-   33DE-33DF
-   33FF
-   4DB6-4DFF
-   9FA6-9FFF
-   A48D-A48F
-   A4C7-ABFF
-   D7A4-D7FF
-   FA2E-FA2F
-   FA6B-FAFF
-   FB07-FB12
-   FB18-FB1C
-   FB37
-   FB3D
-   FB3F
-   FB42
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 29]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   FB45
-   FBB2-FBD2
-   FD40-FD4F
-   FD90-FD91
-   FDC8-FDCF
-   FDFD-FDFF
-   FE10-FE1F
-   FE24-FE2F
-   FE47-FE48
-   FE53
-   FE67
-   FE6C-FE6F
-   FE75
-   FEFD-FEFE
-   FF00
-   FFBF-FFC1
-   FFC8-FFC9
-   FFD0-FFD1
-   FFD8-FFD9
-   FFDD-FFDF
-   FFE7
-   FFEF-FFF8
-   10000-102FF
-   1031F
-   10324-1032F
-   1034B-103FF
-   10426-10427
-   1044E-1CFFF
-   1D0F6-1D0FF
-   1D127-1D129
-   1D1DE-1D3FF
-   1D455
-   1D49D
-   1D4A0-1D4A1
-   1D4A3-1D4A4
-   1D4A7-1D4A8
-   1D4AD
-   1D4BA
-   1D4BC
-   1D4C1
-   1D4C4
-   1D506
-   1D50B-1D50C
-   1D515
-   1D51D
-   1D53A
-   1D53F
-   1D545
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 30]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D547-1D549
-   1D551
-   1D6A4-1D6A7
-   1D7CA-1D7CD
-   1D800-1FFFD
-   2A6D7-2F7FF
-   2FA1E-2FFFD
-   30000-3FFFD
-   40000-4FFFD
-   50000-5FFFD
-   60000-6FFFD
-   70000-7FFFD
-   80000-8FFFD
-   90000-9FFFD
-   A0000-AFFFD
-   B0000-BFFFD
-   C0000-CFFFD
-   D0000-DFFFD
-   E0000
-   E0002-E001F
-   E0080-EFFFD
-   ----- End Table A.1 -----
-
-B. Mapping Tables
-
-   The following is the mapping table from section 3.  The table has
-   three columns:
-
-   - the code point that is mapped from
-   - the zero or more code points that it is mapped to
-   - the reason for the mapping
-
-   The columns are separated by semicolons.  Note that the second column
-   may be empty, or it may have one code point, or it may have more than
-   one code point, with each code point separated by a space.
-
-B.1 Commonly mapped to nothing
-
-   ----- Start Table B.1 -----
-   00AD; ; Map to nothing
-   034F; ; Map to nothing
-   1806; ; Map to nothing
-   180B; ; Map to nothing
-   180C; ; Map to nothing
-   180D; ; Map to nothing
-   200B; ; Map to nothing
-   200C; ; Map to nothing
-   200D; ; Map to nothing
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 31]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   2060; ; Map to nothing
-   FE00; ; Map to nothing
-   FE01; ; Map to nothing
-   FE02; ; Map to nothing
-   FE03; ; Map to nothing
-   FE04; ; Map to nothing
-   FE05; ; Map to nothing
-   FE06; ; Map to nothing
-   FE07; ; Map to nothing
-   FE08; ; Map to nothing
-   FE09; ; Map to nothing
-   FE0A; ; Map to nothing
-   FE0B; ; Map to nothing
-   FE0C; ; Map to nothing
-   FE0D; ; Map to nothing
-   FE0E; ; Map to nothing
-   FE0F; ; Map to nothing
-   FEFF; ; Map to nothing
-   ----- End Table B.1 -----
-
-B.2 Mapping for case-folding used with NFKC
-
-   ----- Start Table B.2 -----
-   0041; 0061; Case map
-   0042; 0062; Case map
-   0043; 0063; Case map
-   0044; 0064; Case map
-   0045; 0065; Case map
-   0046; 0066; Case map
-   0047; 0067; Case map
-   0048; 0068; Case map
-   0049; 0069; Case map
-   004A; 006A; Case map
-   004B; 006B; Case map
-   004C; 006C; Case map
-   004D; 006D; Case map
-   004E; 006E; Case map
-   004F; 006F; Case map
-   0050; 0070; Case map
-   0051; 0071; Case map
-   0052; 0072; Case map
-   0053; 0073; Case map
-   0054; 0074; Case map
-   0055; 0075; Case map
-   0056; 0076; Case map
-   0057; 0077; Case map
-   0058; 0078; Case map
-   0059; 0079; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 32]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   005A; 007A; Case map
-   00B5; 03BC; Case map
-   00C0; 00E0; Case map
-   00C1; 00E1; Case map
-   00C2; 00E2; Case map
-   00C3; 00E3; Case map
-   00C4; 00E4; Case map
-   00C5; 00E5; Case map
-   00C6; 00E6; Case map
-   00C7; 00E7; Case map
-   00C8; 00E8; Case map
-   00C9; 00E9; Case map
-   00CA; 00EA; Case map
-   00CB; 00EB; Case map
-   00CC; 00EC; Case map
-   00CD; 00ED; Case map
-   00CE; 00EE; Case map
-   00CF; 00EF; Case map
-   00D0; 00F0; Case map
-   00D1; 00F1; Case map
-   00D2; 00F2; Case map
-   00D3; 00F3; Case map
-   00D4; 00F4; Case map
-   00D5; 00F5; Case map
-   00D6; 00F6; Case map
-   00D8; 00F8; Case map
-   00D9; 00F9; Case map
-   00DA; 00FA; Case map
-   00DB; 00FB; Case map
-   00DC; 00FC; Case map
-   00DD; 00FD; Case map
-   00DE; 00FE; Case map
-   00DF; 0073 0073; Case map
-   0100; 0101; Case map
-   0102; 0103; Case map
-   0104; 0105; Case map
-   0106; 0107; Case map
-   0108; 0109; Case map
-   010A; 010B; Case map
-   010C; 010D; Case map
-   010E; 010F; Case map
-   0110; 0111; Case map
-   0112; 0113; Case map
-   0114; 0115; Case map
-   0116; 0117; Case map
-   0118; 0119; Case map
-   011A; 011B; Case map
-   011C; 011D; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 33]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   011E; 011F; Case map
-   0120; 0121; Case map
-   0122; 0123; Case map
-   0124; 0125; Case map
-   0126; 0127; Case map
-   0128; 0129; Case map
-   012A; 012B; Case map
-   012C; 012D; Case map
-   012E; 012F; Case map
-   0130; 0069 0307; Case map
-   0132; 0133; Case map
-   0134; 0135; Case map
-   0136; 0137; Case map
-   0139; 013A; Case map
-   013B; 013C; Case map
-   013D; 013E; Case map
-   013F; 0140; Case map
-   0141; 0142; Case map
-   0143; 0144; Case map
-   0145; 0146; Case map
-   0147; 0148; Case map
-   0149; 02BC 006E; Case map
-   014A; 014B; Case map
-   014C; 014D; Case map
-   014E; 014F; Case map
-   0150; 0151; Case map
-   0152; 0153; Case map
-   0154; 0155; Case map
-   0156; 0157; Case map
-   0158; 0159; Case map
-   015A; 015B; Case map
-   015C; 015D; Case map
-   015E; 015F; Case map
-   0160; 0161; Case map
-   0162; 0163; Case map
-   0164; 0165; Case map
-   0166; 0167; Case map
-   0168; 0169; Case map
-   016A; 016B; Case map
-   016C; 016D; Case map
-   016E; 016F; Case map
-   0170; 0171; Case map
-   0172; 0173; Case map
-   0174; 0175; Case map
-   0176; 0177; Case map
-   0178; 00FF; Case map
-   0179; 017A; Case map
-   017B; 017C; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 34]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   017D; 017E; Case map
-   017F; 0073; Case map
-   0181; 0253; Case map
-   0182; 0183; Case map
-   0184; 0185; Case map
-   0186; 0254; Case map
-   0187; 0188; Case map
-   0189; 0256; Case map
-   018A; 0257; Case map
-   018B; 018C; Case map
-   018E; 01DD; Case map
-   018F; 0259; Case map
-   0190; 025B; Case map
-   0191; 0192; Case map
-   0193; 0260; Case map
-   0194; 0263; Case map
-   0196; 0269; Case map
-   0197; 0268; Case map
-   0198; 0199; Case map
-   019C; 026F; Case map
-   019D; 0272; Case map
-   019F; 0275; Case map
-   01A0; 01A1; Case map
-   01A2; 01A3; Case map
-   01A4; 01A5; Case map
-   01A6; 0280; Case map
-   01A7; 01A8; Case map
-   01A9; 0283; Case map
-   01AC; 01AD; Case map
-   01AE; 0288; Case map
-   01AF; 01B0; Case map
-   01B1; 028A; Case map
-   01B2; 028B; Case map
-   01B3; 01B4; Case map
-   01B5; 01B6; Case map
-   01B7; 0292; Case map
-   01B8; 01B9; Case map
-   01BC; 01BD; Case map
-   01C4; 01C6; Case map
-   01C5; 01C6; Case map
-   01C7; 01C9; Case map
-   01C8; 01C9; Case map
-   01CA; 01CC; Case map
-   01CB; 01CC; Case map
-   01CD; 01CE; Case map
-   01CF; 01D0; Case map
-   01D1; 01D2; Case map
-   01D3; 01D4; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 35]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   01D5; 01D6; Case map
-   01D7; 01D8; Case map
-   01D9; 01DA; Case map
-   01DB; 01DC; Case map
-   01DE; 01DF; Case map
-   01E0; 01E1; Case map
-   01E2; 01E3; Case map
-   01E4; 01E5; Case map
-   01E6; 01E7; Case map
-   01E8; 01E9; Case map
-   01EA; 01EB; Case map
-   01EC; 01ED; Case map
-   01EE; 01EF; Case map
-   01F0; 006A 030C; Case map
-   01F1; 01F3; Case map
-   01F2; 01F3; Case map
-   01F4; 01F5; Case map
-   01F6; 0195; Case map
-   01F7; 01BF; Case map
-   01F8; 01F9; Case map
-   01FA; 01FB; Case map
-   01FC; 01FD; Case map
-   01FE; 01FF; Case map
-   0200; 0201; Case map
-   0202; 0203; Case map
-   0204; 0205; Case map
-   0206; 0207; Case map
-   0208; 0209; Case map
-   020A; 020B; Case map
-   020C; 020D; Case map
-   020E; 020F; Case map
-   0210; 0211; Case map
-   0212; 0213; Case map
-   0214; 0215; Case map
-   0216; 0217; Case map
-   0218; 0219; Case map
-   021A; 021B; Case map
-   021C; 021D; Case map
-   021E; 021F; Case map
-   0220; 019E; Case map
-   0222; 0223; Case map
-   0224; 0225; Case map
-   0226; 0227; Case map
-   0228; 0229; Case map
-   022A; 022B; Case map
-   022C; 022D; Case map
-   022E; 022F; Case map
-   0230; 0231; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 36]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0232; 0233; Case map
-   0345; 03B9; Case map
-   037A; 0020 03B9; Additional folding
-   0386; 03AC; Case map
-   0388; 03AD; Case map
-   0389; 03AE; Case map
-   038A; 03AF; Case map
-   038C; 03CC; Case map
-   038E; 03CD; Case map
-   038F; 03CE; Case map
-   0390; 03B9 0308 0301; Case map
-   0391; 03B1; Case map
-   0392; 03B2; Case map
-   0393; 03B3; Case map
-   0394; 03B4; Case map
-   0395; 03B5; Case map
-   0396; 03B6; Case map
-   0397; 03B7; Case map
-   0398; 03B8; Case map
-   0399; 03B9; Case map
-   039A; 03BA; Case map
-   039B; 03BB; Case map
-   039C; 03BC; Case map
-   039D; 03BD; Case map
-   039E; 03BE; Case map
-   039F; 03BF; Case map
-   03A0; 03C0; Case map
-   03A1; 03C1; Case map
-   03A3; 03C3; Case map
-   03A4; 03C4; Case map
-   03A5; 03C5; Case map
-   03A6; 03C6; Case map
-   03A7; 03C7; Case map
-   03A8; 03C8; Case map
-   03A9; 03C9; Case map
-   03AA; 03CA; Case map
-   03AB; 03CB; Case map
-   03B0; 03C5 0308 0301; Case map
-   03C2; 03C3; Case map
-   03D0; 03B2; Case map
-   03D1; 03B8; Case map
-   03D2; 03C5; Additional folding
-   03D3; 03CD; Additional folding
-   03D4; 03CB; Additional folding
-   03D5; 03C6; Case map
-   03D6; 03C0; Case map
-   03D8; 03D9; Case map
-   03DA; 03DB; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 37]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   03DC; 03DD; Case map
-   03DE; 03DF; Case map
-   03E0; 03E1; Case map
-   03E2; 03E3; Case map
-   03E4; 03E5; Case map
-   03E6; 03E7; Case map
-   03E8; 03E9; Case map
-   03EA; 03EB; Case map
-   03EC; 03ED; Case map
-   03EE; 03EF; Case map
-   03F0; 03BA; Case map
-   03F1; 03C1; Case map
-   03F2; 03C3; Case map
-   03F4; 03B8; Case map
-   03F5; 03B5; Case map
-   0400; 0450; Case map
-   0401; 0451; Case map
-   0402; 0452; Case map
-   0403; 0453; Case map
-   0404; 0454; Case map
-   0405; 0455; Case map
-   0406; 0456; Case map
-   0407; 0457; Case map
-   0408; 0458; Case map
-   0409; 0459; Case map
-   040A; 045A; Case map
-   040B; 045B; Case map
-   040C; 045C; Case map
-   040D; 045D; Case map
-   040E; 045E; Case map
-   040F; 045F; Case map
-   0410; 0430; Case map
-   0411; 0431; Case map
-   0412; 0432; Case map
-   0413; 0433; Case map
-   0414; 0434; Case map
-   0415; 0435; Case map
-   0416; 0436; Case map
-   0417; 0437; Case map
-   0418; 0438; Case map
-   0419; 0439; Case map
-   041A; 043A; Case map
-   041B; 043B; Case map
-   041C; 043C; Case map
-   041D; 043D; Case map
-   041E; 043E; Case map
-   041F; 043F; Case map
-   0420; 0440; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 38]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0421; 0441; Case map
-   0422; 0442; Case map
-   0423; 0443; Case map
-   0424; 0444; Case map
-   0425; 0445; Case map
-   0426; 0446; Case map
-   0427; 0447; Case map
-   0428; 0448; Case map
-   0429; 0449; Case map
-   042A; 044A; Case map
-   042B; 044B; Case map
-   042C; 044C; Case map
-   042D; 044D; Case map
-   042E; 044E; Case map
-   042F; 044F; Case map
-   0460; 0461; Case map
-   0462; 0463; Case map
-   0464; 0465; Case map
-   0466; 0467; Case map
-   0468; 0469; Case map
-   046A; 046B; Case map
-   046C; 046D; Case map
-   046E; 046F; Case map
-   0470; 0471; Case map
-   0472; 0473; Case map
-   0474; 0475; Case map
-   0476; 0477; Case map
-   0478; 0479; Case map
-   047A; 047B; Case map
-   047C; 047D; Case map
-   047E; 047F; Case map
-   0480; 0481; Case map
-   048A; 048B; Case map
-   048C; 048D; Case map
-   048E; 048F; Case map
-   0490; 0491; Case map
-   0492; 0493; Case map
-   0494; 0495; Case map
-   0496; 0497; Case map
-   0498; 0499; Case map
-   049A; 049B; Case map
-   049C; 049D; Case map
-   049E; 049F; Case map
-   04A0; 04A1; Case map
-   04A2; 04A3; Case map
-   04A4; 04A5; Case map
-   04A6; 04A7; Case map
-   04A8; 04A9; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 39]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   04AA; 04AB; Case map
-   04AC; 04AD; Case map
-   04AE; 04AF; Case map
-   04B0; 04B1; Case map
-   04B2; 04B3; Case map
-   04B4; 04B5; Case map
-   04B6; 04B7; Case map
-   04B8; 04B9; Case map
-   04BA; 04BB; Case map
-   04BC; 04BD; Case map
-   04BE; 04BF; Case map
-   04C1; 04C2; Case map
-   04C3; 04C4; Case map
-   04C5; 04C6; Case map
-   04C7; 04C8; Case map
-   04C9; 04CA; Case map
-   04CB; 04CC; Case map
-   04CD; 04CE; Case map
-   04D0; 04D1; Case map
-   04D2; 04D3; Case map
-   04D4; 04D5; Case map
-   04D6; 04D7; Case map
-   04D8; 04D9; Case map
-   04DA; 04DB; Case map
-   04DC; 04DD; Case map
-   04DE; 04DF; Case map
-   04E0; 04E1; Case map
-   04E2; 04E3; Case map
-   04E4; 04E5; Case map
-   04E6; 04E7; Case map
-   04E8; 04E9; Case map
-   04EA; 04EB; Case map
-   04EC; 04ED; Case map
-   04EE; 04EF; Case map
-   04F0; 04F1; Case map
-   04F2; 04F3; Case map
-   04F4; 04F5; Case map
-   04F8; 04F9; Case map
-   0500; 0501; Case map
-   0502; 0503; Case map
-   0504; 0505; Case map
-   0506; 0507; Case map
-   0508; 0509; Case map
-   050A; 050B; Case map
-   050C; 050D; Case map
-   050E; 050F; Case map
-   0531; 0561; Case map
-   0532; 0562; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 40]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0533; 0563; Case map
-   0534; 0564; Case map
-   0535; 0565; Case map
-   0536; 0566; Case map
-   0537; 0567; Case map
-   0538; 0568; Case map
-   0539; 0569; Case map
-   053A; 056A; Case map
-   053B; 056B; Case map
-   053C; 056C; Case map
-   053D; 056D; Case map
-   053E; 056E; Case map
-   053F; 056F; Case map
-   0540; 0570; Case map
-   0541; 0571; Case map
-   0542; 0572; Case map
-   0543; 0573; Case map
-   0544; 0574; Case map
-   0545; 0575; Case map
-   0546; 0576; Case map
-   0547; 0577; Case map
-   0548; 0578; Case map
-   0549; 0579; Case map
-   054A; 057A; Case map
-   054B; 057B; Case map
-   054C; 057C; Case map
-   054D; 057D; Case map
-   054E; 057E; Case map
-   054F; 057F; Case map
-   0550; 0580; Case map
-   0551; 0581; Case map
-   0552; 0582; Case map
-   0553; 0583; Case map
-   0554; 0584; Case map
-   0555; 0585; Case map
-   0556; 0586; Case map
-   0587; 0565 0582; Case map
-   1E00; 1E01; Case map
-   1E02; 1E03; Case map
-   1E04; 1E05; Case map
-   1E06; 1E07; Case map
-   1E08; 1E09; Case map
-   1E0A; 1E0B; Case map
-   1E0C; 1E0D; Case map
-   1E0E; 1E0F; Case map
-   1E10; 1E11; Case map
-   1E12; 1E13; Case map
-   1E14; 1E15; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 41]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1E16; 1E17; Case map
-   1E18; 1E19; Case map
-   1E1A; 1E1B; Case map
-   1E1C; 1E1D; Case map
-   1E1E; 1E1F; Case map
-   1E20; 1E21; Case map
-   1E22; 1E23; Case map
-   1E24; 1E25; Case map
-   1E26; 1E27; Case map
-   1E28; 1E29; Case map
-   1E2A; 1E2B; Case map
-   1E2C; 1E2D; Case map
-   1E2E; 1E2F; Case map
-   1E30; 1E31; Case map
-   1E32; 1E33; Case map
-   1E34; 1E35; Case map
-   1E36; 1E37; Case map
-   1E38; 1E39; Case map
-   1E3A; 1E3B; Case map
-   1E3C; 1E3D; Case map
-   1E3E; 1E3F; Case map
-   1E40; 1E41; Case map
-   1E42; 1E43; Case map
-   1E44; 1E45; Case map
-   1E46; 1E47; Case map
-   1E48; 1E49; Case map
-   1E4A; 1E4B; Case map
-   1E4C; 1E4D; Case map
-   1E4E; 1E4F; Case map
-   1E50; 1E51; Case map
-   1E52; 1E53; Case map
-   1E54; 1E55; Case map
-   1E56; 1E57; Case map
-   1E58; 1E59; Case map
-   1E5A; 1E5B; Case map
-   1E5C; 1E5D; Case map
-   1E5E; 1E5F; Case map
-   1E60; 1E61; Case map
-   1E62; 1E63; Case map
-   1E64; 1E65; Case map
-   1E66; 1E67; Case map
-   1E68; 1E69; Case map
-   1E6A; 1E6B; Case map
-   1E6C; 1E6D; Case map
-   1E6E; 1E6F; Case map
-   1E70; 1E71; Case map
-   1E72; 1E73; Case map
-   1E74; 1E75; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 42]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1E76; 1E77; Case map
-   1E78; 1E79; Case map
-   1E7A; 1E7B; Case map
-   1E7C; 1E7D; Case map
-   1E7E; 1E7F; Case map
-   1E80; 1E81; Case map
-   1E82; 1E83; Case map
-   1E84; 1E85; Case map
-   1E86; 1E87; Case map
-   1E88; 1E89; Case map
-   1E8A; 1E8B; Case map
-   1E8C; 1E8D; Case map
-   1E8E; 1E8F; Case map
-   1E90; 1E91; Case map
-   1E92; 1E93; Case map
-   1E94; 1E95; Case map
-   1E96; 0068 0331; Case map
-   1E97; 0074 0308; Case map
-   1E98; 0077 030A; Case map
-   1E99; 0079 030A; Case map
-   1E9A; 0061 02BE; Case map
-   1E9B; 1E61; Case map
-   1EA0; 1EA1; Case map
-   1EA2; 1EA3; Case map
-   1EA4; 1EA5; Case map
-   1EA6; 1EA7; Case map
-   1EA8; 1EA9; Case map
-   1EAA; 1EAB; Case map
-   1EAC; 1EAD; Case map
-   1EAE; 1EAF; Case map
-   1EB0; 1EB1; Case map
-   1EB2; 1EB3; Case map
-   1EB4; 1EB5; Case map
-   1EB6; 1EB7; Case map
-   1EB8; 1EB9; Case map
-   1EBA; 1EBB; Case map
-   1EBC; 1EBD; Case map
-   1EBE; 1EBF; Case map
-   1EC0; 1EC1; Case map
-   1EC2; 1EC3; Case map
-   1EC4; 1EC5; Case map
-   1EC6; 1EC7; Case map
-   1EC8; 1EC9; Case map
-   1ECA; 1ECB; Case map
-   1ECC; 1ECD; Case map
-   1ECE; 1ECF; Case map
-   1ED0; 1ED1; Case map
-   1ED2; 1ED3; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 43]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1ED4; 1ED5; Case map
-   1ED6; 1ED7; Case map
-   1ED8; 1ED9; Case map
-   1EDA; 1EDB; Case map
-   1EDC; 1EDD; Case map
-   1EDE; 1EDF; Case map
-   1EE0; 1EE1; Case map
-   1EE2; 1EE3; Case map
-   1EE4; 1EE5; Case map
-   1EE6; 1EE7; Case map
-   1EE8; 1EE9; Case map
-   1EEA; 1EEB; Case map
-   1EEC; 1EED; Case map
-   1EEE; 1EEF; Case map
-   1EF0; 1EF1; Case map
-   1EF2; 1EF3; Case map
-   1EF4; 1EF5; Case map
-   1EF6; 1EF7; Case map
-   1EF8; 1EF9; Case map
-   1F08; 1F00; Case map
-   1F09; 1F01; Case map
-   1F0A; 1F02; Case map
-   1F0B; 1F03; Case map
-   1F0C; 1F04; Case map
-   1F0D; 1F05; Case map
-   1F0E; 1F06; Case map
-   1F0F; 1F07; Case map
-   1F18; 1F10; Case map
-   1F19; 1F11; Case map
-   1F1A; 1F12; Case map
-   1F1B; 1F13; Case map
-   1F1C; 1F14; Case map
-   1F1D; 1F15; Case map
-   1F28; 1F20; Case map
-   1F29; 1F21; Case map
-   1F2A; 1F22; Case map
-   1F2B; 1F23; Case map
-   1F2C; 1F24; Case map
-   1F2D; 1F25; Case map
-   1F2E; 1F26; Case map
-   1F2F; 1F27; Case map
-   1F38; 1F30; Case map
-   1F39; 1F31; Case map
-   1F3A; 1F32; Case map
-   1F3B; 1F33; Case map
-   1F3C; 1F34; Case map
-   1F3D; 1F35; Case map
-   1F3E; 1F36; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 44]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1F3F; 1F37; Case map
-   1F48; 1F40; Case map
-   1F49; 1F41; Case map
-   1F4A; 1F42; Case map
-   1F4B; 1F43; Case map
-   1F4C; 1F44; Case map
-   1F4D; 1F45; Case map
-   1F50; 03C5 0313; Case map
-   1F52; 03C5 0313 0300; Case map
-   1F54; 03C5 0313 0301; Case map
-   1F56; 03C5 0313 0342; Case map
-   1F59; 1F51; Case map
-   1F5B; 1F53; Case map
-   1F5D; 1F55; Case map
-   1F5F; 1F57; Case map
-   1F68; 1F60; Case map
-   1F69; 1F61; Case map
-   1F6A; 1F62; Case map
-   1F6B; 1F63; Case map
-   1F6C; 1F64; Case map
-   1F6D; 1F65; Case map
-   1F6E; 1F66; Case map
-   1F6F; 1F67; Case map
-   1F80; 1F00 03B9; Case map
-   1F81; 1F01 03B9; Case map
-   1F82; 1F02 03B9; Case map
-   1F83; 1F03 03B9; Case map
-   1F84; 1F04 03B9; Case map
-   1F85; 1F05 03B9; Case map
-   1F86; 1F06 03B9; Case map
-   1F87; 1F07 03B9; Case map
-   1F88; 1F00 03B9; Case map
-   1F89; 1F01 03B9; Case map
-   1F8A; 1F02 03B9; Case map
-   1F8B; 1F03 03B9; Case map
-   1F8C; 1F04 03B9; Case map
-   1F8D; 1F05 03B9; Case map
-   1F8E; 1F06 03B9; Case map
-   1F8F; 1F07 03B9; Case map
-   1F90; 1F20 03B9; Case map
-   1F91; 1F21 03B9; Case map
-   1F92; 1F22 03B9; Case map
-   1F93; 1F23 03B9; Case map
-   1F94; 1F24 03B9; Case map
-   1F95; 1F25 03B9; Case map
-   1F96; 1F26 03B9; Case map
-   1F97; 1F27 03B9; Case map
-   1F98; 1F20 03B9; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 45]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1F99; 1F21 03B9; Case map
-   1F9A; 1F22 03B9; Case map
-   1F9B; 1F23 03B9; Case map
-   1F9C; 1F24 03B9; Case map
-   1F9D; 1F25 03B9; Case map
-   1F9E; 1F26 03B9; Case map
-   1F9F; 1F27 03B9; Case map
-   1FA0; 1F60 03B9; Case map
-   1FA1; 1F61 03B9; Case map
-   1FA2; 1F62 03B9; Case map
-   1FA3; 1F63 03B9; Case map
-   1FA4; 1F64 03B9; Case map
-   1FA5; 1F65 03B9; Case map
-   1FA6; 1F66 03B9; Case map
-   1FA7; 1F67 03B9; Case map
-   1FA8; 1F60 03B9; Case map
-   1FA9; 1F61 03B9; Case map
-   1FAA; 1F62 03B9; Case map
-   1FAB; 1F63 03B9; Case map
-   1FAC; 1F64 03B9; Case map
-   1FAD; 1F65 03B9; Case map
-   1FAE; 1F66 03B9; Case map
-   1FAF; 1F67 03B9; Case map
-   1FB2; 1F70 03B9; Case map
-   1FB3; 03B1 03B9; Case map
-   1FB4; 03AC 03B9; Case map
-   1FB6; 03B1 0342; Case map
-   1FB7; 03B1 0342 03B9; Case map
-   1FB8; 1FB0; Case map
-   1FB9; 1FB1; Case map
-   1FBA; 1F70; Case map
-   1FBB; 1F71; Case map
-   1FBC; 03B1 03B9; Case map
-   1FBE; 03B9; Case map
-   1FC2; 1F74 03B9; Case map
-   1FC3; 03B7 03B9; Case map
-   1FC4; 03AE 03B9; Case map
-   1FC6; 03B7 0342; Case map
-   1FC7; 03B7 0342 03B9; Case map
-   1FC8; 1F72; Case map
-   1FC9; 1F73; Case map
-   1FCA; 1F74; Case map
-   1FCB; 1F75; Case map
-   1FCC; 03B7 03B9; Case map
-   1FD2; 03B9 0308 0300; Case map
-   1FD3; 03B9 0308 0301; Case map
-   1FD6; 03B9 0342; Case map
-   1FD7; 03B9 0308 0342; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 46]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1FD8; 1FD0; Case map
-   1FD9; 1FD1; Case map
-   1FDA; 1F76; Case map
-   1FDB; 1F77; Case map
-   1FE2; 03C5 0308 0300; Case map
-   1FE3; 03C5 0308 0301; Case map
-   1FE4; 03C1 0313; Case map
-   1FE6; 03C5 0342; Case map
-   1FE7; 03C5 0308 0342; Case map
-   1FE8; 1FE0; Case map
-   1FE9; 1FE1; Case map
-   1FEA; 1F7A; Case map
-   1FEB; 1F7B; Case map
-   1FEC; 1FE5; Case map
-   1FF2; 1F7C 03B9; Case map
-   1FF3; 03C9 03B9; Case map
-   1FF4; 03CE 03B9; Case map
-   1FF6; 03C9 0342; Case map
-   1FF7; 03C9 0342 03B9; Case map
-   1FF8; 1F78; Case map
-   1FF9; 1F79; Case map
-   1FFA; 1F7C; Case map
-   1FFB; 1F7D; Case map
-   1FFC; 03C9 03B9; Case map
-   20A8; 0072 0073; Additional folding
-   2102; 0063; Additional folding
-   2103; 00B0 0063; Additional folding
-   2107; 025B; Additional folding
-   2109; 00B0 0066; Additional folding
-   210B; 0068; Additional folding
-   210C; 0068; Additional folding
-   210D; 0068; Additional folding
-   2110; 0069; Additional folding
-   2111; 0069; Additional folding
-   2112; 006C; Additional folding
-   2115; 006E; Additional folding
-   2116; 006E 006F; Additional folding
-   2119; 0070; Additional folding
-   211A; 0071; Additional folding
-   211B; 0072; Additional folding
-   211C; 0072; Additional folding
-   211D; 0072; Additional folding
-   2120; 0073 006D; Additional folding
-   2121; 0074 0065 006C; Additional folding
-   2122; 0074 006D; Additional folding
-   2124; 007A; Additional folding
-   2126; 03C9; Case map
-   2128; 007A; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 47]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   212A; 006B; Case map
-   212B; 00E5; Case map
-   212C; 0062; Additional folding
-   212D; 0063; Additional folding
-   2130; 0065; Additional folding
-   2131; 0066; Additional folding
-   2133; 006D; Additional folding
-   213E; 03B3; Additional folding
-   213F; 03C0; Additional folding
-   2145; 0064; Additional folding
-   2160; 2170; Case map
-   2161; 2171; Case map
-   2162; 2172; Case map
-   2163; 2173; Case map
-   2164; 2174; Case map
-   2165; 2175; Case map
-   2166; 2176; Case map
-   2167; 2177; Case map
-   2168; 2178; Case map
-   2169; 2179; Case map
-   216A; 217A; Case map
-   216B; 217B; Case map
-   216C; 217C; Case map
-   216D; 217D; Case map
-   216E; 217E; Case map
-   216F; 217F; Case map
-   24B6; 24D0; Case map
-   24B7; 24D1; Case map
-   24B8; 24D2; Case map
-   24B9; 24D3; Case map
-   24BA; 24D4; Case map
-   24BB; 24D5; Case map
-   24BC; 24D6; Case map
-   24BD; 24D7; Case map
-   24BE; 24D8; Case map
-   24BF; 24D9; Case map
-   24C0; 24DA; Case map
-   24C1; 24DB; Case map
-   24C2; 24DC; Case map
-   24C3; 24DD; Case map
-   24C4; 24DE; Case map
-   24C5; 24DF; Case map
-   24C6; 24E0; Case map
-   24C7; 24E1; Case map
-   24C8; 24E2; Case map
-   24C9; 24E3; Case map
-   24CA; 24E4; Case map
-   24CB; 24E5; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 48]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   24CC; 24E6; Case map
-   24CD; 24E7; Case map
-   24CE; 24E8; Case map
-   24CF; 24E9; Case map
-   3371; 0068 0070 0061; Additional folding
-   3373; 0061 0075; Additional folding
-   3375; 006F 0076; Additional folding
-   3380; 0070 0061; Additional folding
-   3381; 006E 0061; Additional folding
-   3382; 03BC 0061; Additional folding
-   3383; 006D 0061; Additional folding
-   3384; 006B 0061; Additional folding
-   3385; 006B 0062; Additional folding
-   3386; 006D 0062; Additional folding
-   3387; 0067 0062; Additional folding
-   338A; 0070 0066; Additional folding
-   338B; 006E 0066; Additional folding
-   338C; 03BC 0066; Additional folding
-   3390; 0068 007A; Additional folding
-   3391; 006B 0068 007A; Additional folding
-   3392; 006D 0068 007A; Additional folding
-   3393; 0067 0068 007A; Additional folding
-   3394; 0074 0068 007A; Additional folding
-   33A9; 0070 0061; Additional folding
-   33AA; 006B 0070 0061; Additional folding
-   33AB; 006D 0070 0061; Additional folding
-   33AC; 0067 0070 0061; Additional folding
-   33B4; 0070 0076; Additional folding
-   33B5; 006E 0076; Additional folding
-   33B6; 03BC 0076; Additional folding
-   33B7; 006D 0076; Additional folding
-   33B8; 006B 0076; Additional folding
-   33B9; 006D 0076; Additional folding
-   33BA; 0070 0077; Additional folding
-   33BB; 006E 0077; Additional folding
-   33BC; 03BC 0077; Additional folding
-   33BD; 006D 0077; Additional folding
-   33BE; 006B 0077; Additional folding
-   33BF; 006D 0077; Additional folding
-   33C0; 006B 03C9; Additional folding
-   33C1; 006D 03C9; Additional folding
-   33C3; 0062 0071; Additional folding
-   33C6; 0063 2215 006B 0067; Additional folding
-   33C7; 0063 006F 002E; Additional folding
-   33C8; 0064 0062; Additional folding
-   33C9; 0067 0079; Additional folding
-   33CB; 0068 0070; Additional folding
-   33CD; 006B 006B; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 49]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   33CE; 006B 006D; Additional folding
-   33D7; 0070 0068; Additional folding
-   33D9; 0070 0070 006D; Additional folding
-   33DA; 0070 0072; Additional folding
-   33DC; 0073 0076; Additional folding
-   33DD; 0077 0062; Additional folding
-   FB00; 0066 0066; Case map
-   FB01; 0066 0069; Case map
-   FB02; 0066 006C; Case map
-   FB03; 0066 0066 0069; Case map
-   FB04; 0066 0066 006C; Case map
-   FB05; 0073 0074; Case map
-   FB06; 0073 0074; Case map
-   FB13; 0574 0576; Case map
-   FB14; 0574 0565; Case map
-   FB15; 0574 056B; Case map
-   FB16; 057E 0576; Case map
-   FB17; 0574 056D; Case map
-   FF21; FF41; Case map
-   FF22; FF42; Case map
-   FF23; FF43; Case map
-   FF24; FF44; Case map
-   FF25; FF45; Case map
-   FF26; FF46; Case map
-   FF27; FF47; Case map
-   FF28; FF48; Case map
-   FF29; FF49; Case map
-   FF2A; FF4A; Case map
-   FF2B; FF4B; Case map
-   FF2C; FF4C; Case map
-   FF2D; FF4D; Case map
-   FF2E; FF4E; Case map
-   FF2F; FF4F; Case map
-   FF30; FF50; Case map
-   FF31; FF51; Case map
-   FF32; FF52; Case map
-   FF33; FF53; Case map
-   FF34; FF54; Case map
-   FF35; FF55; Case map
-   FF36; FF56; Case map
-   FF37; FF57; Case map
-   FF38; FF58; Case map
-   FF39; FF59; Case map
-   FF3A; FF5A; Case map
-   10400; 10428; Case map
-   10401; 10429; Case map
-   10402; 1042A; Case map
-   10403; 1042B; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 50]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   10404; 1042C; Case map
-   10405; 1042D; Case map
-   10406; 1042E; Case map
-   10407; 1042F; Case map
-   10408; 10430; Case map
-   10409; 10431; Case map
-   1040A; 10432; Case map
-   1040B; 10433; Case map
-   1040C; 10434; Case map
-   1040D; 10435; Case map
-   1040E; 10436; Case map
-   1040F; 10437; Case map
-   10410; 10438; Case map
-   10411; 10439; Case map
-   10412; 1043A; Case map
-   10413; 1043B; Case map
-   10414; 1043C; Case map
-   10415; 1043D; Case map
-   10416; 1043E; Case map
-   10417; 1043F; Case map
-   10418; 10440; Case map
-   10419; 10441; Case map
-   1041A; 10442; Case map
-   1041B; 10443; Case map
-   1041C; 10444; Case map
-   1041D; 10445; Case map
-   1041E; 10446; Case map
-   1041F; 10447; Case map
-   10420; 10448; Case map
-   10421; 10449; Case map
-   10422; 1044A; Case map
-   10423; 1044B; Case map
-   10424; 1044C; Case map
-   10425; 1044D; Case map
-   1D400; 0061; Additional folding
-   1D401; 0062; Additional folding
-   1D402; 0063; Additional folding
-   1D403; 0064; Additional folding
-   1D404; 0065; Additional folding
-   1D405; 0066; Additional folding
-   1D406; 0067; Additional folding
-   1D407; 0068; Additional folding
-   1D408; 0069; Additional folding
-   1D409; 006A; Additional folding
-   1D40A; 006B; Additional folding
-   1D40B; 006C; Additional folding
-   1D40C; 006D; Additional folding
-   1D40D; 006E; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 51]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D40E; 006F; Additional folding
-   1D40F; 0070; Additional folding
-   1D410; 0071; Additional folding
-   1D411; 0072; Additional folding
-   1D412; 0073; Additional folding
-   1D413; 0074; Additional folding
-   1D414; 0075; Additional folding
-   1D415; 0076; Additional folding
-   1D416; 0077; Additional folding
-   1D417; 0078; Additional folding
-   1D418; 0079; Additional folding
-   1D419; 007A; Additional folding
-   1D434; 0061; Additional folding
-   1D435; 0062; Additional folding
-   1D436; 0063; Additional folding
-   1D437; 0064; Additional folding
-   1D438; 0065; Additional folding
-   1D439; 0066; Additional folding
-   1D43A; 0067; Additional folding
-   1D43B; 0068; Additional folding
-   1D43C; 0069; Additional folding
-   1D43D; 006A; Additional folding
-   1D43E; 006B; Additional folding
-   1D43F; 006C; Additional folding
-   1D440; 006D; Additional folding
-   1D441; 006E; Additional folding
-   1D442; 006F; Additional folding
-   1D443; 0070; Additional folding
-   1D444; 0071; Additional folding
-   1D445; 0072; Additional folding
-   1D446; 0073; Additional folding
-   1D447; 0074; Additional folding
-   1D448; 0075; Additional folding
-   1D449; 0076; Additional folding
-   1D44A; 0077; Additional folding
-   1D44B; 0078; Additional folding
-   1D44C; 0079; Additional folding
-   1D44D; 007A; Additional folding
-   1D468; 0061; Additional folding
-   1D469; 0062; Additional folding
-   1D46A; 0063; Additional folding
-   1D46B; 0064; Additional folding
-   1D46C; 0065; Additional folding
-   1D46D; 0066; Additional folding
-   1D46E; 0067; Additional folding
-   1D46F; 0068; Additional folding
-   1D470; 0069; Additional folding
-   1D471; 006A; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 52]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D472; 006B; Additional folding
-   1D473; 006C; Additional folding
-   1D474; 006D; Additional folding
-   1D475; 006E; Additional folding
-   1D476; 006F; Additional folding
-   1D477; 0070; Additional folding
-   1D478; 0071; Additional folding
-   1D479; 0072; Additional folding
-   1D47A; 0073; Additional folding
-   1D47B; 0074; Additional folding
-   1D47C; 0075; Additional folding
-   1D47D; 0076; Additional folding
-   1D47E; 0077; Additional folding
-   1D47F; 0078; Additional folding
-   1D480; 0079; Additional folding
-   1D481; 007A; Additional folding
-   1D49C; 0061; Additional folding
-   1D49E; 0063; Additional folding
-   1D49F; 0064; Additional folding
-   1D4A2; 0067; Additional folding
-   1D4A5; 006A; Additional folding
-   1D4A6; 006B; Additional folding
-   1D4A9; 006E; Additional folding
-   1D4AA; 006F; Additional folding
-   1D4AB; 0070; Additional folding
-   1D4AC; 0071; Additional folding
-   1D4AE; 0073; Additional folding
-   1D4AF; 0074; Additional folding
-   1D4B0; 0075; Additional folding
-   1D4B1; 0076; Additional folding
-   1D4B2; 0077; Additional folding
-   1D4B3; 0078; Additional folding
-   1D4B4; 0079; Additional folding
-   1D4B5; 007A; Additional folding
-   1D4D0; 0061; Additional folding
-   1D4D1; 0062; Additional folding
-   1D4D2; 0063; Additional folding
-   1D4D3; 0064; Additional folding
-   1D4D4; 0065; Additional folding
-   1D4D5; 0066; Additional folding
-   1D4D6; 0067; Additional folding
-   1D4D7; 0068; Additional folding
-   1D4D8; 0069; Additional folding
-   1D4D9; 006A; Additional folding
-   1D4DA; 006B; Additional folding
-   1D4DB; 006C; Additional folding
-   1D4DC; 006D; Additional folding
-   1D4DD; 006E; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 53]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D4DE; 006F; Additional folding
-   1D4DF; 0070; Additional folding
-   1D4E0; 0071; Additional folding
-   1D4E1; 0072; Additional folding
-   1D4E2; 0073; Additional folding
-   1D4E3; 0074; Additional folding
-   1D4E4; 0075; Additional folding
-   1D4E5; 0076; Additional folding
-   1D4E6; 0077; Additional folding
-   1D4E7; 0078; Additional folding
-   1D4E8; 0079; Additional folding
-   1D4E9; 007A; Additional folding
-   1D504; 0061; Additional folding
-   1D505; 0062; Additional folding
-   1D507; 0064; Additional folding
-   1D508; 0065; Additional folding
-   1D509; 0066; Additional folding
-   1D50A; 0067; Additional folding
-   1D50D; 006A; Additional folding
-   1D50E; 006B; Additional folding
-   1D50F; 006C; Additional folding
-   1D510; 006D; Additional folding
-   1D511; 006E; Additional folding
-   1D512; 006F; Additional folding
-   1D513; 0070; Additional folding
-   1D514; 0071; Additional folding
-   1D516; 0073; Additional folding
-   1D517; 0074; Additional folding
-   1D518; 0075; Additional folding
-   1D519; 0076; Additional folding
-   1D51A; 0077; Additional folding
-   1D51B; 0078; Additional folding
-   1D51C; 0079; Additional folding
-   1D538; 0061; Additional folding
-   1D539; 0062; Additional folding
-   1D53B; 0064; Additional folding
-   1D53C; 0065; Additional folding
-   1D53D; 0066; Additional folding
-   1D53E; 0067; Additional folding
-   1D540; 0069; Additional folding
-   1D541; 006A; Additional folding
-   1D542; 006B; Additional folding
-   1D543; 006C; Additional folding
-   1D544; 006D; Additional folding
-   1D546; 006F; Additional folding
-   1D54A; 0073; Additional folding
-   1D54B; 0074; Additional folding
-   1D54C; 0075; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 54]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D54D; 0076; Additional folding
-   1D54E; 0077; Additional folding
-   1D54F; 0078; Additional folding
-   1D550; 0079; Additional folding
-   1D56C; 0061; Additional folding
-   1D56D; 0062; Additional folding
-   1D56E; 0063; Additional folding
-   1D56F; 0064; Additional folding
-   1D570; 0065; Additional folding
-   1D571; 0066; Additional folding
-   1D572; 0067; Additional folding
-   1D573; 0068; Additional folding
-   1D574; 0069; Additional folding
-   1D575; 006A; Additional folding
-   1D576; 006B; Additional folding
-   1D577; 006C; Additional folding
-   1D578; 006D; Additional folding
-   1D579; 006E; Additional folding
-   1D57A; 006F; Additional folding
-   1D57B; 0070; Additional folding
-   1D57C; 0071; Additional folding
-   1D57D; 0072; Additional folding
-   1D57E; 0073; Additional folding
-   1D57F; 0074; Additional folding
-   1D580; 0075; Additional folding
-   1D581; 0076; Additional folding
-   1D582; 0077; Additional folding
-   1D583; 0078; Additional folding
-   1D584; 0079; Additional folding
-   1D585; 007A; Additional folding
-   1D5A0; 0061; Additional folding
-   1D5A1; 0062; Additional folding
-   1D5A2; 0063; Additional folding
-   1D5A3; 0064; Additional folding
-   1D5A4; 0065; Additional folding
-   1D5A5; 0066; Additional folding
-   1D5A6; 0067; Additional folding
-   1D5A7; 0068; Additional folding
-   1D5A8; 0069; Additional folding
-   1D5A9; 006A; Additional folding
-   1D5AA; 006B; Additional folding
-   1D5AB; 006C; Additional folding
-   1D5AC; 006D; Additional folding
-   1D5AD; 006E; Additional folding
-   1D5AE; 006F; Additional folding
-   1D5AF; 0070; Additional folding
-   1D5B0; 0071; Additional folding
-   1D5B1; 0072; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 55]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D5B2; 0073; Additional folding
-   1D5B3; 0074; Additional folding
-   1D5B4; 0075; Additional folding
-   1D5B5; 0076; Additional folding
-   1D5B6; 0077; Additional folding
-   1D5B7; 0078; Additional folding
-   1D5B8; 0079; Additional folding
-   1D5B9; 007A; Additional folding
-   1D5D4; 0061; Additional folding
-   1D5D5; 0062; Additional folding
-   1D5D6; 0063; Additional folding
-   1D5D7; 0064; Additional folding
-   1D5D8; 0065; Additional folding
-   1D5D9; 0066; Additional folding
-   1D5DA; 0067; Additional folding
-   1D5DB; 0068; Additional folding
-   1D5DC; 0069; Additional folding
-   1D5DD; 006A; Additional folding
-   1D5DE; 006B; Additional folding
-   1D5DF; 006C; Additional folding
-   1D5E0; 006D; Additional folding
-   1D5E1; 006E; Additional folding
-   1D5E2; 006F; Additional folding
-   1D5E3; 0070; Additional folding
-   1D5E4; 0071; Additional folding
-   1D5E5; 0072; Additional folding
-   1D5E6; 0073; Additional folding
-   1D5E7; 0074; Additional folding
-   1D5E8; 0075; Additional folding
-   1D5E9; 0076; Additional folding
-   1D5EA; 0077; Additional folding
-   1D5EB; 0078; Additional folding
-   1D5EC; 0079; Additional folding
-   1D5ED; 007A; Additional folding
-   1D608; 0061; Additional folding
-   1D609; 0062; Additional folding
-   1D60A; 0063; Additional folding
-   1D60B; 0064; Additional folding
-   1D60C; 0065; Additional folding
-   1D60D; 0066; Additional folding
-   1D60E; 0067; Additional folding
-   1D60F; 0068; Additional folding
-   1D610; 0069; Additional folding
-   1D611; 006A; Additional folding
-   1D612; 006B; Additional folding
-   1D613; 006C; Additional folding
-   1D614; 006D; Additional folding
-   1D615; 006E; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 56]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D616; 006F; Additional folding
-   1D617; 0070; Additional folding
-   1D618; 0071; Additional folding
-   1D619; 0072; Additional folding
-   1D61A; 0073; Additional folding
-   1D61B; 0074; Additional folding
-   1D61C; 0075; Additional folding
-   1D61D; 0076; Additional folding
-   1D61E; 0077; Additional folding
-   1D61F; 0078; Additional folding
-   1D620; 0079; Additional folding
-   1D621; 007A; Additional folding
-   1D63C; 0061; Additional folding
-   1D63D; 0062; Additional folding
-   1D63E; 0063; Additional folding
-   1D63F; 0064; Additional folding
-   1D640; 0065; Additional folding
-   1D641; 0066; Additional folding
-   1D642; 0067; Additional folding
-   1D643; 0068; Additional folding
-   1D644; 0069; Additional folding
-   1D645; 006A; Additional folding
-   1D646; 006B; Additional folding
-   1D647; 006C; Additional folding
-   1D648; 006D; Additional folding
-   1D649; 006E; Additional folding
-   1D64A; 006F; Additional folding
-   1D64B; 0070; Additional folding
-   1D64C; 0071; Additional folding
-   1D64D; 0072; Additional folding
-   1D64E; 0073; Additional folding
-   1D64F; 0074; Additional folding
-   1D650; 0075; Additional folding
-   1D651; 0076; Additional folding
-   1D652; 0077; Additional folding
-   1D653; 0078; Additional folding
-   1D654; 0079; Additional folding
-   1D655; 007A; Additional folding
-   1D670; 0061; Additional folding
-   1D671; 0062; Additional folding
-   1D672; 0063; Additional folding
-   1D673; 0064; Additional folding
-   1D674; 0065; Additional folding
-   1D675; 0066; Additional folding
-   1D676; 0067; Additional folding
-   1D677; 0068; Additional folding
-   1D678; 0069; Additional folding
-   1D679; 006A; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 57]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D67A; 006B; Additional folding
-   1D67B; 006C; Additional folding
-   1D67C; 006D; Additional folding
-   1D67D; 006E; Additional folding
-   1D67E; 006F; Additional folding
-   1D67F; 0070; Additional folding
-   1D680; 0071; Additional folding
-   1D681; 0072; Additional folding
-   1D682; 0073; Additional folding
-   1D683; 0074; Additional folding
-   1D684; 0075; Additional folding
-   1D685; 0076; Additional folding
-   1D686; 0077; Additional folding
-   1D687; 0078; Additional folding
-   1D688; 0079; Additional folding
-   1D689; 007A; Additional folding
-   1D6A8; 03B1; Additional folding
-   1D6A9; 03B2; Additional folding
-   1D6AA; 03B3; Additional folding
-   1D6AB; 03B4; Additional folding
-   1D6AC; 03B5; Additional folding
-   1D6AD; 03B6; Additional folding
-   1D6AE; 03B7; Additional folding
-   1D6AF; 03B8; Additional folding
-   1D6B0; 03B9; Additional folding
-   1D6B1; 03BA; Additional folding
-   1D6B2; 03BB; Additional folding
-   1D6B3; 03BC; Additional folding
-   1D6B4; 03BD; Additional folding
-   1D6B5; 03BE; Additional folding
-   1D6B6; 03BF; Additional folding
-   1D6B7; 03C0; Additional folding
-   1D6B8; 03C1; Additional folding
-   1D6B9; 03B8; Additional folding
-   1D6BA; 03C3; Additional folding
-   1D6BB; 03C4; Additional folding
-   1D6BC; 03C5; Additional folding
-   1D6BD; 03C6; Additional folding
-   1D6BE; 03C7; Additional folding
-   1D6BF; 03C8; Additional folding
-   1D6C0; 03C9; Additional folding
-   1D6D3; 03C3; Additional folding
-   1D6E2; 03B1; Additional folding
-   1D6E3; 03B2; Additional folding
-   1D6E4; 03B3; Additional folding
-   1D6E5; 03B4; Additional folding
-   1D6E6; 03B5; Additional folding
-   1D6E7; 03B6; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 58]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D6E8; 03B7; Additional folding
-   1D6E9; 03B8; Additional folding
-   1D6EA; 03B9; Additional folding
-   1D6EB; 03BA; Additional folding
-   1D6EC; 03BB; Additional folding
-   1D6ED; 03BC; Additional folding
-   1D6EE; 03BD; Additional folding
-   1D6EF; 03BE; Additional folding
-   1D6F0; 03BF; Additional folding
-   1D6F1; 03C0; Additional folding
-   1D6F2; 03C1; Additional folding
-   1D6F3; 03B8; Additional folding
-   1D6F4; 03C3; Additional folding
-   1D6F5; 03C4; Additional folding
-   1D6F6; 03C5; Additional folding
-   1D6F7; 03C6; Additional folding
-   1D6F8; 03C7; Additional folding
-   1D6F9; 03C8; Additional folding
-   1D6FA; 03C9; Additional folding
-   1D70D; 03C3; Additional folding
-   1D71C; 03B1; Additional folding
-   1D71D; 03B2; Additional folding
-   1D71E; 03B3; Additional folding
-   1D71F; 03B4; Additional folding
-   1D720; 03B5; Additional folding
-   1D721; 03B6; Additional folding
-   1D722; 03B7; Additional folding
-   1D723; 03B8; Additional folding
-   1D724; 03B9; Additional folding
-   1D725; 03BA; Additional folding
-   1D726; 03BB; Additional folding
-   1D727; 03BC; Additional folding
-   1D728; 03BD; Additional folding
-   1D729; 03BE; Additional folding
-   1D72A; 03BF; Additional folding
-   1D72B; 03C0; Additional folding
-   1D72C; 03C1; Additional folding
-   1D72D; 03B8; Additional folding
-   1D72E; 03C3; Additional folding
-   1D72F; 03C4; Additional folding
-   1D730; 03C5; Additional folding
-   1D731; 03C6; Additional folding
-   1D732; 03C7; Additional folding
-   1D733; 03C8; Additional folding
-   1D734; 03C9; Additional folding
-   1D747; 03C3; Additional folding
-   1D756; 03B1; Additional folding
-   1D757; 03B2; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 59]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D758; 03B3; Additional folding
-   1D759; 03B4; Additional folding
-   1D75A; 03B5; Additional folding
-   1D75B; 03B6; Additional folding
-   1D75C; 03B7; Additional folding
-   1D75D; 03B8; Additional folding
-   1D75E; 03B9; Additional folding
-   1D75F; 03BA; Additional folding
-   1D760; 03BB; Additional folding
-   1D761; 03BC; Additional folding
-   1D762; 03BD; Additional folding
-   1D763; 03BE; Additional folding
-   1D764; 03BF; Additional folding
-   1D765; 03C0; Additional folding
-   1D766; 03C1; Additional folding
-   1D767; 03B8; Additional folding
-   1D768; 03C3; Additional folding
-   1D769; 03C4; Additional folding
-   1D76A; 03C5; Additional folding
-   1D76B; 03C6; Additional folding
-   1D76C; 03C7; Additional folding
-   1D76D; 03C8; Additional folding
-   1D76E; 03C9; Additional folding
-   1D781; 03C3; Additional folding
-   1D790; 03B1; Additional folding
-   1D791; 03B2; Additional folding
-   1D792; 03B3; Additional folding
-   1D793; 03B4; Additional folding
-   1D794; 03B5; Additional folding
-   1D795; 03B6; Additional folding
-   1D796; 03B7; Additional folding
-   1D797; 03B8; Additional folding
-   1D798; 03B9; Additional folding
-   1D799; 03BA; Additional folding
-   1D79A; 03BB; Additional folding
-   1D79B; 03BC; Additional folding
-   1D79C; 03BD; Additional folding
-   1D79D; 03BE; Additional folding
-   1D79E; 03BF; Additional folding
-   1D79F; 03C0; Additional folding
-   1D7A0; 03C1; Additional folding
-   1D7A1; 03B8; Additional folding
-   1D7A2; 03C3; Additional folding
-   1D7A3; 03C4; Additional folding
-   1D7A4; 03C5; Additional folding
-   1D7A5; 03C6; Additional folding
-   1D7A6; 03C7; Additional folding
-   1D7A7; 03C8; Additional folding
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 60]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D7A8; 03C9; Additional folding
-   1D7BB; 03C3; Additional folding
-   ----- End Table B.2 -----
-
-B.3 Mapping for case-folding used with no normalization
-
-   ----- Start Table B.3 -----
-   0041; 0061; Case map
-   0042; 0062; Case map
-   0043; 0063; Case map
-   0044; 0064; Case map
-   0045; 0065; Case map
-   0046; 0066; Case map
-   0047; 0067; Case map
-   0048; 0068; Case map
-   0049; 0069; Case map
-   004A; 006A; Case map
-   004B; 006B; Case map
-   004C; 006C; Case map
-   004D; 006D; Case map
-   004E; 006E; Case map
-   004F; 006F; Case map
-   0050; 0070; Case map
-   0051; 0071; Case map
-   0052; 0072; Case map
-   0053; 0073; Case map
-   0054; 0074; Case map
-   0055; 0075; Case map
-   0056; 0076; Case map
-   0057; 0077; Case map
-   0058; 0078; Case map
-   0059; 0079; Case map
-   005A; 007A; Case map
-   00B5; 03BC; Case map
-   00C0; 00E0; Case map
-   00C1; 00E1; Case map
-   00C2; 00E2; Case map
-   00C3; 00E3; Case map
-   00C4; 00E4; Case map
-   00C5; 00E5; Case map
-   00C6; 00E6; Case map
-   00C7; 00E7; Case map
-   00C8; 00E8; Case map
-   00C9; 00E9; Case map
-   00CA; 00EA; Case map
-   00CB; 00EB; Case map
-   00CC; 00EC; Case map
-   00CD; 00ED; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 61]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   00CE; 00EE; Case map
-   00CF; 00EF; Case map
-   00D0; 00F0; Case map
-   00D1; 00F1; Case map
-   00D2; 00F2; Case map
-   00D3; 00F3; Case map
-   00D4; 00F4; Case map
-   00D5; 00F5; Case map
-   00D6; 00F6; Case map
-   00D8; 00F8; Case map
-   00D9; 00F9; Case map
-   00DA; 00FA; Case map
-   00DB; 00FB; Case map
-   00DC; 00FC; Case map
-   00DD; 00FD; Case map
-   00DE; 00FE; Case map
-   00DF; 0073 0073; Case map
-   0100; 0101; Case map
-   0102; 0103; Case map
-   0104; 0105; Case map
-   0106; 0107; Case map
-   0108; 0109; Case map
-   010A; 010B; Case map
-   010C; 010D; Case map
-   010E; 010F; Case map
-   0110; 0111; Case map
-   0112; 0113; Case map
-   0114; 0115; Case map
-   0116; 0117; Case map
-   0118; 0119; Case map
-   011A; 011B; Case map
-   011C; 011D; Case map
-   011E; 011F; Case map
-   0120; 0121; Case map
-   0122; 0123; Case map
-   0124; 0125; Case map
-   0126; 0127; Case map
-   0128; 0129; Case map
-   012A; 012B; Case map
-   012C; 012D; Case map
-   012E; 012F; Case map
-   0130; 0069 0307; Case map
-   0132; 0133; Case map
-   0134; 0135; Case map
-   0136; 0137; Case map
-   0139; 013A; Case map
-   013B; 013C; Case map
-   013D; 013E; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 62]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   013F; 0140; Case map
-   0141; 0142; Case map
-   0143; 0144; Case map
-   0145; 0146; Case map
-   0147; 0148; Case map
-   0149; 02BC 006E; Case map
-   014A; 014B; Case map
-   014C; 014D; Case map
-   014E; 014F; Case map
-   0150; 0151; Case map
-   0152; 0153; Case map
-   0154; 0155; Case map
-   0156; 0157; Case map
-   0158; 0159; Case map
-   015A; 015B; Case map
-   015C; 015D; Case map
-   015E; 015F; Case map
-   0160; 0161; Case map
-   0162; 0163; Case map
-   0164; 0165; Case map
-   0166; 0167; Case map
-   0168; 0169; Case map
-   016A; 016B; Case map
-   016C; 016D; Case map
-   016E; 016F; Case map
-   0170; 0171; Case map
-   0172; 0173; Case map
-   0174; 0175; Case map
-   0176; 0177; Case map
-   0178; 00FF; Case map
-   0179; 017A; Case map
-   017B; 017C; Case map
-   017D; 017E; Case map
-   017F; 0073; Case map
-   0181; 0253; Case map
-   0182; 0183; Case map
-   0184; 0185; Case map
-   0186; 0254; Case map
-   0187; 0188; Case map
-   0189; 0256; Case map
-   018A; 0257; Case map
-   018B; 018C; Case map
-   018E; 01DD; Case map
-   018F; 0259; Case map
-   0190; 025B; Case map
-   0191; 0192; Case map
-   0193; 0260; Case map
-   0194; 0263; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 63]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0196; 0269; Case map
-   0197; 0268; Case map
-   0198; 0199; Case map
-   019C; 026F; Case map
-   019D; 0272; Case map
-   019F; 0275; Case map
-   01A0; 01A1; Case map
-   01A2; 01A3; Case map
-   01A4; 01A5; Case map
-   01A6; 0280; Case map
-   01A7; 01A8; Case map
-   01A9; 0283; Case map
-   01AC; 01AD; Case map
-   01AE; 0288; Case map
-   01AF; 01B0; Case map
-   01B1; 028A; Case map
-   01B2; 028B; Case map
-   01B3; 01B4; Case map
-   01B5; 01B6; Case map
-   01B7; 0292; Case map
-   01B8; 01B9; Case map
-   01BC; 01BD; Case map
-   01C4; 01C6; Case map
-   01C5; 01C6; Case map
-   01C7; 01C9; Case map
-   01C8; 01C9; Case map
-   01CA; 01CC; Case map
-   01CB; 01CC; Case map
-   01CD; 01CE; Case map
-   01CF; 01D0; Case map
-   01D1; 01D2; Case map
-   01D3; 01D4; Case map
-   01D5; 01D6; Case map
-   01D7; 01D8; Case map
-   01D9; 01DA; Case map
-   01DB; 01DC; Case map
-   01DE; 01DF; Case map
-   01E0; 01E1; Case map
-   01E2; 01E3; Case map
-   01E4; 01E5; Case map
-   01E6; 01E7; Case map
-   01E8; 01E9; Case map
-   01EA; 01EB; Case map
-   01EC; 01ED; Case map
-   01EE; 01EF; Case map
-   01F0; 006A 030C; Case map
-   01F1; 01F3; Case map
-   01F2; 01F3; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 64]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   01F4; 01F5; Case map
-   01F6; 0195; Case map
-   01F7; 01BF; Case map
-   01F8; 01F9; Case map
-   01FA; 01FB; Case map
-   01FC; 01FD; Case map
-   01FE; 01FF; Case map
-   0200; 0201; Case map
-   0202; 0203; Case map
-   0204; 0205; Case map
-   0206; 0207; Case map
-   0208; 0209; Case map
-   020A; 020B; Case map
-   020C; 020D; Case map
-   020E; 020F; Case map
-   0210; 0211; Case map
-   0212; 0213; Case map
-   0214; 0215; Case map
-   0216; 0217; Case map
-   0218; 0219; Case map
-   021A; 021B; Case map
-   021C; 021D; Case map
-   021E; 021F; Case map
-   0220; 019E; Case map
-   0222; 0223; Case map
-   0224; 0225; Case map
-   0226; 0227; Case map
-   0228; 0229; Case map
-   022A; 022B; Case map
-   022C; 022D; Case map
-   022E; 022F; Case map
-   0230; 0231; Case map
-   0232; 0233; Case map
-   0345; 03B9; Case map
-   0386; 03AC; Case map
-   0388; 03AD; Case map
-   0389; 03AE; Case map
-   038A; 03AF; Case map
-   038C; 03CC; Case map
-   038E; 03CD; Case map
-   038F; 03CE; Case map
-   0390; 03B9 0308 0301; Case map
-   0391; 03B1; Case map
-   0392; 03B2; Case map
-   0393; 03B3; Case map
-   0394; 03B4; Case map
-   0395; 03B5; Case map
-   0396; 03B6; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 65]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0397; 03B7; Case map
-   0398; 03B8; Case map
-   0399; 03B9; Case map
-   039A; 03BA; Case map
-   039B; 03BB; Case map
-   039C; 03BC; Case map
-   039D; 03BD; Case map
-   039E; 03BE; Case map
-   039F; 03BF; Case map
-   03A0; 03C0; Case map
-   03A1; 03C1; Case map
-   03A3; 03C3; Case map
-   03A4; 03C4; Case map
-   03A5; 03C5; Case map
-   03A6; 03C6; Case map
-   03A7; 03C7; Case map
-   03A8; 03C8; Case map
-   03A9; 03C9; Case map
-   03AA; 03CA; Case map
-   03AB; 03CB; Case map
-   03B0; 03C5 0308 0301; Case map
-   03C2; 03C3; Case map
-   03D0; 03B2; Case map
-   03D1; 03B8; Case map
-   03D5; 03C6; Case map
-   03D6; 03C0; Case map
-   03D8; 03D9; Case map
-   03DA; 03DB; Case map
-   03DC; 03DD; Case map
-   03DE; 03DF; Case map
-   03E0; 03E1; Case map
-   03E2; 03E3; Case map
-   03E4; 03E5; Case map
-   03E6; 03E7; Case map
-   03E8; 03E9; Case map
-   03EA; 03EB; Case map
-   03EC; 03ED; Case map
-   03EE; 03EF; Case map
-   03F0; 03BA; Case map
-   03F1; 03C1; Case map
-   03F2; 03C3; Case map
-   03F4; 03B8; Case map
-   03F5; 03B5; Case map
-   0400; 0450; Case map
-   0401; 0451; Case map
-   0402; 0452; Case map
-   0403; 0453; Case map
-   0404; 0454; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 66]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0405; 0455; Case map
-   0406; 0456; Case map
-   0407; 0457; Case map
-   0408; 0458; Case map
-   0409; 0459; Case map
-   040A; 045A; Case map
-   040B; 045B; Case map
-   040C; 045C; Case map
-   040D; 045D; Case map
-   040E; 045E; Case map
-   040F; 045F; Case map
-   0410; 0430; Case map
-   0411; 0431; Case map
-   0412; 0432; Case map
-   0413; 0433; Case map
-   0414; 0434; Case map
-   0415; 0435; Case map
-   0416; 0436; Case map
-   0417; 0437; Case map
-   0418; 0438; Case map
-   0419; 0439; Case map
-   041A; 043A; Case map
-   041B; 043B; Case map
-   041C; 043C; Case map
-   041D; 043D; Case map
-   041E; 043E; Case map
-   041F; 043F; Case map
-   0420; 0440; Case map
-   0421; 0441; Case map
-   0422; 0442; Case map
-   0423; 0443; Case map
-   0424; 0444; Case map
-   0425; 0445; Case map
-   0426; 0446; Case map
-   0427; 0447; Case map
-   0428; 0448; Case map
-   0429; 0449; Case map
-   042A; 044A; Case map
-   042B; 044B; Case map
-   042C; 044C; Case map
-   042D; 044D; Case map
-   042E; 044E; Case map
-   042F; 044F; Case map
-   0460; 0461; Case map
-   0462; 0463; Case map
-   0464; 0465; Case map
-   0466; 0467; Case map
-   0468; 0469; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 67]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   046A; 046B; Case map
-   046C; 046D; Case map
-   046E; 046F; Case map
-   0470; 0471; Case map
-   0472; 0473; Case map
-   0474; 0475; Case map
-   0476; 0477; Case map
-   0478; 0479; Case map
-   047A; 047B; Case map
-   047C; 047D; Case map
-   047E; 047F; Case map
-   0480; 0481; Case map
-   048A; 048B; Case map
-   048C; 048D; Case map
-   048E; 048F; Case map
-   0490; 0491; Case map
-   0492; 0493; Case map
-   0494; 0495; Case map
-   0496; 0497; Case map
-   0498; 0499; Case map
-   049A; 049B; Case map
-   049C; 049D; Case map
-   049E; 049F; Case map
-   04A0; 04A1; Case map
-   04A2; 04A3; Case map
-   04A4; 04A5; Case map
-   04A6; 04A7; Case map
-   04A8; 04A9; Case map
-   04AA; 04AB; Case map
-   04AC; 04AD; Case map
-   04AE; 04AF; Case map
-   04B0; 04B1; Case map
-   04B2; 04B3; Case map
-   04B4; 04B5; Case map
-   04B6; 04B7; Case map
-   04B8; 04B9; Case map
-   04BA; 04BB; Case map
-   04BC; 04BD; Case map
-   04BE; 04BF; Case map
-   04C1; 04C2; Case map
-   04C3; 04C4; Case map
-   04C5; 04C6; Case map
-   04C7; 04C8; Case map
-   04C9; 04CA; Case map
-   04CB; 04CC; Case map
-   04CD; 04CE; Case map
-   04D0; 04D1; Case map
-   04D2; 04D3; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 68]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   04D4; 04D5; Case map
-   04D6; 04D7; Case map
-   04D8; 04D9; Case map
-   04DA; 04DB; Case map
-   04DC; 04DD; Case map
-   04DE; 04DF; Case map
-   04E0; 04E1; Case map
-   04E2; 04E3; Case map
-   04E4; 04E5; Case map
-   04E6; 04E7; Case map
-   04E8; 04E9; Case map
-   04EA; 04EB; Case map
-   04EC; 04ED; Case map
-   04EE; 04EF; Case map
-   04F0; 04F1; Case map
-   04F2; 04F3; Case map
-   04F4; 04F5; Case map
-   04F8; 04F9; Case map
-   0500; 0501; Case map
-   0502; 0503; Case map
-   0504; 0505; Case map
-   0506; 0507; Case map
-   0508; 0509; Case map
-   050A; 050B; Case map
-   050C; 050D; Case map
-   050E; 050F; Case map
-   0531; 0561; Case map
-   0532; 0562; Case map
-   0533; 0563; Case map
-   0534; 0564; Case map
-   0535; 0565; Case map
-   0536; 0566; Case map
-   0537; 0567; Case map
-   0538; 0568; Case map
-   0539; 0569; Case map
-   053A; 056A; Case map
-   053B; 056B; Case map
-   053C; 056C; Case map
-   053D; 056D; Case map
-   053E; 056E; Case map
-   053F; 056F; Case map
-   0540; 0570; Case map
-   0541; 0571; Case map
-   0542; 0572; Case map
-   0543; 0573; Case map
-   0544; 0574; Case map
-   0545; 0575; Case map
-   0546; 0576; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 69]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0547; 0577; Case map
-   0548; 0578; Case map
-   0549; 0579; Case map
-   054A; 057A; Case map
-   054B; 057B; Case map
-   054C; 057C; Case map
-   054D; 057D; Case map
-   054E; 057E; Case map
-   054F; 057F; Case map
-   0550; 0580; Case map
-   0551; 0581; Case map
-   0552; 0582; Case map
-   0553; 0583; Case map
-   0554; 0584; Case map
-   0555; 0585; Case map
-   0556; 0586; Case map
-   0587; 0565 0582; Case map
-   1E00; 1E01; Case map
-   1E02; 1E03; Case map
-   1E04; 1E05; Case map
-   1E06; 1E07; Case map
-   1E08; 1E09; Case map
-   1E0A; 1E0B; Case map
-   1E0C; 1E0D; Case map
-   1E0E; 1E0F; Case map
-   1E10; 1E11; Case map
-   1E12; 1E13; Case map
-   1E14; 1E15; Case map
-   1E16; 1E17; Case map
-   1E18; 1E19; Case map
-   1E1A; 1E1B; Case map
-   1E1C; 1E1D; Case map
-   1E1E; 1E1F; Case map
-   1E20; 1E21; Case map
-   1E22; 1E23; Case map
-   1E24; 1E25; Case map
-   1E26; 1E27; Case map
-   1E28; 1E29; Case map
-   1E2A; 1E2B; Case map
-   1E2C; 1E2D; Case map
-   1E2E; 1E2F; Case map
-   1E30; 1E31; Case map
-   1E32; 1E33; Case map
-   1E34; 1E35; Case map
-   1E36; 1E37; Case map
-   1E38; 1E39; Case map
-   1E3A; 1E3B; Case map
-   1E3C; 1E3D; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 70]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1E3E; 1E3F; Case map
-   1E40; 1E41; Case map
-   1E42; 1E43; Case map
-   1E44; 1E45; Case map
-   1E46; 1E47; Case map
-   1E48; 1E49; Case map
-   1E4A; 1E4B; Case map
-   1E4C; 1E4D; Case map
-   1E4E; 1E4F; Case map
-   1E50; 1E51; Case map
-   1E52; 1E53; Case map
-   1E54; 1E55; Case map
-   1E56; 1E57; Case map
-   1E58; 1E59; Case map
-   1E5A; 1E5B; Case map
-   1E5C; 1E5D; Case map
-   1E5E; 1E5F; Case map
-   1E60; 1E61; Case map
-   1E62; 1E63; Case map
-   1E64; 1E65; Case map
-   1E66; 1E67; Case map
-   1E68; 1E69; Case map
-   1E6A; 1E6B; Case map
-   1E6C; 1E6D; Case map
-   1E6E; 1E6F; Case map
-   1E70; 1E71; Case map
-   1E72; 1E73; Case map
-   1E74; 1E75; Case map
-   1E76; 1E77; Case map
-   1E78; 1E79; Case map
-   1E7A; 1E7B; Case map
-   1E7C; 1E7D; Case map
-   1E7E; 1E7F; Case map
-   1E80; 1E81; Case map
-   1E82; 1E83; Case map
-   1E84; 1E85; Case map
-   1E86; 1E87; Case map
-   1E88; 1E89; Case map
-   1E8A; 1E8B; Case map
-   1E8C; 1E8D; Case map
-   1E8E; 1E8F; Case map
-   1E90; 1E91; Case map
-   1E92; 1E93; Case map
-   1E94; 1E95; Case map
-   1E96; 0068 0331; Case map
-   1E97; 0074 0308; Case map
-   1E98; 0077 030A; Case map
-   1E99; 0079 030A; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 71]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1E9A; 0061 02BE; Case map
-   1E9B; 1E61; Case map
-   1EA0; 1EA1; Case map
-   1EA2; 1EA3; Case map
-   1EA4; 1EA5; Case map
-   1EA6; 1EA7; Case map
-   1EA8; 1EA9; Case map
-   1EAA; 1EAB; Case map
-   1EAC; 1EAD; Case map
-   1EAE; 1EAF; Case map
-   1EB0; 1EB1; Case map
-   1EB2; 1EB3; Case map
-   1EB4; 1EB5; Case map
-   1EB6; 1EB7; Case map
-   1EB8; 1EB9; Case map
-   1EBA; 1EBB; Case map
-   1EBC; 1EBD; Case map
-   1EBE; 1EBF; Case map
-   1EC0; 1EC1; Case map
-   1EC2; 1EC3; Case map
-   1EC4; 1EC5; Case map
-   1EC6; 1EC7; Case map
-   1EC8; 1EC9; Case map
-   1ECA; 1ECB; Case map
-   1ECC; 1ECD; Case map
-   1ECE; 1ECF; Case map
-   1ED0; 1ED1; Case map
-   1ED2; 1ED3; Case map
-   1ED4; 1ED5; Case map
-   1ED6; 1ED7; Case map
-   1ED8; 1ED9; Case map
-   1EDA; 1EDB; Case map
-   1EDC; 1EDD; Case map
-   1EDE; 1EDF; Case map
-   1EE0; 1EE1; Case map
-   1EE2; 1EE3; Case map
-   1EE4; 1EE5; Case map
-   1EE6; 1EE7; Case map
-   1EE8; 1EE9; Case map
-   1EEA; 1EEB; Case map
-   1EEC; 1EED; Case map
-   1EEE; 1EEF; Case map
-   1EF0; 1EF1; Case map
-   1EF2; 1EF3; Case map
-   1EF4; 1EF5; Case map
-   1EF6; 1EF7; Case map
-   1EF8; 1EF9; Case map
-   1F08; 1F00; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 72]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1F09; 1F01; Case map
-   1F0A; 1F02; Case map
-   1F0B; 1F03; Case map
-   1F0C; 1F04; Case map
-   1F0D; 1F05; Case map
-   1F0E; 1F06; Case map
-   1F0F; 1F07; Case map
-   1F18; 1F10; Case map
-   1F19; 1F11; Case map
-   1F1A; 1F12; Case map
-   1F1B; 1F13; Case map
-   1F1C; 1F14; Case map
-   1F1D; 1F15; Case map
-   1F28; 1F20; Case map
-   1F29; 1F21; Case map
-   1F2A; 1F22; Case map
-   1F2B; 1F23; Case map
-   1F2C; 1F24; Case map
-   1F2D; 1F25; Case map
-   1F2E; 1F26; Case map
-   1F2F; 1F27; Case map
-   1F38; 1F30; Case map
-   1F39; 1F31; Case map
-   1F3A; 1F32; Case map
-   1F3B; 1F33; Case map
-   1F3C; 1F34; Case map
-   1F3D; 1F35; Case map
-   1F3E; 1F36; Case map
-   1F3F; 1F37; Case map
-   1F48; 1F40; Case map
-   1F49; 1F41; Case map
-   1F4A; 1F42; Case map
-   1F4B; 1F43; Case map
-   1F4C; 1F44; Case map
-   1F4D; 1F45; Case map
-   1F50; 03C5 0313; Case map
-   1F52; 03C5 0313 0300; Case map
-   1F54; 03C5 0313 0301; Case map
-   1F56; 03C5 0313 0342; Case map
-   1F59; 1F51; Case map
-   1F5B; 1F53; Case map
-   1F5D; 1F55; Case map
-   1F5F; 1F57; Case map
-   1F68; 1F60; Case map
-   1F69; 1F61; Case map
-   1F6A; 1F62; Case map
-   1F6B; 1F63; Case map
-   1F6C; 1F64; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 73]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1F6D; 1F65; Case map
-   1F6E; 1F66; Case map
-   1F6F; 1F67; Case map
-   1F80; 1F00 03B9; Case map
-   1F81; 1F01 03B9; Case map
-   1F82; 1F02 03B9; Case map
-   1F83; 1F03 03B9; Case map
-   1F84; 1F04 03B9; Case map
-   1F85; 1F05 03B9; Case map
-   1F86; 1F06 03B9; Case map
-   1F87; 1F07 03B9; Case map
-   1F88; 1F00 03B9; Case map
-   1F89; 1F01 03B9; Case map
-   1F8A; 1F02 03B9; Case map
-   1F8B; 1F03 03B9; Case map
-   1F8C; 1F04 03B9; Case map
-   1F8D; 1F05 03B9; Case map
-   1F8E; 1F06 03B9; Case map
-   1F8F; 1F07 03B9; Case map
-   1F90; 1F20 03B9; Case map
-   1F91; 1F21 03B9; Case map
-   1F92; 1F22 03B9; Case map
-   1F93; 1F23 03B9; Case map
-   1F94; 1F24 03B9; Case map
-   1F95; 1F25 03B9; Case map
-   1F96; 1F26 03B9; Case map
-   1F97; 1F27 03B9; Case map
-   1F98; 1F20 03B9; Case map
-   1F99; 1F21 03B9; Case map
-   1F9A; 1F22 03B9; Case map
-   1F9B; 1F23 03B9; Case map
-   1F9C; 1F24 03B9; Case map
-   1F9D; 1F25 03B9; Case map
-   1F9E; 1F26 03B9; Case map
-   1F9F; 1F27 03B9; Case map
-   1FA0; 1F60 03B9; Case map
-   1FA1; 1F61 03B9; Case map
-   1FA2; 1F62 03B9; Case map
-   1FA3; 1F63 03B9; Case map
-   1FA4; 1F64 03B9; Case map
-   1FA5; 1F65 03B9; Case map
-   1FA6; 1F66 03B9; Case map
-   1FA7; 1F67 03B9; Case map
-   1FA8; 1F60 03B9; Case map
-   1FA9; 1F61 03B9; Case map
-   1FAA; 1F62 03B9; Case map
-   1FAB; 1F63 03B9; Case map
-   1FAC; 1F64 03B9; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 74]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1FAD; 1F65 03B9; Case map
-   1FAE; 1F66 03B9; Case map
-   1FAF; 1F67 03B9; Case map
-   1FB2; 1F70 03B9; Case map
-   1FB3; 03B1 03B9; Case map
-   1FB4; 03AC 03B9; Case map
-   1FB6; 03B1 0342; Case map
-   1FB7; 03B1 0342 03B9; Case map
-   1FB8; 1FB0; Case map
-   1FB9; 1FB1; Case map
-   1FBA; 1F70; Case map
-   1FBB; 1F71; Case map
-   1FBC; 03B1 03B9; Case map
-   1FBE; 03B9; Case map
-   1FC2; 1F74 03B9; Case map
-   1FC3; 03B7 03B9; Case map
-   1FC4; 03AE 03B9; Case map
-   1FC6; 03B7 0342; Case map
-   1FC7; 03B7 0342 03B9; Case map
-   1FC8; 1F72; Case map
-   1FC9; 1F73; Case map
-   1FCA; 1F74; Case map
-   1FCB; 1F75; Case map
-   1FCC; 03B7 03B9; Case map
-   1FD2; 03B9 0308 0300; Case map
-   1FD3; 03B9 0308 0301; Case map
-   1FD6; 03B9 0342; Case map
-   1FD7; 03B9 0308 0342; Case map
-   1FD8; 1FD0; Case map
-   1FD9; 1FD1; Case map
-   1FDA; 1F76; Case map
-   1FDB; 1F77; Case map
-   1FE2; 03C5 0308 0300; Case map
-   1FE3; 03C5 0308 0301; Case map
-   1FE4; 03C1 0313; Case map
-   1FE6; 03C5 0342; Case map
-   1FE7; 03C5 0308 0342; Case map
-   1FE8; 1FE0; Case map
-   1FE9; 1FE1; Case map
-   1FEA; 1F7A; Case map
-   1FEB; 1F7B; Case map
-   1FEC; 1FE5; Case map
-   1FF2; 1F7C 03B9; Case map
-   1FF3; 03C9 03B9; Case map
-   1FF4; 03CE 03B9; Case map
-   1FF6; 03C9 0342; Case map
-   1FF7; 03C9 0342 03B9; Case map
-   1FF8; 1F78; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 75]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1FF9; 1F79; Case map
-   1FFA; 1F7C; Case map
-   1FFB; 1F7D; Case map
-   1FFC; 03C9 03B9; Case map
-   2126; 03C9; Case map
-   212A; 006B; Case map
-   212B; 00E5; Case map
-   2160; 2170; Case map
-   2161; 2171; Case map
-   2162; 2172; Case map
-   2163; 2173; Case map
-   2164; 2174; Case map
-   2165; 2175; Case map
-   2166; 2176; Case map
-   2167; 2177; Case map
-   2168; 2178; Case map
-   2169; 2179; Case map
-   216A; 217A; Case map
-   216B; 217B; Case map
-   216C; 217C; Case map
-   216D; 217D; Case map
-   216E; 217E; Case map
-   216F; 217F; Case map
-   24B6; 24D0; Case map
-   24B7; 24D1; Case map
-   24B8; 24D2; Case map
-   24B9; 24D3; Case map
-   24BA; 24D4; Case map
-   24BB; 24D5; Case map
-   24BC; 24D6; Case map
-   24BD; 24D7; Case map
-   24BE; 24D8; Case map
-   24BF; 24D9; Case map
-   24C0; 24DA; Case map
-   24C1; 24DB; Case map
-   24C2; 24DC; Case map
-   24C3; 24DD; Case map
-   24C4; 24DE; Case map
-   24C5; 24DF; Case map
-   24C6; 24E0; Case map
-   24C7; 24E1; Case map
-   24C8; 24E2; Case map
-   24C9; 24E3; Case map
-   24CA; 24E4; Case map
-   24CB; 24E5; Case map
-   24CC; 24E6; Case map
-   24CD; 24E7; Case map
-   24CE; 24E8; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 76]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   24CF; 24E9; Case map
-   FB00; 0066 0066; Case map
-   FB01; 0066 0069; Case map
-   FB02; 0066 006C; Case map
-   FB03; 0066 0066 0069; Case map
-   FB04; 0066 0066 006C; Case map
-   FB05; 0073 0074; Case map
-   FB06; 0073 0074; Case map
-   FB13; 0574 0576; Case map
-   FB14; 0574 0565; Case map
-   FB15; 0574 056B; Case map
-   FB16; 057E 0576; Case map
-   FB17; 0574 056D; Case map
-   FF21; FF41; Case map
-   FF22; FF42; Case map
-   FF23; FF43; Case map
-   FF24; FF44; Case map
-   FF25; FF45; Case map
-   FF26; FF46; Case map
-   FF27; FF47; Case map
-   FF28; FF48; Case map
-   FF29; FF49; Case map
-   FF2A; FF4A; Case map
-   FF2B; FF4B; Case map
-   FF2C; FF4C; Case map
-   FF2D; FF4D; Case map
-   FF2E; FF4E; Case map
-   FF2F; FF4F; Case map
-   FF30; FF50; Case map
-   FF31; FF51; Case map
-   FF32; FF52; Case map
-   FF33; FF53; Case map
-   FF34; FF54; Case map
-   FF35; FF55; Case map
-   FF36; FF56; Case map
-   FF37; FF57; Case map
-   FF38; FF58; Case map
-   FF39; FF59; Case map
-   FF3A; FF5A; Case map
-   10400; 10428; Case map
-   10401; 10429; Case map
-   10402; 1042A; Case map
-   10403; 1042B; Case map
-   10404; 1042C; Case map
-   10405; 1042D; Case map
-   10406; 1042E; Case map
-   10407; 1042F; Case map
-   10408; 10430; Case map
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 77]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   10409; 10431; Case map
-   1040A; 10432; Case map
-   1040B; 10433; Case map
-   1040C; 10434; Case map
-   1040D; 10435; Case map
-   1040E; 10436; Case map
-   1040F; 10437; Case map
-   10410; 10438; Case map
-   10411; 10439; Case map
-   10412; 1043A; Case map
-   10413; 1043B; Case map
-   10414; 1043C; Case map
-   10415; 1043D; Case map
-   10416; 1043E; Case map
-   10417; 1043F; Case map
-   10418; 10440; Case map
-   10419; 10441; Case map
-   1041A; 10442; Case map
-   1041B; 10443; Case map
-   1041C; 10444; Case map
-   1041D; 10445; Case map
-   1041E; 10446; Case map
-   1041F; 10447; Case map
-   10420; 10448; Case map
-   10421; 10449; Case map
-   10422; 1044A; Case map
-   10423; 1044B; Case map
-   10424; 1044C; Case map
-   10425; 1044D; Case map
-   ----- End Table B.3 -----
-
-C. Prohibition tables
-
-   The tables in this appendix consist of lines with one prohibited code
-   point per line.  The format of the lines are the value of the code
-   point, a semicolon, and a comment which is the name of the code
-   point.
-
-C.1 Space characters
-
-C.1.1 ASCII space characters
-
-   ----- Start Table C.1.1 -----
-   0020; SPACE
-   ----- End Table C.1.1 -----
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 78]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-C.1.2 Non-ASCII space characters
-   ----- Start Table C.1.2 -----
-   00A0; NO-BREAK SPACE
-   1680; OGHAM SPACE MARK
-   2000; EN QUAD
-   2001; EM QUAD
-   2002; EN SPACE
-   2003; EM SPACE
-   2004; THREE-PER-EM SPACE
-   2005; FOUR-PER-EM SPACE
-   2006; SIX-PER-EM SPACE
-   2007; FIGURE SPACE
-   2008; PUNCTUATION SPACE
-   2009; THIN SPACE
-   200A; HAIR SPACE
-   200B; ZERO WIDTH SPACE
-   202F; NARROW NO-BREAK SPACE
-   205F; MEDIUM MATHEMATICAL SPACE
-   3000; IDEOGRAPHIC SPACE
-   ----- End Table C.1.2 -----
-
-C.2 Control characters
-
-C.2.1 ASCII control characters
-
-   ----- Start Table C.2.1 -----
-   0000-001F; [CONTROL CHARACTERS]
-   007F; DELETE
-   ----- End Table C.2.1 -----
-
-C.2.2 Non-ASCII control characters
-
-   ----- Start Table C.2.2 -----
-   0080-009F; [CONTROL CHARACTERS]
-   06DD; ARABIC END OF AYAH
-   070F; SYRIAC ABBREVIATION MARK
-   180E; MONGOLIAN VOWEL SEPARATOR
-   200C; ZERO WIDTH NON-JOINER
-   200D; ZERO WIDTH JOINER
-   2028; LINE SEPARATOR
-   2029; PARAGRAPH SEPARATOR
-   2060; WORD JOINER
-   2061; FUNCTION APPLICATION
-   2062; INVISIBLE TIMES
-   2063; INVISIBLE SEPARATOR
-   206A-206F; [CONTROL CHARACTERS]
-   FEFF; ZERO WIDTH NO-BREAK SPACE
-   FFF9-FFFC; [CONTROL CHARACTERS]
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 79]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D173-1D17A; [MUSICAL CONTROL CHARACTERS]
-   ----- End Table C.2.2 -----
-
-C.3 Private use
-
-   ----- Start Table C.3 -----
-   E000-F8FF; [PRIVATE USE, PLANE 0]
-   F0000-FFFFD; [PRIVATE USE, PLANE 15]
-   100000-10FFFD; [PRIVATE USE, PLANE 16]
-   ----- End Table C.3 -----
-
-C.4 Non-character code points
-
-   ----- Start Table C.4 -----
-   FDD0-FDEF; [NONCHARACTER CODE POINTS]
-   FFFE-FFFF; [NONCHARACTER CODE POINTS]
-   1FFFE-1FFFF; [NONCHARACTER CODE POINTS]
-   2FFFE-2FFFF; [NONCHARACTER CODE POINTS]
-   3FFFE-3FFFF; [NONCHARACTER CODE POINTS]
-   4FFFE-4FFFF; [NONCHARACTER CODE POINTS]
-   5FFFE-5FFFF; [NONCHARACTER CODE POINTS]
-   6FFFE-6FFFF; [NONCHARACTER CODE POINTS]
-   7FFFE-7FFFF; [NONCHARACTER CODE POINTS]
-   8FFFE-8FFFF; [NONCHARACTER CODE POINTS]
-   9FFFE-9FFFF; [NONCHARACTER CODE POINTS]
-   AFFFE-AFFFF; [NONCHARACTER CODE POINTS]
-   BFFFE-BFFFF; [NONCHARACTER CODE POINTS]
-   CFFFE-CFFFF; [NONCHARACTER CODE POINTS]
-   DFFFE-DFFFF; [NONCHARACTER CODE POINTS]
-   EFFFE-EFFFF; [NONCHARACTER CODE POINTS]
-   FFFFE-FFFFF; [NONCHARACTER CODE POINTS]
-   10FFFE-10FFFF; [NONCHARACTER CODE POINTS]
-   ----- End Table C.4 -----
-
-C.5 Surrogate codes
-
-   ----- Start Table C.5 -----
-   D800-DFFF; [SURROGATE CODES]
-   ----- End Table C.5 -----
-
-C.6 Inappropriate for plain text
-
-   ----- Start Table C.6 -----
-   FFF9; INTERLINEAR ANNOTATION ANCHOR
-   FFFA; INTERLINEAR ANNOTATION SEPARATOR
-   FFFB; INTERLINEAR ANNOTATION TERMINATOR
-   FFFC; OBJECT REPLACEMENT CHARACTER
-   FFFD; REPLACEMENT CHARACTER
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 80]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   ----- End Table C.6 -----
-
-C.7 Inappropriate for canonical representation
-
-   ----- Start Table C.7 -----
-   2FF0-2FFB; [IDEOGRAPHIC DESCRIPTION CHARACTERS]
-   ----- End Table C.7 -----
-
-C.8 Change display properties or are deprecated
-
-   ----- Start Table C.8 -----
-   0340; COMBINING GRAVE TONE MARK
-   0341; COMBINING ACUTE TONE MARK
-   200E; LEFT-TO-RIGHT MARK
-   200F; RIGHT-TO-LEFT MARK
-   202A; LEFT-TO-RIGHT EMBEDDING
-   202B; RIGHT-TO-LEFT EMBEDDING
-   202C; POP DIRECTIONAL FORMATTING
-   202D; LEFT-TO-RIGHT OVERRIDE
-   202E; RIGHT-TO-LEFT OVERRIDE
-   206A; INHIBIT SYMMETRIC SWAPPING
-   206B; ACTIVATE SYMMETRIC SWAPPING
-   206C; INHIBIT ARABIC FORM SHAPING
-   206D; ACTIVATE ARABIC FORM SHAPING
-   206E; NATIONAL DIGIT SHAPES
-   206F; NOMINAL DIGIT SHAPES
-   ----- End Table C.8 -----
-
-C.9 Tagging characters
-
-   ----- Start Table C.9 -----
-   E0001; LANGUAGE TAG
-   E0020-E007F; [TAGGING CHARACTERS]
-   ----- End Table C.9 -----
-
-D. Bidirectional tables
-
-D.1 Characters with bidirectional property "R" or "AL"
-
-   ----- Start Table D.1 -----
-   05BE
-   05C0
-   05C3
-   05D0-05EA
-   05F0-05F4
-   061B
-   061F
-   0621-063A
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 81]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0640-064A
-   066D-066F
-   0671-06D5
-   06DD
-   06E5-06E6
-   06FA-06FE
-   0700-070D
-   0710
-   0712-072C
-   0780-07A5
-   07B1
-   200F
-   FB1D
-   FB1F-FB28
-   FB2A-FB36
-   FB38-FB3C
-   FB3E
-   FB40-FB41
-   FB43-FB44
-   FB46-FBB1
-   FBD3-FD3D
-   FD50-FD8F
-   FD92-FDC7
-   FDF0-FDFC
-   FE70-FE74
-   FE76-FEFC
-   ----- End Table D.1 -----
-
-D.2 Characters with bidirectional property "L"
-
-   ----- Start Table D.2 -----
-   0041-005A
-   0061-007A
-   00AA
-   00B5
-   00BA
-   00C0-00D6
-   00D8-00F6
-   00F8-0220
-   0222-0233
-   0250-02AD
-   02B0-02B8
-   02BB-02C1
-   02D0-02D1
-   02E0-02E4
-   02EE
-   037A
-   0386
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 82]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0388-038A
-   038C
-   038E-03A1
-   03A3-03CE
-   03D0-03F5
-   0400-0482
-   048A-04CE
-   04D0-04F5
-   04F8-04F9
-   0500-050F
-   0531-0556
-   0559-055F
-   0561-0587
-   0589
-   0903
-   0905-0939
-   093D-0940
-   0949-094C
-   0950
-   0958-0961
-   0964-0970
-   0982-0983
-   0985-098C
-   098F-0990
-   0993-09A8
-   09AA-09B0
-   09B2
-   09B6-09B9
-   09BE-09C0
-   09C7-09C8
-   09CB-09CC
-   09D7
-   09DC-09DD
-   09DF-09E1
-   09E6-09F1
-   09F4-09FA
-   0A05-0A0A
-   0A0F-0A10
-   0A13-0A28
-   0A2A-0A30
-   0A32-0A33
-   0A35-0A36
-   0A38-0A39
-   0A3E-0A40
-   0A59-0A5C
-   0A5E
-   0A66-0A6F
-   0A72-0A74
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 83]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0A83
-   0A85-0A8B
-   0A8D
-   0A8F-0A91
-   0A93-0AA8
-   0AAA-0AB0
-   0AB2-0AB3
-   0AB5-0AB9
-   0ABD-0AC0
-   0AC9
-   0ACB-0ACC
-   0AD0
-   0AE0
-   0AE6-0AEF
-   0B02-0B03
-   0B05-0B0C
-   0B0F-0B10
-   0B13-0B28
-   0B2A-0B30
-   0B32-0B33
-   0B36-0B39
-   0B3D-0B3E
-   0B40
-   0B47-0B48
-   0B4B-0B4C
-   0B57
-   0B5C-0B5D
-   0B5F-0B61
-   0B66-0B70
-   0B83
-   0B85-0B8A
-   0B8E-0B90
-   0B92-0B95
-   0B99-0B9A
-   0B9C
-   0B9E-0B9F
-   0BA3-0BA4
-   0BA8-0BAA
-   0BAE-0BB5
-   0BB7-0BB9
-   0BBE-0BBF
-   0BC1-0BC2
-   0BC6-0BC8
-   0BCA-0BCC
-   0BD7
-   0BE7-0BF2
-   0C01-0C03
-   0C05-0C0C
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 84]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0C0E-0C10
-   0C12-0C28
-   0C2A-0C33
-   0C35-0C39
-   0C41-0C44
-   0C60-0C61
-   0C66-0C6F
-   0C82-0C83
-   0C85-0C8C
-   0C8E-0C90
-   0C92-0CA8
-   0CAA-0CB3
-   0CB5-0CB9
-   0CBE
-   0CC0-0CC4
-   0CC7-0CC8
-   0CCA-0CCB
-   0CD5-0CD6
-   0CDE
-   0CE0-0CE1
-   0CE6-0CEF
-   0D02-0D03
-   0D05-0D0C
-   0D0E-0D10
-   0D12-0D28
-   0D2A-0D39
-   0D3E-0D40
-   0D46-0D48
-   0D4A-0D4C
-   0D57
-   0D60-0D61
-   0D66-0D6F
-   0D82-0D83
-   0D85-0D96
-   0D9A-0DB1
-   0DB3-0DBB
-   0DBD
-   0DC0-0DC6
-   0DCF-0DD1
-   0DD8-0DDF
-   0DF2-0DF4
-   0E01-0E30
-   0E32-0E33
-   0E40-0E46
-   0E4F-0E5B
-   0E81-0E82
-   0E84
-   0E87-0E88
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 85]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   0E8A
-   0E8D
-   0E94-0E97
-   0E99-0E9F
-   0EA1-0EA3
-   0EA5
-   0EA7
-   0EAA-0EAB
-   0EAD-0EB0
-   0EB2-0EB3
-   0EBD
-   0EC0-0EC4
-   0EC6
-   0ED0-0ED9
-   0EDC-0EDD
-   0F00-0F17
-   0F1A-0F34
-   0F36
-   0F38
-   0F3E-0F47
-   0F49-0F6A
-   0F7F
-   0F85
-   0F88-0F8B
-   0FBE-0FC5
-   0FC7-0FCC
-   0FCF
-   1000-1021
-   1023-1027
-   1029-102A
-   102C
-   1031
-   1038
-   1040-1057
-   10A0-10C5
-   10D0-10F8
-   10FB
-   1100-1159
-   115F-11A2
-   11A8-11F9
-   1200-1206
-   1208-1246
-   1248
-   124A-124D
-   1250-1256
-   1258
-   125A-125D
-   1260-1286
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 86]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1288
-   128A-128D
-   1290-12AE
-   12B0
-   12B2-12B5
-   12B8-12BE
-   12C0
-   12C2-12C5
-   12C8-12CE
-   12D0-12D6
-   12D8-12EE
-   12F0-130E
-   1310
-   1312-1315
-   1318-131E
-   1320-1346
-   1348-135A
-   1361-137C
-   13A0-13F4
-   1401-1676
-   1681-169A
-   16A0-16F0
-   1700-170C
-   170E-1711
-   1720-1731
-   1735-1736
-   1740-1751
-   1760-176C
-   176E-1770
-   1780-17B6
-   17BE-17C5
-   17C7-17C8
-   17D4-17DA
-   17DC
-   17E0-17E9
-   1810-1819
-   1820-1877
-   1880-18A8
-   1E00-1E9B
-   1EA0-1EF9
-   1F00-1F15
-   1F18-1F1D
-   1F20-1F45
-   1F48-1F4D
-   1F50-1F57
-   1F59
-   1F5B
-   1F5D
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 87]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1F5F-1F7D
-   1F80-1FB4
-   1FB6-1FBC
-   1FBE
-   1FC2-1FC4
-   1FC6-1FCC
-   1FD0-1FD3
-   1FD6-1FDB
-   1FE0-1FEC
-   1FF2-1FF4
-   1FF6-1FFC
-   200E
-   2071
-   207F
-   2102
-   2107
-   210A-2113
-   2115
-   2119-211D
-   2124
-   2126
-   2128
-   212A-212D
-   212F-2131
-   2133-2139
-   213D-213F
-   2145-2149
-   2160-2183
-   2336-237A
-   2395
-   249C-24E9
-   3005-3007
-   3021-3029
-   3031-3035
-   3038-303C
-   3041-3096
-   309D-309F
-   30A1-30FA
-   30FC-30FF
-   3105-312C
-   3131-318E
-   3190-31B7
-   31F0-321C
-   3220-3243
-   3260-327B
-   327F-32B0
-   32C0-32CB
-   32D0-32FE
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 88]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   3300-3376
-   337B-33DD
-   33E0-33FE
-   3400-4DB5
-   4E00-9FA5
-   A000-A48C
-   AC00-D7A3
-   D800-FA2D
-   FA30-FA6A
-   FB00-FB06
-   FB13-FB17
-   FF21-FF3A
-   FF41-FF5A
-   FF66-FFBE
-   FFC2-FFC7
-   FFCA-FFCF
-   FFD2-FFD7
-   FFDA-FFDC
-   10300-1031E
-   10320-10323
-   10330-1034A
-   10400-10425
-   10428-1044D
-   1D000-1D0F5
-   1D100-1D126
-   1D12A-1D166
-   1D16A-1D172
-   1D183-1D184
-   1D18C-1D1A9
-   1D1AE-1D1DD
-   1D400-1D454
-   1D456-1D49C
-   1D49E-1D49F
-   1D4A2
-   1D4A5-1D4A6
-   1D4A9-1D4AC
-   1D4AE-1D4B9
-   1D4BB
-   1D4BD-1D4C0
-   1D4C2-1D4C3
-   1D4C5-1D505
-   1D507-1D50A
-   1D50D-1D514
-   1D516-1D51C
-   1D51E-1D539
-   1D53B-1D53E
-   1D540-1D544
-   1D546
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 89]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-   1D54A-1D550
-   1D552-1D6A3
-   1D6A8-1D7C9
-   20000-2A6D6
-   2F800-2FA1D
-   F0000-FFFFD
-   100000-10FFFD
-   ----- End Table D.2 -----
-
-Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman at imc.org and paul.hoffman at vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet at viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 90]
-
-RFC 3454        Preparation of Internationalized Strings   December 2002
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                    [Page 91]
-

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3490.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3490.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3490.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       P. Faltstrom
-Request for Comments: 3490                                         Cisco
-Category: Standards Track                                     P. Hoffman
-                                                              IMC & VPNC
-                                                             A. Costello
-                                                             UC Berkeley
-                                                              March 2003
-
-
-         Internationalizing Domain Names in Applications (IDNA)
-
-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 (2003).  All Rights Reserved.
-
-Abstract
-
-   Until now, there has been no standard method for domain names to use
-   characters outside the ASCII repertoire.  This document defines
-   internationalized domain names (IDNs) and a mechanism called
-   Internationalizing Domain Names in Applications (IDNA) for handling
-   them in a standard fashion.  IDNs use characters drawn from a large
-   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
-   represented using only the ASCII characters already allowed in so-
-   called host names today.  This backward-compatible representation is
-   required in existing protocols like DNS, so that IDNs can be
-   introduced with no changes to the existing infrastructure.  IDNA is
-   only meant for processing domain names, not free text.
-
-Table of Contents
-
-   1. Introduction..................................................  2
-      1.1 Problem Statement.........................................  3
-      1.2 Limitations of IDNA.......................................  3
-      1.3 Brief overview for application developers.................  4
-   2. Terminology...................................................  5
-   3. Requirements and applicability................................  7
-      3.1 Requirements..............................................  7
-      3.2 Applicability.............................................  8
-         3.2.1. DNS resource records................................  8
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 1]
-
-RFC 3490                          IDNA                        March 2003
-
-
-         3.2.2. Non-domain-name data types stored in domain names...  9
-   4. Conversion operations.........................................  9
-      4.1 ToASCII................................................... 10
-      4.2 ToUnicode................................................. 11
-   5. ACE prefix.................................................... 12
-   6. Implications for typical applications using DNS............... 13
-      6.1 Entry and display in applications......................... 14
-      6.2 Applications and resolver libraries....................... 15
-      6.3 DNS servers............................................... 15
-      6.4 Avoiding exposing users to the raw ACE encoding........... 16
-      6.5  DNSSEC authentication of IDN domain names................ 16
-   7. Name server considerations.................................... 17
-   8. Root server considerations.................................... 17
-   9. References.................................................... 18
-      9.1 Normative References...................................... 18
-      9.2 Informative References.................................... 18
-   10. Security Considerations...................................... 19
-   11. IANA Considerations.......................................... 20
-   12. Authors' Addresses........................................... 21
-   13. Full Copyright Statement..................................... 22
-
-1. Introduction
-
-   IDNA works by allowing applications to use certain ASCII name labels
-   (beginning with a special prefix) to represent non-ASCII name labels.
-   Lower-layer protocols need not be aware of this; therefore IDNA does
-   not depend on changes to any infrastructure.  In particular, IDNA
-   does not depend on any changes to DNS servers, resolvers, or protocol
-   elements, because the ASCII name service provided by the existing DNS
-   is entirely sufficient for IDNA.
-
-   This document does not require any applications to conform to IDNA,
-   but applications can elect to use IDNA in order to support IDN while
-   maintaining interoperability with existing infrastructure.  If an
-   application wants to use non-ASCII characters in domain names, IDNA
-   is the only currently-defined option.  Adding IDNA support to an
-   existing application entails changes to the application only, and
-   leaves room for flexibility in the user interface.
-
-   A great deal of the discussion of IDN solutions has focused on
-   transition issues and how IDN will work in a world where not all of
-   the components have been updated.  Proposals that were not chosen by
-   the IDN Working Group would depend on user applications, resolvers,
-   and DNS servers being updated in order for a user to use an
-   internationalized domain name.  Rather than rely on widespread
-   updating of all components, IDNA depends on updates to user
-   applications only; no changes are needed to the DNS protocol or any
-   DNS servers or the resolvers on user's computers.
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 2]
-
-RFC 3490                          IDNA                        March 2003
-
-
-1.1 Problem Statement
-
-   The IDNA specification solves the problem of extending the repertoire
-   of characters that can be used in domain names to include the Unicode
-   repertoire (with some restrictions).
-
-   IDNA does not extend the service offered by DNS to the applications.
-   Instead, the applications (and, by implication, the users) continue
-   to see an exact-match lookup service.  Either there is a single
-   exactly-matching name or there is no match.  This model has served
-   the existing applications well, but it requires, with or without
-   internationalized domain names, that users know the exact spelling of
-   the domain names that the users type into applications such as web
-   browsers and mail user agents.  The introduction of the larger
-   repertoire of characters potentially makes the set of misspellings
-   larger, especially given that in some cases the same appearance, for
-   example on a business card, might visually match several Unicode code
-   points or several sequences of code points.
-
-   IDNA allows the graceful introduction of IDNs not only by avoiding
-   upgrades to existing infrastructure (such as DNS servers and mail
-   transport agents), but also by allowing some rudimentary use of IDNs
-   in applications by using the ASCII representation of the non-ASCII
-   name labels.  While such names are very user-unfriendly to read and
-   type, and hence are not suitable for user input, they allow (for
-   instance) replying to email and clicking on URLs even though the
-   domain name displayed is incomprehensible to the user.  In order to
-   allow user-friendly input and output of the IDNs, the applications
-   need to be modified to conform to this specification.
-
-   IDNA uses the Unicode character repertoire, which avoids the
-   significant delays that would be inherent in waiting for a different
-   and specific character set be defined for IDN purposes by some other
-   standards developing organization.
-
-1.2 Limitations of IDNA
-
-   The IDNA protocol does not solve all linguistic issues with users
-   inputting names in different scripts.  Many important language-based
-   and script-based mappings are not covered in IDNA and need to be
-   handled outside the protocol.  For example, names that are entered in
-   a mix of traditional and simplified Chinese characters will not be
-   mapped to a single canonical name.  Another example is Scandinavian
-   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
-   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
-   STROKE).
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 3]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An example of an important issue that is not considered in detail in
-   IDNA is how to provide a high probability that a user who is entering
-   a domain name based on visual information (such as from a business
-   card or billboard) or aural information (such as from a telephone or
-   radio) would correctly enter the IDN.  Similar issues exist for ASCII
-   domain names, for example the possible visual confusion between the
-   letter 'O' and the digit zero, but the introduction of the larger
-   repertoire of characters creates more opportunities of similar
-   looking and similar sounding names.  Note that this is a complex
-   issue relating to languages, input methods on computers, and so on.
-   Furthermore, the kind of matching and searching necessary for a high
-   probability of success would not fit the role of the DNS and its
-   exact matching function.
-
-1.3 Brief overview for application developers
-
-   Applications can use IDNA to support internationalized domain names
-   anywhere that ASCII domain names are already supported, including DNS
-   master files and resolver interfaces.  (Applications can also define
-   protocols and interfaces that support IDNs directly using non-ASCII
-   representations.  IDNA does not prescribe any particular
-   representation for new protocols, but it still defines which names
-   are valid and how they are compared.)
-
-   The IDNA protocol is contained completely within applications.  It is
-   not a client-server or peer-to-peer protocol: everything is done
-   inside the application itself.  When used with a DNS resolver
-   library, IDNA is inserted as a "shim" between the application and the
-   resolver library.  When used for writing names into a DNS zone, IDNA
-   is used just before the name is committed to the zone.
-
-   There are two operations described in section 4 of this document:
-
-   -  The ToASCII operation is used before sending an IDN to something
-      that expects ASCII names (such as a resolver) or writing an IDN
-      into a place that expects ASCII names (such as a DNS master file).
-
-   -  The ToUnicode operation is used when displaying names to users,
-      for example names obtained from a DNS zone.
-
-   It is important to note that the ToASCII operation can fail.  If it
-   fails when processing a domain name, that domain name cannot be used
-   as an internationalized domain name and the application has to have
-   some method of dealing with this failure.
-
-   IDNA requires that implementations process input strings with
-   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
-   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 4]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
-   are optional.
-
-2. Terminology
-
-   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
-   and "MAY" in this document are to be interpreted as described in BCP
-   14, RFC 2119 [RFC2119].
-
-   A code point is an integer value associated with a character in a
-   coded character set.
-
-   Unicode [UNICODE] is a coded character set containing tens of
-   thousands of characters.  A single Unicode code point is denoted by
-   "U+" followed by four to six hexadecimal digits, while a range of
-   Unicode code points is denoted by two hexadecimal numbers separated
-   by "..", with no prefixes.
-
-   ASCII means US-ASCII [USASCII], a coded character set containing 128
-   characters associated with code points in the range 0..7F.  Unicode
-   is an extension of ASCII: it includes all the ASCII characters and
-   associates them with the same code points.
-
-   The term "LDH code points" is defined in this document to mean the
-   code points associated with ASCII letters, digits, and the hyphen-
-   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
-   abbreviation for "letters, digits, hyphen".
-
-   [STD13] talks about "domain names" and "host names", but many people
-   use the terms interchangeably.  Further, because [STD13] was not
-   terribly clear, many people who are sure they know the exact
-   definitions of each of these terms disagree on the definitions.  In
-   this document the term "domain name" is used in general.  This
-   document explicitly cites [STD3] whenever referring to the host name
-   syntax restrictions defined therein.
-
-   A label is an individual part of a domain name.  Labels are usually
-   shown separated by dots; for example, the domain name
-   "www.example.com" is composed of three labels: "www", "example", and
-   "com".  (The zero-length root label described in [STD13], which can
-   be explicit as in "www.example.com." or implicit as in
-   "www.example.com", is not considered a label in this specification.)
-   IDNA extends the set of usable characters in labels that are text.
-   For the rest of this document, the term "label" is shorthand for
-   "text label", and "every label" means "every text label".
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 5]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   An "internationalized label" is a label to which the ToASCII
-   operation (see section 4) can be applied without failing (with the
-   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
-   that satisfies the [STD13] length restriction is an internationalized
-   label.  Therefore the term "internationalized label" is a
-   generalization, embracing both old ASCII labels and new non-ASCII
-   labels.  Although most Unicode characters can appear in
-   internationalized labels, ToASCII will fail for some input strings,
-   and such strings are not valid internationalized labels.
-
-   An "internationalized domain name" (IDN) is a domain name in which
-   every label is an internationalized label.  This implies that every
-   ASCII domain name is an IDN (which implies that it is possible for a
-   name to be an IDN without it containing any non-ASCII characters).
-   This document does not attempt to define an "internationalized host
-   name".  Just as has been the case with ASCII names, some DNS zone
-   administrators may impose restrictions, beyond those imposed by DNS
-   or IDNA, on the characters or strings that may be registered as
-   labels in their zones.  Such restrictions have no impact on the
-   syntax or semantics of DNS protocol messages; a query for a name that
-   matches no records will yield the same response regardless of the
-   reason why it is not in the zone.  Clients issuing queries or
-   interpreting responses cannot be assumed to have any knowledge of
-   zone-specific restrictions or conventions.
-
-   In IDNA, equivalence of labels is defined in terms of the ToASCII
-   operation, which constructs an ASCII form for a given label, whether
-   or not the label was already an ASCII label.  Labels are defined to
-   be equivalent if and only if their ASCII forms produced by ToASCII
-   match using a case-insensitive ASCII comparison.  ASCII labels
-   already have a notion of equivalence: upper case and lower case are
-   considered equivalent.  The IDNA notion of equivalence is an
-   extension of that older notion.  Equivalent labels in IDNA are
-   treated as alternate forms of the same label, just as "foo" and "Foo"
-   are treated as alternate forms of the same label.
-
-   To allow internationalized labels to be handled by existing
-   applications, IDNA uses an "ACE label" (ACE stands for ASCII
-   Compatible Encoding).  An ACE label is an internationalized label
-   that can be rendered in ASCII and is equivalent to an
-   internationalized label that cannot be rendered in ASCII.  Given any
-   internationalized label that cannot be rendered in ASCII, the ToASCII
-   operation will convert it to an equivalent ACE label (whereas an
-   ASCII label will be left unaltered by ToASCII).  ACE labels are
-   unsuitable for display to users.  The ToUnicode operation will
-   convert any label to an equivalent non-ACE label.  In fact, an ACE
-   label is formally defined to be any label that the ToUnicode
-   operation would alter (whereas non-ACE labels are left unaltered by
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 6]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ToUnicode).  Every ACE label begins with the ACE prefix specified in
-   section 5.  The ToASCII and ToUnicode operations are specified in
-   section 4.
-
-   The "ACE prefix" is defined in this document to be a string of ASCII
-   characters that appears at the beginning of every ACE label.  It is
-   specified in section 5.
-
-   A "domain name slot" is defined in this document to be a protocol
-   element or a function argument or a return value (and so on)
-   explicitly designated for carrying a domain name.  Examples of domain
-   name slots include: the QNAME field of a DNS query; the name argument
-   of the gethostbyname() library function; the part of an email address
-   following the at-sign (@) in the From: field of an email message
-   header; and the host portion of the URI in the src attribute of an
-   HTML <IMG> tag.  General text that just happens to contain a domain
-   name is not a domain name slot; for example, a domain name appearing
-   in the plain text body of an email message is not occupying a domain
-   name slot.
-
-   An "IDN-aware domain name slot" is defined in this document to be a
-   domain name slot explicitly designated for carrying an
-   internationalized domain name as defined in this document.  The
-   designation may be static (for example, in the specification of the
-   protocol or interface) or dynamic (for example, as a result of
-   negotiation in an interactive session).
-
-   An "IDN-unaware domain name slot" is defined in this document to be
-   any domain name slot that is not an IDN-aware domain name slot.
-   Obviously, this includes any domain name slot whose specification
-   predates IDNA.
-
-3. Requirements and applicability
-
-3.1 Requirements
-
-   IDNA conformance means adherence to the following four requirements:
-
-   1) Whenever dots are used as label separators, the following
-      characters MUST be recognized as dots: U+002E (full stop), U+3002
-      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
-      (halfwidth ideographic full stop).
-
-   2) Whenever a domain name is put into an IDN-unaware domain name slot
-      (see section 2), it MUST contain only ASCII characters.  Given an
-      internationalized domain name (IDN), an equivalent domain name
-      satisfying this requirement can be obtained by applying the
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 7]
-
-RFC 3490                          IDNA                        March 2003
-
-
-      ToASCII operation (see section 4) to each label and, if dots are
-      used as label separators, changing all the label separators to
-      U+002E.
-
-   3) ACE labels obtained from domain name slots SHOULD be hidden from
-      users when it is known that the environment can handle the non-ACE
-      form, except when the ACE form is explicitly requested.  When it
-      is not known whether or not the environment can handle the non-ACE
-      form, the application MAY use the non-ACE form (which might fail,
-      such as by not being displayed properly), or it MAY use the ACE
-      form (which will look unintelligle to the user).  Given an
-      internationalized domain name, an equivalent domain name
-      containing no ACE labels can be obtained by applying the ToUnicode
-      operation (see section 4) to each label.  When requirements 2 and
-      3 both apply, requirement 2 takes precedence.
-
-   4) Whenever two labels are compared, they MUST be considered to match
-      if and only if they are equivalent, that is, their ASCII forms
-      (obtained by applying ToASCII) match using a case-insensitive
-      ASCII comparison.  Whenever two names are compared, they MUST be
-      considered to match if and only if their corresponding labels
-      match, regardless of whether the names use the same forms of label
-      separators.
-
-3.2 Applicability
-
-   IDNA is applicable to all domain names in all domain name slots
-   except where it is explicitly excluded.
-
-   This implies that IDNA is applicable to many protocols that predate
-   IDNA.  Note that IDNs occupying domain name slots in those protocols
-   MUST be in ASCII form (see section 3.1, requirement 2).
-
-3.2.1. DNS resource records
-
-   IDNA does not apply to domain names in the NAME and RDATA fields of
-   DNS resource records whose CLASS is not IN.  This exclusion applies
-   to every non-IN class, present and future, except where future
-   standards override this exclusion by explicitly inviting the use of
-   IDNA.
-
-   There are currently no other exclusions on the applicability of IDNA
-   to DNS resource records; it depends entirely on the CLASS, and not on
-   the TYPE.  This will remain true, even as new types are defined,
-   unless there is a compelling reason for a new type to complicate
-   matters by imposing type-specific rules.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 8]
-
-RFC 3490                          IDNA                        March 2003
-
-
-3.2.2. Non-domain-name data types stored in domain names
-
-   Although IDNA enables the representation of non-ASCII characters in
-   domain names, that does not imply that IDNA enables the
-   representation of non-ASCII characters in other data types that are
-   stored in domain names.  For example, an email address local part is
-   sometimes stored in a domain label (hostmaster at example.com would be
-   represented as hostmaster.example.com in the RDATA field of an SOA
-   record).  IDNA does not update the existing email standards, which
-   allow only ASCII characters in local parts.  Therefore, unless the
-   email standards are revised to invite the use of IDNA for local
-   parts, a domain label that holds the local part of an email address
-   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
-   be interpreted literally as a local part that happens to begin with
-   the ACE prefix.
-
-4. Conversion operations
-
-   An application converts a domain name put into an IDN-unaware slot or
-   displayed to a user.  This section specifies the steps to perform in
-   the conversion, and the ToASCII and ToUnicode operations.
-
-   The input to ToASCII or ToUnicode is a single label that is a
-   sequence of Unicode code points (remember that all ASCII code points
-   are also Unicode code points).  If a domain name is represented using
-   a character set other than Unicode or US-ASCII, it will first need to
-   be transcoded to Unicode.
-
-   Starting from a whole domain name, the steps that an application
-   takes to do the conversions are:
-
-   1) Decide whether the domain name is a "stored string" or a "query
-      string" as described in [STRINGPREP].  If this conversion follows
-      the "queries" rule from [STRINGPREP], set the flag called
-      "AllowUnassigned".
-
-   2) Split the domain name into individual labels as described in
-      section 3.1.  The labels do not include the separator.
-
-   3) For each label, decide whether or not to enforce the restrictions
-      on ASCII characters in host names [STD3].  (Applications already
-      faced this choice before the introduction of IDNA, and can
-      continue to make the decision the same way they always have; IDNA
-      makes no new recommendations regarding this choice.)  If the
-      restrictions are to be enforced, set the flag called
-      "UseSTD3ASCIIRules" for that label.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                     [Page 9]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   4) Process each label with either the ToASCII or the ToUnicode
-      operation as appropriate.  Typically, you use the ToASCII
-      operation if you are about to put the name into an IDN-unaware
-      slot, and you use the ToUnicode operation if you are displaying
-      the name to a user; section 3.1 gives greater detail on the
-      applicable requirements.
-
-   5) If ToASCII was applied in step 4 and dots are used as label
-      separators, change all the label separators to U+002E (full stop).
-
-   The following two subsections define the ToASCII and ToUnicode
-   operations that are used in step 4.
-
-   This description of the protocol uses specific procedure names, names
-   of flags, and so on, in order to facilitate the specification of the
-   protocol.  These names, as well as the actual steps of the
-   procedures, are not required of an implementation.  In fact, any
-   implementation which has the same external behavior as specified in
-   this document conforms to this specification.
-
-4.1 ToASCII
-
-   The ToASCII operation takes a sequence of Unicode code points that
-   make up one label and transforms it into a sequence of code points in
-   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
-   and the resulting sequence are equivalent labels.
-
-   It is important to note that the ToASCII operation can fail.  ToASCII
-   fails if any step of it fails.  If any step of the ToASCII operation
-   fails on any label in a domain name, that domain name MUST NOT be
-   used as an internationalized domain name.  The method for dealing
-   with this failure is application-specific.
-
-   The inputs to ToASCII are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToASCII is either a sequence of ASCII code points or a failure
-   condition.
-
-   ToASCII never alters a sequence of code points that are all in the
-   ASCII range to begin with (although it could fail).  Applying the
-   ToASCII operation multiple times has exactly the same effect as
-   applying it just once.
-
-   ToASCII consists of the following steps:
-
-   1. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 2, otherwise skip to step 3.
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 10]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
-
-     (a) Verify the absence of non-LDH ASCII code points; that is, the
-         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
-
-     (b) Verify the absence of leading and trailing hyphen-minus; that
-         is, the absence of U+002D at the beginning and end of the
-         sequence.
-
-   4. If the sequence contains any code points outside the ASCII range
-      (0..7F) then proceed to step 5, otherwise skip to step 8.
-
-   5. Verify that the sequence does NOT begin with the ACE prefix.
-
-   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
-      fail if there is an error.
-
-   7. Prepend the ACE prefix.
-
-   8. Verify that the number of code points is in the range 1 to 63
-      inclusive.
-
-4.2 ToUnicode
-
-   The ToUnicode operation takes a sequence of Unicode code points that
-   make up one label and returns a sequence of Unicode code points.  If
-   the input sequence is a label in ACE form, then the result is an
-   equivalent internationalized label that is not in ACE form, otherwise
-   the original sequence is returned unaltered.
-
-   ToUnicode never fails.  If any step fails, then the original input
-   sequence is returned immediately in that step.
-
-   The ToUnicode output never contains more code points than its input.
-   Note that the number of octets needed to represent a sequence of code
-   points depends on the particular character encoding used.
-
-   The inputs to ToUnicode are a sequence of code points, the
-   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
-   ToUnicode is always a sequence of Unicode code points.
-
-   1. If all code points in the sequence are in the ASCII range (0..7F)
-      then skip to step 3.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 11]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   2. Perform the steps specified in [NAMEPREP] and fail if there is an
-      error.  (If step 3 of ToASCII is also performed here, it will not
-      affect the overall behavior of ToUnicode, but it is not
-      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
-
-   3. Verify that the sequence begins with the ACE prefix, and save a
-      copy of the sequence.
-
-   4. Remove the ACE prefix.
-
-   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
-      fail if there is an error.  Save a copy of the result of this
-      step.
-
-   6. Apply ToASCII.
-
-   7. Verify that the result of step 6 matches the saved copy from step
-      3, using a case-insensitive ASCII comparison.
-
-   8. Return the saved copy from step 5.
-
-5. ACE prefix
-
-   The ACE prefix, used in the conversion operations (section 4), is two
-   alphanumeric ASCII characters followed by two hyphen-minuses.  It
-   cannot be any of the prefixes already used in earlier documents,
-   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
-   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
-   recognize the ACE prefix in a case-insensitive manner.
-
-   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
-
-   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
-   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
-   the encoding steps in [PUNYCODE].
-
-   While all ACE labels begin with the ACE prefix, not all labels
-   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
-   labels that begin with the ACE prefix will confuse users and SHOULD
-   NOT be allowed in DNS zones.
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 12]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6. Implications for typical applications using DNS
-
-   In IDNA, applications perform the processing needed to input
-   internationalized domain names from users, display internationalized
-   domain names to users, and process the inputs and outputs from DNS
-   and other protocols that carry domain names.
-
-   The components and interfaces between them can be represented
-   pictorially as:
-
-                    +------+
-                    | User |
-                    +------+
-                       ^
-                       | Input and display: local interface methods
-                       | (pen, keyboard, glowing phosphorus, ...)
-   +-------------------|-------------------------------+
-   |                   v                               |
-   |          +-----------------------------+          |
-   |          |        Application          |          |
-   |          |   (ToASCII and ToUnicode    |          |
-   |          |      operations may be      |          |
-   |          |        called here)         |          |
-   |          +-----------------------------+          |
-   |                   ^        ^                      | End system
-   |                   |        |                      |
-   | Call to resolver: |        | Application-specific |
-   |              ACE  |        | protocol:            |
-   |                   v        | ACE unless the       |
-   |           +----------+     | protocol is updated  |
-   |           | Resolver |     | to handle other      |
-   |           +----------+     | encodings            |
-   |                 ^          |                      |
-   +-----------------|----------|----------------------+
-       DNS protocol: |          |
-                 ACE |          |
-                     v          v
-          +-------------+    +---------------------+
-          | DNS servers |    | Application servers |
-          +-------------+    +---------------------+
-
-   The box labeled "Application" is where the application splits a
-   domain name into labels, sets the appropriate flags, and performs the
-   ToASCII and ToUnicode operations.  This is described in section 4.
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 13]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.1 Entry and display in applications
-
-   Applications can accept domain names using any character set or sets
-   desired by the application developer, and can display domain names in
-   any charset.  That is, the IDNA protocol does not affect the
-   interface between users and applications.
-
-   An IDNA-aware application can accept and display internationalized
-   domain names in two formats: the internationalized character set(s)
-   supported by the application, and as an ACE label.  ACE labels that
-   are displayed or input MUST always include the ACE prefix.
-   Applications MAY allow input and display of ACE labels, but are not
-   encouraged to do so except as an interface for special purposes,
-   possibly for debugging, or to cope with display limitations as
-   described in section 6.4..  ACE encoding is opaque and ugly, and
-   should thus only be exposed to users who absolutely need it.  Because
-   name labels encoded as ACE name labels can be rendered either as the
-   encoded ASCII characters or the proper decoded characters, the
-   application MAY have an option for the user to select the preferred
-   method of display; if it does, rendering the ACE SHOULD NOT be the
-   default.
-
-   Domain names are often stored and transported in many places.  For
-   example, they are part of documents such as mail messages and web
-   pages.  They are transported in many parts of many protocols, such as
-   both the control commands and the RFC 2822 body parts of SMTP, and
-   the headers and the body content in HTTP.  It is important to
-   remember that domain names appear both in domain name slots and in
-   the content that is passed over protocols.
-
-   In protocols and document formats that define how to handle
-   specification or negotiation of charsets, labels can be encoded in
-   any charset allowed by the protocol or document format.  If a
-   protocol or document format only allows one charset, the labels MUST
-   be given in that charset.
-
-   In any place where a protocol or document format allows transmission
-   of the characters in internationalized labels, internationalized
-   labels SHOULD be transmitted using whatever character encoding and
-   escape mechanism that the protocol or document format uses at that
-   place.
-
-   All protocols that use domain name slots already have the capacity
-   for handling domain names in the ASCII charset.  Thus, ACE labels
-   (internationalized labels that have been processed with the ToASCII
-   operation) can inherently be handled by those protocols.
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 14]
-
-RFC 3490                          IDNA                        March 2003
-
-
-6.2 Applications and resolver libraries
-
-   Applications normally use functions in the operating system when they
-   resolve DNS queries.  Those functions in the operating system are
-   often called "the resolver library", and the applications communicate
-   with the resolver libraries through a programming interface (API).
-
-   Because these resolver libraries today expect only domain names in
-   ASCII, applications MUST prepare labels that are passed to the
-   resolver library using the ToASCII operation.  Labels received from
-   the resolver library contain only ASCII characters; internationalized
-   labels that cannot be represented directly in ASCII use the ACE form.
-   ACE labels always include the ACE prefix.
-
-   An operating system might have a set of libraries for performing the
-   ToASCII operation.  The input to such a library might be in one or
-   more charsets that are used in applications (UTF-8 and UTF-16 are
-   likely candidates for almost any operating system, and script-
-   specific charsets are likely for localized operating systems).
-
-   IDNA-aware applications MUST be able to work with both non-
-   internationalized labels (those that conform to [STD13] and [STD3])
-   and internationalized labels.
-
-   It is expected that new versions of the resolver libraries in the
-   future will be able to accept domain names in other charsets than
-   ASCII, and application developers might one day pass not only domain
-   names in Unicode, but also in local script to a new API for the
-   resolver libraries in the operating system.  Thus the ToASCII and
-   ToUnicode operations might be performed inside these new versions of
-   the resolver libraries.
-
-   Domain names passed to resolvers or put into the question section of
-   DNS requests follow the rules for "queries" from [STRINGPREP].
-
-6.3 DNS servers
-
-   Domain names stored in zones follow the rules for "stored strings"
-   from [STRINGPREP].
-
-   For internationalized labels that cannot be represented directly in
-   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
-   operation.  All IDNs served by DNS servers MUST contain only ASCII
-   characters.
-
-   If a signaling system which makes negotiation possible between old
-   and new DNS clients and servers is standardized in the future, the
-   encoding of the query in the DNS protocol itself can be changed from
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 15]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   ACE to something else, such as UTF-8.  The question whether or not
-   this should be used is, however, a separate problem and is not
-   discussed in this memo.
-
-6.4 Avoiding exposing users to the raw ACE encoding
-
-   Any application that might show the user a domain name obtained from
-   a domain name slot, such as from gethostbyaddr or part of a mail
-   header, will need to be updated if it is to prevent users from seeing
-   the ACE.
-
-   If an application decodes an ACE name using ToUnicode but cannot show
-   all of the characters in the decoded name, such as if the name
-   contains characters that the output system cannot display, the
-   application SHOULD show the name in ACE format (which always includes
-   the ACE prefix) instead of displaying the name with the replacement
-   character (U+FFFD).  This is to make it easier for the user to
-   transfer the name correctly to other programs.  Programs that by
-   default show the ACE form when they cannot show all the characters in
-   a name label SHOULD also have a mechanism to show the name that is
-   produced by the ToUnicode operation with as many characters as
-   possible and replacement characters in the positions where characters
-   cannot be displayed.
-
-   The ToUnicode operation does not alter labels that are not valid ACE
-   labels, even if they begin with the ACE prefix.  After ToUnicode has
-   been applied, if a label still begins with the ACE prefix, then it is
-   not a valid ACE label, and is not equivalent to any of the
-   intermediate Unicode strings constructed by ToUnicode.
-
-6.5  DNSSEC authentication of IDN domain names
-
-   DNS Security [RFC2535] is a method for supplying cryptographic
-   verification information along with DNS messages.  Public Key
-   Cryptography is used in conjunction with digital signatures to
-   provide a means for a requester of domain information to authenticate
-   the source of the data.  This ensures that it can be traced back to a
-   trusted source, either directly, or via a chain of trust linking the
-   source of the information to the top of the DNS hierarchy.
-
-   IDNA specifies that all internationalized domain names served by DNS
-   servers that cannot be represented directly in ASCII must use the ACE
-   form produced by the ToASCII operation.  This operation must be
-   performed prior to a zone being signed by the private key for that
-   zone.  Because of this ordering, it is important to recognize that
-   DNSSEC authenticates the ASCII domain name, not the Unicode form or
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 16]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   the mapping between the Unicode form and the ASCII form.  In the
-   presence of DNSSEC, this is the name that MUST be signed in the zone
-   and MUST be validated against.
-
-   One consequence of this for sites deploying IDNA in the presence of
-   DNSSEC is that any special purpose proxies or forwarders used to
-   transform user input into IDNs must be earlier in the resolution flow
-   than DNSSEC authenticating nameservers for DNSSEC to work.
-
-7. Name server considerations
-
-   Existing DNS servers do not know the IDNA rules for handling non-
-   ASCII forms of IDNs, and therefore need to be shielded from them.
-   All existing channels through which names can enter a DNS server
-   database (for example, master files [STD13] and DNS update messages
-   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
-   requirement 2 of section 3.1 of this document provides the needed
-   shielding, by ensuring that internationalized domain names entering
-   DNS server databases through such channels have already been
-   converted to their equivalent ASCII forms.
-
-   It is imperative that there be only one ASCII encoding for a
-   particular domain name.  Because of the design of the ToASCII and
-   ToUnicode operations, there are no ACE labels that decode to ASCII
-   labels, and therefore name servers cannot contain multiple ASCII
-   encodings of the same domain name.
-
-   [RFC2181] explicitly allows domain labels to contain octets beyond
-   the ASCII range (0..7F), and this document does not change that.
-   Note, however, that there is no defined interpretation of octets
-   80..FF as characters.  If labels containing these octets are returned
-   to applications, unpredictable behavior could result.  The ASCII form
-   defined by ToASCII is the only standard representation for
-   internationalized labels in the current DNS protocol.
-
-8. Root server considerations
-
-   IDNs are likely to be somewhat longer than current domain names, so
-   the bandwidth needed by the root servers is likely to go up by a
-   small amount.  Also, queries and responses for IDNs will probably be
-   somewhat longer than typical queries today, so more queries and
-   responses may be forced to go to TCP instead of UDP.
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 17]
-
-RFC 3490                          IDNA                        March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
-                Unicode for use with Internationalized Domain Names in
-                Applications (IDNA)", RFC 3492, March 2003.
-
-   [STD3]       Braden, R., "Requirements for Internet Hosts --
-                Communication Layers", STD 3, RFC 1122, and
-                "Requirements for Internet Hosts -- Application and
-                Support", STD 3, RFC 1123, October 1989.
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034 and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9.2 Informative References
-
-   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
-                RFC 2535, March 1999.
-
-   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
-                Specification", RFC 2181, July 1997.
-
-   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
-                <http://www.unicode.org/unicode/reports/tr9/>.
-
-   [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/).
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 18]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-10. Security Considerations
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   This memo describes an algorithm which encodes characters that are
-   not valid according to STD3 and STD13 into octet values that are
-   valid.  No security issues such as string length increases or new
-   allowed values are introduced by the encoding process or the use of
-   these encoded values, apart from those introduced by the ACE encoding
-   itself.
-
-   Domain names are used by users to identify and connect to Internet
-   servers.  The security of the Internet is compromised if a user
-   entering a single internationalized name is connected to different
-   servers based on different interpretations of the internationalized
-   domain name.
-
-   When systems use local character sets other than ASCII and Unicode,
-   this specification leaves the the problem of transcoding between the
-   local character set and Unicode up to the application.  If different
-   applications (or different versions of one application) implement
-   different transcoding rules, they could interpret the same name
-   differently and contact different servers.  This problem is not
-   solved by security protocols like TLS that do not take local
-   character sets into account.
-
-   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
-   and [STRINGPREP], it includes the security considerations from those
-   documents as well.
-
-   If or when this specification is updated to use a more recent Unicode
-   normalization table, the new normalization table will need to be
-   compared with the old to spot backwards incompatible changes.  If
-   there are such changes, they will need to be handled somehow, or
-   there will be security as well as operational implications.  Methods
-   to handle the conflicts could include keeping the old normalization,
-   or taking care of the conflicting characters by operational means, or
-   some other method.
-
-   Implementations MUST NOT use more recent normalization tables than
-   the one referenced from this document, even though more recent tables
-   may be provided by operating systems.  If an application is unsure of
-   which version of the normalization tables are in the operating
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 19]
-
-RFC 3490                          IDNA                        March 2003
-
-
-   system, the application needs to include the normalization tables
-   itself.  Using normalization tables other than the one referenced
-   from this specification could have security and operational
-   implications.
-
-   To help prevent confusion between characters that are visually
-   similar, it is suggested that implementations provide visual
-   indications where a domain name contains multiple scripts.  Such
-   mechanisms can also be used to show when a name contains a mixture of
-   simplified and traditional Chinese characters, or to distinguish zero
-   and one from O and l.  DNS zone adminstrators may impose restrictions
-   (subject to the limitations in section 2) that try to minimize
-   homographs.
-
-   Domain names (or portions of them) are sometimes compared against a
-   set of privileged or anti-privileged domains.  In such situations it
-   is especially important that the comparisons be done properly, as
-   specified in section 3.1 requirement 4.  For labels already in ASCII
-   form, the proper comparison reduces to the same case-insensitive
-   ASCII comparison that has always been used for ASCII labels.
-
-   The introduction of IDNA means that any existing labels that start
-   with the ACE prefix and would be altered by ToUnicode will
-   automatically be ACE labels, and will be considered equivalent to
-   non-ASCII labels, whether or not that was the intent of the zone
-   adminstrator or registrant.
-
-11. IANA Considerations
-
-   IANA has assigned the ACE prefix in consultation with the IESG.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 20]
-
-RFC 3490                          IDNA                        March 2003
-
-
-12. Authors' Addresses
-
-   Patrik Faltstrom
-   Cisco Systems
-   Arstaangsvagen 31 J
-   S-117 43 Stockholm  Sweden
-
-   EMail: paf at cisco.com
-
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060  USA
-
-   EMail: phoffman at imc.org
-
-
-   Adam M. Costello
-   University of California, Berkeley
-
-   URL: http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 21]
-
-RFC 3490                          IDNA                        March 2003
-
-
-13. Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Faltstrom, et al.           Standards Track                    [Page 22]
-

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3491.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3491.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3491.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                         P. Hoffman
-Request for Comments: 3491                                    IMC & VPNC
-Category: Standards Track                                    M. Blanchet
-                                                                Viagenie
-                                                              March 2003
-
-
-                   Nameprep: A Stringprep Profile for
-                  Internationalized Domain Names (IDN)
-
-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 (2003).  All Rights Reserved.
-
-Abstract
-
-   This document describes how to prepare internationalized domain name
-   (IDN) labels in order to increase the likelihood that name input and
-   name comparison work in ways that make sense for typical users
-   throughout the world.  This profile of the stringprep protocol is
-   used as part of a suite of on-the-wire protocols for
-   internationalizing the Domain Name System (DNS).
-
-1. Introduction
-
-   This document specifies processing rules that will allow users to
-   enter internationalized domain names (IDNs) into applications and
-   have the highest chance of getting the content of the strings
-   correct.  It is a profile of stringprep [STRINGPREP].  These
-   processing rules are only intended for internationalized domain
-   names, not for arbitrary text.
-
-   This profile defines the following, as required by [STRINGPREP].
-
-   -  The intended applicability of the profile: internationalized
-      domain names processed by IDNA.
-
-   -  The character repertoire that is the input and output to
-      stringprep:  Unicode 3.2, specified in section 2.
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 1]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-   -  The mappings used: specified in section 3.
-
-   -  The Unicode normalization used: specified in section 4.
-
-   -  The characters that are prohibited as output: specified in section
-      5.
-
-   -  Bidirectional character handling: specified in section 6.
-
-1.1 Interaction of protocol parts
-
-   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
-   names; it is not designed for any other purpose.  It is explicitly
-   not designed for processing arbitrary free text and SHOULD NOT be
-   used for that purpose.  Nameprep is a profile of Stringprep
-   [STRINGPREP].  Implementations of Nameprep MUST fully implement
-   Stringprep.
-
-   Nameprep is used to process domain name labels, not domain names.
-   IDNA calls nameprep for each label in a domain name, not for the
-   whole domain name.
-
-1.2 Terminology
-
-   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
-   in this document are to be interpreted as described in BCP 14, RFC
-   2119 [RFC2119].
-
-2. Character Repertoire
-
-   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
-
-3. Mapping
-
-   This profile specifies mapping using the following tables from
-   [STRINGPREP]:
-
-   Table B.1
-   Table B.2
-
-4. Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in [STRINGPREP].
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 2]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-5. Prohibited Output
-
-   This profile specifies prohibiting using the following tables from
-   [STRINGPREP]:
-
-   Table C.1.2
-   Table C.2.2
-   Table C.3
-   Table C.4
-   Table C.5
-   Table C.6
-   Table C.7
-   Table C.8
-   Table C.9
-
-   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
-   The IDNA protocol has additional prohibitions that are checked
-   outside of this profile.
-
-6. Bidirectional characters
-
-   This profile specifies checking bidirectional strings as described in
-   [STRINGPREP] section 6.
-
-7. Unassigned Code Points in Internationalized Domain Names
-
-   If the processing in [IDNA] specifies that a list of unassigned code
-   points be used, the system uses table A.1 from [STRINGPREP] as its
-   list of unassigned code points.
-
-8. References
-
-8.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 3]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-8.2 Informative references
-
-   [STD13]      Mockapetris, P., "Domain names - concepts and
-                facilities", STD 13, RFC 1034, and "Domain names -
-                implementation and specification", STD 13, RFC 1035,
-                November 1987.
-
-9. Security Considerations
-
-   The Unicode and ISO/IEC 10646 repertoires have many characters that
-   look similar.  In many cases, users of security protocols might do
-   visual matching, such as when comparing the names of trusted third
-   parties.  Because it is impossible to map similar-looking characters
-   without a great deal of context such as knowing the fonts used,
-   stringprep does nothing to map similar-looking characters together
-   nor to prohibit some characters because they look like others.
-
-   Security on the Internet partly relies on the DNS.  Thus, any change
-   to the characteristics of the DNS can change the security of much of
-   the Internet.
-
-   Domain names are used by users to connect to Internet servers.  The
-   security of the Internet would be compromised if a user entering a
-   single internationalized name could be connected to different servers
-   based on different interpretations of the internationalized domain
-   name.
-
-   Current applications might assume that the characters allowed in
-   domain names will always be the same as they are in [STD13].  This
-   document vastly increases the number of characters available in
-   domain names.  Every program that uses "special" characters in
-   conjunction with domain names may be vulnerable to attack based on
-   the new characters allowed by this specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 4]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-10. IANA Considerations
-
-   This is a profile of stringprep.  It has been registered by the IANA
-   in the stringprep profile registry
-   (www.iana.org/assignments/stringprep-profiles).
-
-      Name of this profile:
-         Nameprep
-
-      RFC in which the profile is defined:
-         This document.
-
-      Indicator whether or not this is the newest version of the
-      profile:
-         This is the first version of Nameprep.
-
-11. Acknowledgements
-
-   Many people from the IETF IDN Working Group and the Unicode Technical
-   Committee contributed ideas that went into this document.
-
-   The IDN Nameprep design team made many useful changes to the
-   document.  That team and its advisors include:
-
-      Asmus Freytag
-      Cathy Wissink
-      Francois Yergeau
-      James Seng
-      Marc Blanchet
-      Mark Davis
-      Martin Duerst
-      Patrik Faltstrom
-      Paul Hoffman
-
-   Additional significant improvements were proposed by:
-
-      Jonathan Rosenne
-      Kent Karlsson
-      Scott Hollenbeck
-      Dave Crocker
-      Erik Nordmark
-      Matitiahu Allouche
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 5]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-12. Authors' Addresses
-
-   Paul Hoffman
-   Internet Mail Consortium and VPN Consortium
-   127 Segre Place
-   Santa Cruz, CA  95060 USA
-
-   EMail: paul.hoffman at imc.org and paul.hoffman at vpnc.org
-
-
-   Marc Blanchet
-   Viagenie inc.
-   2875 boul. Laurier, bur. 300
-   Ste-Foy, Quebec, Canada, G1V 2M2
-
-   EMail: Marc.Blanchet at viagenie.qc.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 6]
-
-RFC 3491                      IDN Nameprep                    March 2003
-
-
-13.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Hoffman & Blanchet          Standards Track                     [Page 7]
-

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3492.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3492.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc3492.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        A. Costello
-Request for Comments: 3492                 Univ. of California, Berkeley
-Category: Standards Track                                     March 2003
-
-
-              Punycode: A Bootstring encoding of Unicode
-       for Internationalized Domain Names in Applications (IDNA)
-
-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 (2003).  All Rights Reserved.
-
-Abstract
-
-   Punycode is a simple and efficient transfer encoding syntax designed
-   for use with Internationalized Domain Names in Applications (IDNA).
-   It uniquely and reversibly transforms a Unicode string into an ASCII
-   string.  ASCII characters in the Unicode string are represented
-   literally, and non-ASCII characters are represented by ASCII
-   characters that are allowed in host name labels (letters, digits, and
-   hyphens).  This document defines a general algorithm called
-   Bootstring that allows a string of basic code points to uniquely
-   represent any string of code points drawn from a larger set.
-   Punycode is an instance of Bootstring that uses particular parameter
-   values specified by this document, appropriate for IDNA.
-
-Table of Contents
-
-   1. Introduction...............................................2
-       1.1 Features..............................................2
-       1.2 Interaction of protocol parts.........................3
-   2. Terminology................................................3
-   3. Bootstring description.....................................4
-       3.1 Basic code point segregation..........................4
-       3.2 Insertion unsort coding...............................4
-       3.3 Generalized variable-length integers..................5
-       3.4 Bias adaptation.......................................7
-   4. Bootstring parameters......................................8
-   5. Parameter values for Punycode..............................8
-   6. Bootstring algorithms......................................9
-
-
-
-Costello                    Standards Track                     [Page 1]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-       6.1 Bias adaptation function.............................10
-       6.2 Decoding procedure...................................11
-       6.3 Encoding procedure...................................12
-       6.4 Overflow handling....................................13
-   7. Punycode examples.........................................14
-       7.1 Sample strings.......................................14
-       7.2 Decoding traces......................................17
-       7.3 Encoding traces......................................19
-   8. Security Considerations...................................20
-   9. References................................................21
-       9.1 Normative References.................................21
-       9.2 Informative References...............................21
-   A. Mixed-case annotation.....................................22
-   B. Disclaimer and license....................................22
-   C. Punycode sample implementation............................23
-   Author's Address.............................................34
-   Full Copyright Statement.....................................35
-
-1. Introduction
-
-   [IDNA] describes an architecture for supporting internationalized
-   domain names.  Labels containing non-ASCII characters can be
-   represented by ACE labels, which begin with a special ACE prefix and
-   contain only ASCII characters.  The remainder of the label after the
-   prefix is a Punycode encoding of a Unicode string satisfying certain
-   constraints.  For the details of the prefix and constraints, see
-   [IDNA] and [NAMEPREP].
-
-   Punycode is an instance of a more general algorithm called
-   Bootstring, which allows strings composed from a small set of "basic"
-   code points to uniquely represent any string of code points drawn
-   from a larger set.  Punycode is Bootstring with particular parameter
-   values appropriate for IDNA.
-
-1.1 Features
-
-   Bootstring has been designed to have the following features:
-
-   *  Completeness:  Every extended string (sequence of arbitrary code
-      points) can be represented by a basic string (sequence of basic
-      code points).  Restrictions on what strings are allowed, and on
-      length, can be imposed by higher layers.
-
-   *  Uniqueness:  There is at most one basic string that represents a
-      given extended string.
-
-   *  Reversibility:  Any extended string mapped to a basic string can
-      be recovered from that basic string.
-
-
-
-Costello                    Standards Track                     [Page 2]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   *  Efficient encoding:  The ratio of basic string length to extended
-      string length is small.  This is important in the context of
-      domain names because RFC 1034 [RFC1034] restricts the length of a
-      domain label to 63 characters.
-
-   *  Simplicity:  The encoding and decoding algorithms are reasonably
-      simple to implement.  The goals of efficiency and simplicity are
-      at odds; Bootstring aims at a good balance between them.
-
-   *  Readability:  Basic code points appearing in the extended string
-      are represented as themselves in the basic string (although the
-      main purpose is to improve efficiency, not readability).
-
-   Punycode can also support an additional feature that is not used by
-   the ToASCII and ToUnicode operations of [IDNA].  When extended
-   strings are case-folded prior to encoding, the basic string can use
-   mixed case to tell how to convert the folded string into a mixed-case
-   string.  See appendix A "Mixed-case annotation".
-
-1.2 Interaction of protocol parts
-
-   Punycode is used by the IDNA protocol [IDNA] for converting domain
-   labels into ASCII; it is not designed for any other purpose.  It is
-   explicitly not designed for processing arbitrary free text.
-
-2. Terminology
-
-   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, RFC 2119
-   [RFC2119].
-
-   A code point is an integral value associated with a character in a
-   coded character set.
-
-   As in the Unicode Standard [UNICODE], Unicode code points are denoted
-   by "U+" followed by four to six hexadecimal digits, while a range of
-   code points is denoted by two hexadecimal numbers separated by "..",
-   with no prefixes.
-
-   The operators div and mod perform integer division; (x div y) is the
-   quotient of x divided by y, discarding the remainder, and (x mod y)
-   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
-   these operators only with nonnegative operands, so the quotient and
-   remainder are always nonnegative.
-
-   The break statement jumps out of the innermost loop (as in C).
-
-
-
-
-Costello                    Standards Track                     [Page 3]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   An overflow is an attempt to compute a value that exceeds the maximum
-   value of an integer variable.
-
-3. Bootstring description
-
-   Bootstring represents an arbitrary sequence of code points (the
-   "extended string") as a sequence of basic code points (the "basic
-   string").  This section describes the representation.  Section 6
-   "Bootstring algorithms" presents the algorithms as pseudocode.
-   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
-   algorithms for sample inputs.
-
-   The following sections describe the four techniques used in
-   Bootstring.  "Basic code point segregation" is a very simple and
-   efficient encoding for basic code points occurring in the extended
-   string: they are simply copied all at once.  "Insertion unsort
-   coding" encodes the non-basic code points as deltas, and processes
-   the code points in numerical order rather than in order of
-   appearance, which typically results in smaller deltas.  The deltas
-   are represented as "generalized variable-length integers", which use
-   basic code points to represent nonnegative integers.  The parameters
-   of this integer representation are dynamically adjusted using "bias
-   adaptation", to improve efficiency when consecutive deltas have
-   similar magnitudes.
-
-3.1 Basic code point segregation
-
-   All basic code points appearing in the extended string are
-   represented literally at the beginning of the basic string, in their
-   original order, followed by a delimiter if (and only if) the number
-   of basic code points is nonzero.  The delimiter is a particular basic
-   code point, which never appears in the remainder of the basic string.
-   The decoder can therefore find the end of the literal portion (if
-   there is one) by scanning for the last delimiter.
-
-3.2 Insertion unsort coding
-
-   The remainder of the basic string (after the last delimiter if there
-   is one) represents a sequence of nonnegative integral deltas as
-   generalized variable-length integers, described in section 3.3.  The
-   meaning of the deltas is best understood in terms of the decoder.
-
-   The decoder builds the extended string incrementally.  Initially, the
-   extended string is a copy of the literal portion of the basic string
-   (excluding the last delimiter).  The decoder inserts non-basic code
-   points, one for each delta, into the extended string, ultimately
-   arriving at the final decoded string.
-
-
-
-
-Costello                    Standards Track                     [Page 4]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   At the heart of this process is a state machine with two state
-   variables: an index i and a counter n.  The index i refers to a
-   position in the extended string; it ranges from 0 (the first
-   position) to the current length of the extended string (which refers
-   to a potential position beyond the current end).  If the current
-   state is <n,i>, the next state is <n,i+1> if i is less than the
-   length of the extended string, or <n+1,0> if i equals the length of
-   the extended string.  In other words, each state change causes i to
-   increment, wrapping around to zero if necessary, and n counts the
-   number of wrap-arounds.
-
-   Notice that the state always advances monotonically (there is no way
-   for the decoder to return to an earlier state).  At each state, an
-   insertion is either performed or not performed.  At most one
-   insertion is performed in a given state.  An insertion inserts the
-   value of n at position i in the extended string.  The deltas are a
-   run-length encoding of this sequence of events: they are the lengths
-   of the runs of non-insertion states preceeding the insertion states.
-   Hence, for each delta, the decoder performs delta state changes, then
-   an insertion, and then one more state change.  (An implementation
-   need not perform each state change individually, but can instead use
-   division and remainder calculations to compute the next insertion
-   state directly.)  It is an error if the inserted code point is a
-   basic code point (because basic code points were supposed to be
-   segregated as described in section 3.1).
-
-   The encoder's main task is to derive the sequence of deltas that will
-   cause the decoder to construct the desired string.  It can do this by
-   repeatedly scanning the extended string for the next code point that
-   the decoder would need to insert, and counting the number of state
-   changes the decoder would need to perform, mindful of the fact that
-   the decoder's extended string will include only those code points
-   that have already been inserted.  Section 6.3 "Encoding procedure"
-   gives a precise algorithm.
-
-3.3 Generalized variable-length integers
-
-   In a conventional integer representation the base is the number of
-   distinct symbols for digits, whose values are 0 through base-1.  Let
-   digit_0 denote the least significant digit, digit_1 the next least
-   significant, and so on.  The value represented is the sum over j of
-   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
-   position j.  For example, in the base 8 integer 437, the digits are
-   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
-   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
-   there are multiple encodings of each value (because there can be
-   extra zeros in the most significant positions), which is inconvenient
-
-
-
-
-Costello                    Standards Track                     [Page 5]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   when unique encodings are needed.  Second, the integer is not self-
-   delimiting, so if multiple integers are concatenated the boundaries
-   between them are lost.
-
-   The generalized variable-length representation solves these two
-   problems.  The digit values are still 0 through base-1, but now the
-   integer is self-delimiting by means of thresholds t(j), each of which
-   is in the range 0 through base-1.  Exactly one digit, the most
-   significant, satisfies digit_j < t(j).  Therefore, if several
-   integers are concatenated, it is easy to separate them, starting with
-   the first if they are little-endian (least significant digit first),
-   or starting with the last if they are big-endian (most significant
-   digit first).  As before, the value is the sum over j of digit_j *
-   w(j), but the weights are different:
-
-      w(0) = 1
-      w(j) = w(j-1) * (base - t(j-1)) for j > 0
-
-   For example, consider the little-endian sequence of base 8 digits
-   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
-   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
-   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
-   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
-   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
-   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
-   similar to decoding a conventional integer:  Start with a current
-   value of N = 0 and a weight w = 1.  Fetch the next digit d and
-   increase N by d * w.  If d is less than the current threshold (t)
-   then stop, otherwise increase w by a factor of (base - t), update t
-   for the next position, and repeat.
-
-   Encoding this representation is similar to encoding a conventional
-   integer:  If N < t then output one digit for N and stop, otherwise
-   output the digit for t + ((N - t) mod (base - t)), then replace N
-   with (N - t) div (base - t), update t for the next position, and
-   repeat.
-
-   For any particular set of values of t(j), there is exactly one
-   generalized variable-length representation of each nonnegative
-   integral value.
-
-   Bootstring uses little-endian ordering so that the deltas can be
-   separated starting with the first.  The t(j) values are defined in
-   terms of the constants base, tmin, and tmax, and a state variable
-   called bias:
-
-      t(j) = base * (j + 1) - bias,
-      clamped to the range tmin through tmax
-
-
-
-Costello                    Standards Track                     [Page 6]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The clamping means that if the formula yields a value less than tmin
-   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
-   the pseudocode in section 6 "Bootstring algorithms", the expression
-   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
-   values cause the representation to favor integers within a particular
-   range determined by the bias.
-
-3.4 Bias adaptation
-
-   After each delta is encoded or decoded, bias is set for the next
-   delta as follows:
-
-   1. Delta is scaled in order to avoid overflow in the next step:
-
-         let delta = delta div 2
-
-      But when this is the very first delta, the divisor is not 2, but
-      instead a constant called damp.  This compensates for the fact
-      that the second delta is usually much smaller than the first.
-
-   2. Delta is increased to compensate for the fact that the next delta
-      will be inserting into a longer string:
-
-         let delta = delta + (delta div numpoints)
-
-      numpoints is the total number of code points encoded/decoded so
-      far (including the one corresponding to this delta itself, and
-      including the basic code points).
-
-   3. Delta is repeatedly divided until it falls within a threshold, to
-      predict the minimum number of digits needed to represent the next
-      delta:
-
-         while delta > ((base - tmin) * tmax) div 2
-         do let delta = delta div (base - tmin)
-
-   4. The bias is set:
-
-         let bias =
-           (base * the number of divisions performed in step 3) +
-           (((base - tmin + 1) * delta) div (delta + skew))
-
-      The motivation for this procedure is that the current delta
-      provides a hint about the likely size of the next delta, and so
-      t(j) is set to tmax for the more significant digits starting with
-      the one expected to be last, tmin for the less significant digits
-      up through the one expected to be third-last, and somewhere
-      between tmin and tmax for the digit expected to be second-last
-
-
-
-Costello                    Standards Track                     [Page 7]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      (balancing the hope of the expected-last digit being unnecessary
-      against the danger of it being insufficient).
-
-4. Bootstring parameters
-
-   Given a set of basic code points, one needs to be designated as the
-   delimiter.  The base cannot be greater than the number of
-   distinguishable basic code points remaining.  The digit-values in the
-   range 0 through base-1 need to be associated with distinct non-
-   delimiter basic code points.  In some cases multiple code points need
-   to have the same digit-value; for example, uppercase and lowercase
-   versions of the same letter need to be equivalent if basic strings
-   are case-insensitive.
-
-   The initial value of n cannot be greater than the minimum non-basic
-   code point that could appear in extended strings.
-
-   The remaining five parameters (tmin, tmax, skew, damp, and the
-   initial value of bias) need to satisfy the following constraints:
-
-      0 <= tmin <= tmax <= base-1
-      skew >= 1
-      damp >= 2
-      initial_bias mod base <= base - tmin
-
-   Provided the constraints are satisfied, these five parameters affect
-   efficiency but not correctness.  They are best chosen empirically.
-
-   If support for mixed-case annotation is desired (see appendix A),
-   make sure that the code points corresponding to 0 through tmax-1 all
-   have both uppercase and lowercase forms.
-
-5. Parameter values for Punycode
-
-   Punycode uses the following Bootstring parameter values:
-
-      base         = 36
-      tmin         = 1
-      tmax         = 26
-      skew         = 38
-      damp         = 700
-      initial_bias = 72
-      initial_n    = 128 = 0x80
-
-   Although the only restriction Punycode imposes on the input integers
-   is that they be nonnegative, these parameters are especially designed
-   to work well with Unicode [UNICODE] code points, which are integers
-   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
-
-
-
-Costello                    Standards Track                     [Page 8]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   use by the UTF-16 encoding of Unicode).  The basic code points are
-   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
-   delimiter, and some of the others have digit-values as follows:
-
-      code points    digit-values
-      ------------   ----------------------
-      41..5A (A-Z) =  0 to 25, respectively
-      61..7A (a-z) =  0 to 25, respectively
-      30..39 (0-9) = 26 to 35, respectively
-
-   Using hyphen-minus as the delimiter implies that the encoded string
-   can end with a hyphen-minus only if the Unicode string consists
-   entirely of basic code points, but IDNA forbids such strings from
-   being encoded.  The encoded string can begin with a hyphen-minus, but
-   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
-   the RFC 952 rule that host name labels neither begin nor end with a
-   hyphen-minus [RFC952].
-
-   A decoder MUST recognize the letters in both uppercase and lowercase
-   forms (including mixtures of both forms).  An encoder SHOULD output
-   only uppercase forms or only lowercase forms, unless it uses mixed-
-   case annotation (see appendix A).
-
-   Presumably most users will not manually write or type encoded strings
-   (as opposed to cutting and pasting them), but those who do will need
-   to be alert to the potential visual ambiguity between the following
-   sets of characters:
-
-      G 6
-      I l 1
-      O 0
-      S 5
-      U V
-      Z 2
-
-   Such ambiguities are usually resolved by context, but in a Punycode
-   encoded string there is no context apparent to humans.
-
-6. Bootstring algorithms
-
-   Some parts of the pseudocode can be omitted if the parameters satisfy
-   certain conditions (for which Punycode qualifies).  These parts are
-   enclosed in {braces}, and notes immediately following the pseudocode
-   explain the conditions under which they can be omitted.
-
-
-
-
-
-
-
-Costello                    Standards Track                     [Page 9]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Formally, code points are integers, and hence the pseudocode assumes
-   that arithmetic operations can be performed directly on code points.
-   In some programming languages, explicit conversion between code
-   points and integers might be necessary.
-
-6.1 Bias adaptation function
-
-   function adapt(delta,numpoints,firsttime):
-     if firsttime then let delta = delta div damp
-     else let delta = delta div 2
-     let delta = delta + (delta div numpoints)
-     let k = 0
-     while delta > ((base - tmin) * tmax) div 2 do begin
-       let delta = delta div (base - tmin)
-       let k = k + base
-     end
-     return k + (((base - tmin + 1) * delta) div (delta + skew))
-
-   It does not matter whether the modifications to delta and k inside
-   adapt() affect variables of the same name inside the
-   encoding/decoding procedures, because after calling adapt() the
-   caller does not read those variables before overwriting them.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 10]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-6.2 Decoding procedure
-
-   let n = initial_n
-   let i = 0
-   let bias = initial_bias
-   let output = an empty string indexed from 0
-   consume all code points before the last delimiter (if there is one)
-     and copy them to output, fail on any non-basic code point
-   if more than zero code points were consumed then consume one more
-     (which will be the last delimiter)
-   while the input is not exhausted do begin
-     let oldi = i
-     let w = 1
-     for k = base to infinity in steps of base do begin
-       consume a code point, or fail if there was none to consume
-       let digit = the code point's digit-value, fail if it has none
-       let i = i + digit * w, fail on overflow
-       let t = tmin if k <= bias {+ tmin}, or
-               tmax if k >= bias + tmax, or k - bias otherwise
-       if digit < t then break
-       let w = w * (base - t), fail on overflow
-     end
-     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
-     let n = n + i div (length(output) + 1), fail on overflow
-     let i = i mod (length(output) + 1)
-     {if n is a basic code point then fail}
-     insert n into output at position i
-     increment i
-   end
-
-   The full statement enclosed in braces (checking whether n is a basic
-   code point) can be omitted if initial_n exceeds all basic code points
-   (which is true for Punycode), because n is never less than initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   Because the decoder state can only advance monotonically, and there
-   is only one representation of any delta, there is therefore only one
-   encoded string that can represent a given sequence of integers.  The
-   only error conditions are invalid code points, unexpected end-of-
-   input, overflow, and basic code points encoded using deltas instead
-   of appearing literally.  If the decoder fails on these errors as
-   shown above, then it cannot produce the same output for two distinct
-   inputs.  Without this property it would have been necessary to re-
-
-
-
-Costello                    Standards Track                    [Page 11]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   encode the output and verify that it matches the input in order to
-   guarantee the uniqueness of the encoding.
-
-6.3 Encoding procedure
-
-   let n = initial_n
-   let delta = 0
-   let bias = initial_bias
-   let h = b = the number of basic code points in the input
-   copy them to the output in order, followed by a delimiter if b > 0
-   {if the input contains a non-basic code point < n then fail}
-   while h < length(input) do begin
-     let m = the minimum {non-basic} code point >= n in the input
-     let delta = delta + (m - n) * (h + 1), fail on overflow
-     let n = m
-     for each code point c in the input (in order) do begin
-       if c < n {or c is basic} then increment delta, fail on overflow
-       if c == n then begin
-         let q = delta
-         for k = base to infinity in steps of base do begin
-           let t = tmin if k <= bias {+ tmin}, or
-                   tmax if k >= bias + tmax, or k - bias otherwise
-           if q < t then break
-           output the code point for digit t + ((q - t) mod (base - t))
-           let q = (q - t) div (base - t)
-         end
-         output the code point for digit q
-         let bias = adapt(delta, h + 1, test h equals b?)
-         let delta = 0
-         increment h
-       end
-     end
-     increment delta and n
-   end
-
-   The full statement enclosed in braces (checking whether the input
-   contains a non-basic code point less than n) can be omitted if all
-   code points less than initial_n are basic code points (which is true
-   for Punycode if code points are unsigned).
-
-   The brace-enclosed conditions "non-basic" and "or c is basic" can be
-   omitted if initial_n exceeds all basic code points (which is true for
-   Punycode), because the code point being tested is never less than
-   initial_n.
-
-   In the assignment of t, where t is clamped to the range tmin through
-   tmax, "+ tmin" can always be omitted.  This makes the clamping
-   calculation incorrect when bias < k < bias + tmin, but that cannot
-
-
-
-Costello                    Standards Track                    [Page 12]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   happen because of the way bias is computed and because of the
-   constraints on the parameters.
-
-   The checks for overflow are necessary to avoid producing invalid
-   output when the input contains very large values or is very long.
-
-   The increment of delta at the bottom of the outer loop cannot
-   overflow because delta < length(input) before the increment, and
-   length(input) is already assumed to be representable.  The increment
-   of n could overflow, but only if h == length(input), in which case
-   the procedure is finished anyway.
-
-6.4 Overflow handling
-
-   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
-   IDNA labels without overflow, because any string that needed a 27-bit
-   delta would have to exceed either the code point limit (0..10FFFF) or
-   the label length limit (63 characters).  However, overflow handling
-   is necessary because the inputs are not necessarily valid IDNA
-   labels.
-
-   If the programming language does not provide overflow detection, the
-   following technique can be used.  Suppose A, B, and C are
-   representable nonnegative integers and C is nonzero.  Then A + B
-   overflows if and only if B > maxint - A, and A + (B * C) overflows if
-   and only if B > (maxint - A) div C, where maxint is the greatest
-   integer for which maxint + 1 cannot be represented.  Refer to
-   appendix C "Punycode sample implementation" for demonstrations of
-   this technique in the C language.
-
-   The decoding and encoding algorithms shown in sections 6.2 and 6.3
-   handle overflow by detecting it whenever it happens.  Another
-   approach is to enforce limits on the inputs that prevent overflow
-   from happening.  For example, if the encoder were to verify that no
-   input code points exceed M and that the input length does not exceed
-   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
-   hence no overflow could occur if integer variables were capable of
-   representing values that large.  This prevention approach would
-   impose more restrictions on the input than the detection approach
-   does, but might be considered simpler in some programming languages.
-
-   In theory, the decoder could use an analogous approach, limiting the
-   number of digits in a variable-length integer (that is, limiting the
-   number of iterations in the innermost loop).  However, the number of
-   digits that suffice to represent a given delta can sometimes
-   represent much larger deltas (because of the adaptation), and hence
-   this approach would probably need integers wider than 32 bits.
-
-
-
-
-Costello                    Standards Track                    [Page 13]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Yet another approach for the decoder is to allow overflow to occur,
-   but to check the final output string by re-encoding it and comparing
-   to the decoder input.  If and only if they do not match (using a
-   case-insensitive ASCII comparison) overflow has occurred.  This
-   delayed-detection approach would not impose any more restrictions on
-   the input than the immediate-detection approach does, and might be
-   considered simpler in some programming languages.
-
-   In fact, if the decoder is used only inside the IDNA ToUnicode
-   operation [IDNA], then it need not check for overflow at all, because
-   ToUnicode performs a higher level re-encoding and comparison, and a
-   mismatch has the same consequence as if the Punycode decoder had
-   failed.
-
-7. Punycode examples
-
-7.1 Sample strings
-
-   In the Punycode encodings below, the ACE prefix is not shown.
-   Backslashes show where line breaks have been inserted in strings too
-   long for one line.
-
-   The first several examples are all translations of the sentence "Why
-   can't they just speak in <language>?" (courtesy of Michael Kaplan's
-   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
-   been removed, as is often done in domain names.
-
-   (A) Arabic (Egyptian):
-       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
-       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
-       Punycode: egbpdaj6bu4bxfgehfvwxn
-
-   (B) Chinese (simplified):
-       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
-       Punycode: ihqwcrb4cv8a8dqg056pqjye
-
-   (C) Chinese (traditional):
-       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
-       Punycode: ihqwctvzc91f659drss3x8bo0yb
-
-   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
-       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
-       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
-       u+0065 u+0073 u+006B u+0079
-       Punycode: Proprostnemluvesky-uyb24dma41a
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 14]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   (E) Hebrew:
-       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
-       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
-       u+05D1 u+05E8 u+05D9 u+05EA
-       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
-
-   (F) Hindi (Devanagari):
-       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
-       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
-       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
-       u+0939 u+0948 u+0902
-       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
-
-   (G) Japanese (kanji and hiragana):
-       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
-       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
-       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
-
-   (H) Korean (Hangul syllables):
-       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
-       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
-       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
-       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
-                 psd879ccm6fea98c
-
-   (I) Russian (Cyrillic):
-       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
-       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
-       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
-       u+0438
-       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
-
-   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
-       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
-       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
-       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
-       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
-       u+0061 u+00F1 u+006F u+006C
-       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
-
-   (K) Vietnamese:
-       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
-       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
-       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
-       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
-       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
-       U+0056 u+0069 u+1EC7 u+0074
-       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
-
-
-
-Costello                    Standards Track                    [Page 15]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   The next several examples are all names of Japanese music artists,
-   song titles, and TV programs, just because the author happens to have
-   them handy (but Japanese is useful for providing examples of single-
-   row text, two-row text, ideographic text, and various mixtures
-   thereof).
-
-   (L) 3<nen>B<gumi><kinpachi><sensei>
-       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
-       Punycode: 3B-ww4c5e180e575a65lsy2b
-
-   (M) <amuro><namie>-with-SUPER-MONKEYS
-       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
-       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
-       U+004F U+004E U+004B U+0045 U+0059 U+0053
-       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
-
-   (N) Hello-Another-Way-<sorezore><no><basho>
-       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
-       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
-       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
-       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
-
-   (O) <hitotsu><yane><no><shita>2
-       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
-       Punycode: 2-u9tlzr9756bt3uc0v
-
-   (P) Maji<de>Koi<suru>5<byou><mae>
-       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
-       u+308B u+0035 u+79D2 u+524D
-       Punycode: MajiKoi5-783gue6qz075azm5e
-
-   (Q) <pafii>de<runba>
-       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
-       Punycode: de-jg4avhby1noc0d
-
-   (R) <sono><supiido><de>
-       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
-       Punycode: d9juau41awczczp
-
-   The last example is an ASCII string that breaks the existing rules
-   for host name labels.  (It is not a realistic example for IDNA,
-   because IDNA never encodes pure ASCII labels.)
-
-   (S) -> $1.00 <-
-       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
-       u+003C u+002D
-       Punycode: -> $1.00 <--
-
-
-
-
-Costello                    Standards Track                    [Page 16]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.2 Decoding traces
-
-   In the following traces, the evolving state of the decoder is shown
-   as a sequence of hexadecimal values, representing the code points in
-   the extended string.  An asterisk appears just after the most
-   recently inserted code point, indicating both n (the value preceeding
-   the asterisk) and i (the position of the value just after the
-   asterisk).  Other numerical values are decimal.
-
-   Decoding trace of example B from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "ihqwcrb4cv8a8dqg056pqjye"
-   there is no delimiter, so extended string starts empty
-   delta "ihq" decodes to 19853
-   bias becomes 21
-   4E0D *
-   delta "wc" decodes to 64
-   bias becomes 20
-   4E0D 4E2D *
-   delta "rb" decodes to 37
-   bias becomes 13
-   4E3A * 4E0D 4E2D
-   delta "4c" decodes to 56
-   bias becomes 17
-   4E3A 4E48 * 4E0D 4E2D
-   delta "v8a" decodes to 599
-   bias becomes 32
-   4E3A 4EC0 * 4E48 4E0D 4E2D
-   delta "8d" decodes to 130
-   bias becomes 23
-   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "qg" decodes to 154
-   bias becomes 25
-   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
-   delta "056p" decodes to 46301
-   bias becomes 84
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
-   delta "qjye" decodes to 88531
-   bias becomes 90
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 17]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Decoding trace of example L from section 7.1:
-
-   n is 128, i is 0, bias is 72
-   input is "3B-ww4c5e180e575a65lsy2b"
-   literal portion is "3B-", so extended string starts as:
-   0033 0042
-   delta "ww4c" decodes to 62042
-   bias becomes 27
-   0033 0042 5148 *
-   delta "5e" decodes to 139
-   bias becomes 24
-   0033 0042 516B * 5148
-   delta "180e" decodes to 16683
-   bias becomes 67
-   0033 5E74 * 0042 516B 5148
-   delta "575a" decodes to 34821
-   bias becomes 82
-   0033 5E74 0042 516B 5148 751F *
-   delta "65l" decodes to 14592
-   bias becomes 67
-   0033 5E74 0042 7D44 * 516B 5148 751F
-   delta "sy2b" decodes to 42088
-   bias becomes 84
-   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 18]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-7.3 Encoding traces
-
-   In the following traces, code point values are hexadecimal, while
-   other numerical values are decimal.
-
-   Encoding trace of example B from section 7.1:
-
-   bias is 72
-   input is:
-   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
-   there are no basic code points, so no literal portion
-   next code point to insert is 4E0D
-   needed delta is 19853, encodes as "ihq"
-   bias becomes 21
-   next code point to insert is 4E2D
-   needed delta is 64, encodes as "wc"
-   bias becomes 20
-   next code point to insert is 4E3A
-   needed delta is 37, encodes as "rb"
-   bias becomes 13
-   next code point to insert is 4E48
-   needed delta is 56, encodes as "4c"
-   bias becomes 17
-   next code point to insert is 4EC0
-   needed delta is 599, encodes as "v8a"
-   bias becomes 32
-   next code point to insert is 4ED6
-   needed delta is 130, encodes as "8d"
-   bias becomes 23
-   next code point to insert is 4EEC
-   needed delta is 154, encodes as "qg"
-   bias becomes 25
-   next code point to insert is 6587
-   needed delta is 46301, encodes as "056p"
-   bias becomes 84
-   next code point to insert is 8BF4
-   needed delta is 88531, encodes as "qjye"
-   bias becomes 90
-   output is "ihqwcrb4cv8a8dqg056pqjye"
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 19]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-   Encoding trace of example L from section 7.1:
-
-   bias is 72
-   input is:
-   0033 5E74 0042 7D44 91D1 516B 5148 751F
-   basic code points (0033, 0042) are copied to literal portion: "3B-"
-   next code point to insert is 5148
-   needed delta is 62042, encodes as "ww4c"
-   bias becomes 27
-   next code point to insert is 516B
-   needed delta is 139, encodes as "5e"
-   bias becomes 24
-   next code point to insert is 5E74
-   needed delta is 16683, encodes as "180e"
-   bias becomes 67
-   next code point to insert is 751F
-   needed delta is 34821, encodes as "575a"
-   bias becomes 82
-   next code point to insert is 7D44
-   needed delta is 14592, encodes as "65l"
-   bias becomes 67
-   next code point to insert is 91D1
-   needed delta is 42088, encodes as "sy2b"
-   bias becomes 84
-   output is "3B-ww4c5e180e575a65lsy2b"
-
-8. Security Considerations
-
-   Users expect each domain name in DNS to be controlled by a single
-   authority.  If a Unicode string intended for use as a domain label
-   could map to multiple ACE labels, then an internationalized domain
-   name could map to multiple ASCII domain names, each controlled by a
-   different authority, some of which could be spoofs that hijack
-   service requests intended for another.  Therefore Punycode is
-   designed so that each Unicode string has a unique encoding.
-
-   However, there can still be multiple Unicode representations of the
-   "same" text, for various definitions of "same".  This problem is
-   addressed to some extent by the Unicode standard under the topic of
-   canonicalization, and this work is leveraged for domain names by
-   Nameprep [NAMEPREP].
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 20]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-9. References
-
-9.1 Normative References
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-9.2 Informative References
-
-   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
-                Host Table Specification", RFC 952, October 1985.
-
-   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
-                Facilities", STD 13, RFC 1034, November 1987.
-
-   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
-                Profile for Internationalized Domain Names (IDN)", RFC
-                3491, March 2003.
-
-   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
-                20, October 1969.
-
-   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
-                http://www.trigeminal.com/samples/provincial.html.
-
-   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
-                http://www.unicode.org/unicode/standard/standard.html.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 21]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-A. Mixed-case annotation
-
-   In order to use Punycode to represent case-insensitive strings,
-   higher layers need to case-fold the strings prior to Punycode
-   encoding.  The encoded string can use mixed case as an annotation
-   telling how to convert the folded string into a mixed-case string for
-   display purposes.  Note, however, that mixed-case annotation is not
-   used by the ToASCII and ToUnicode operations specified in [IDNA], and
-   therefore implementors of IDNA can disregard this appendix.
-
-   Basic code points can use mixed case directly, because the decoder
-   copies them verbatim, leaving lowercase code points lowercase, and
-   leaving uppercase code points uppercase.  Each non-basic code point
-   is represented by a delta, which is represented by a sequence of
-   basic code points, the last of which provides the annotation.  If it
-   is uppercase, it is a suggestion to map the non-basic code point to
-   uppercase (if possible); if it is lowercase, it is a suggestion to
-   map the non-basic code point to lowercase (if possible).
-
-   These annotations do not alter the code points returned by decoders;
-   the annotations are returned separately, for the caller to use or
-   ignore.  Encoders can accept annotations in addition to code points,
-   but the annotations do not alter the output, except to influence the
-   uppercase/lowercase form of ASCII letters.
-
-   Punycode encoders and decoders need not support these annotations,
-   and higher layers need not use them.
-
-B. Disclaimer and license
-
-   Regarding this entire document or any portion of it (including the
-   pseudocode and C code), the author makes no guarantees and is not
-   responsible for any damage resulting from its use.  The author grants
-   irrevocable permission to anyone to use, modify, and distribute it in
-   any way that does not diminish the rights of anyone else to use,
-   modify, and distribute it, provided that redistributed derivative
-   works do not contain misleading author or version information.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 22]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-C. Punycode sample implementation
-
-/*
-punycode.c from RFC 3492
-http://www.nicemice.net/idn/
-Adam M. Costello
-http://www.nicemice.net/amc/
-
-This is ANSI C code (C89) implementing Punycode (RFC 3492).
-
-*/
-
-
-/************************************************************/
-/* Public interface (would normally go in its own .h file): */
-
-#include <limits.h>
-
-enum punycode_status {
-  punycode_success,
-  punycode_bad_input,   /* Input is invalid.                       */
-  punycode_big_output,  /* Output would exceed the space provided. */
-  punycode_overflow     /* Input needs wider integers to process.  */
-};
-
-#if UINT_MAX >= (1 << 26) - 1
-typedef unsigned int punycode_uint;
-#else
-typedef unsigned long punycode_uint;
-#endif
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] );
-
-    /* punycode_encode() converts Unicode to Punycode.  The input     */
-    /* is represented as an array of Unicode code points (not code    */
-    /* units; surrogate pairs are not allowed), and the output        */
-    /* will be represented as an array of ASCII code points.  The     */
-    /* output string is *not* null-terminated; it will contain        */
-    /* zeros if and only if the input contains zeros.  (Of course     */
-    /* the caller can leave room for a terminator and add one if      */
-    /* needed.)  The input_length is the number of code points in     */
-    /* the input.  The output_length is an in/out argument: the       */
-    /* caller passes in the maximum number of code points that it     */
-
-
-
-Costello                    Standards Track                    [Page 23]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    /* can receive, and on successful return it will contain the      */
-    /* number of code points actually output.  The case_flags array   */
-    /* holds input_length boolean values, where nonzero suggests that */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* after being decoded (if possible), and zero suggests that      */
-    /* it be forced to lowercase (if possible).  ASCII code points    */
-    /* are encoded literally, except that ASCII letters are forced    */
-    /* to uppercase or lowercase according to the corresponding       */
-    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
-    /* letters are left as they are, and other code points are        */
-    /* treated as if their uppercase flags were zero.  The return     */
-    /* value can be any of the punycode_status values defined above   */
-    /* except punycode_bad_input; if not punycode_success, then       */
-    /* output_size and output might contain garbage.                  */
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] );
-
-    /* punycode_decode() converts Punycode to Unicode.  The input is  */
-    /* represented as an array of ASCII code points, and the output   */
-    /* will be represented as an array of Unicode code points.  The   */
-    /* input_length is the number of code points in the input.  The   */
-    /* output_length is an in/out argument: the caller passes in      */
-    /* the maximum number of code points that it can receive, and     */
-    /* on successful return it will contain the actual number of      */
-    /* code points output.  The case_flags array needs room for at    */
-    /* least output_length values, or it can be a null pointer if the */
-    /* case information is not needed.  A nonzero flag suggests that  */
-    /* the corresponding Unicode character be forced to uppercase     */
-    /* by the caller (if possible), while zero suggests that it be    */
-    /* forced to lowercase (if possible).  ASCII code points are      */
-    /* output already in the proper case, but their flags will be set */
-    /* appropriately so that applying the flags would be harmless.    */
-    /* The return value can be any of the punycode_status values      */
-    /* defined above; if not punycode_success, then output_length,    */
-    /* output, and case_flags might contain garbage.  On success, the */
-    /* decoder will never need to write an output_length greater than */
-    /* input_length, because of how the encoding is defined.          */
-
-/**********************************************************/
-/* Implementation (would normally go in its own .c file): */
-
-#include <string.h>
-
-
-
-
-Costello                    Standards Track                    [Page 24]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-/*** Bootstring parameters for Punycode ***/
-
-enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
-       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
-
-/* basic(cp) tests whether cp is a basic code point: */
-#define basic(cp) ((punycode_uint)(cp) < 0x80)
-
-/* delim(cp) tests whether cp is a delimiter: */
-#define delim(cp) ((cp) == delimiter)
-
-/* decode_digit(cp) returns the numeric value of a basic code */
-/* point (for use in representing integers) in the range 0 to */
-/* base-1, or base if cp is does not represent a value.       */
-
-static punycode_uint decode_digit(punycode_uint cp)
-{
-  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
-          cp - 97 < 26 ? cp - 97 :  base;
-}
-
-/* encode_digit(d,flag) returns the basic code point whose value      */
-/* (when used for representing integers) is d, which needs to be in   */
-/* the range 0 to base-1.  The lowercase form is used unless flag is  */
-/* nonzero, in which case the uppercase form is used.  The behavior   */
-/* is undefined if flag is nonzero and digit d has no uppercase form. */
-
-static char encode_digit(punycode_uint d, int flag)
-{
-  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
-  /*  0..25 map to ASCII a..z or A..Z */
-  /* 26..35 map to ASCII 0..9         */
-}
-
-/* flagged(bcp) tests whether a basic code point is flagged */
-/* (uppercase).  The behavior is undefined if bcp is not a  */
-/* basic code point.                                        */
-
-#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
-
-/* encode_basic(bcp,flag) forces a basic code point to lowercase */
-/* if flag is zero, uppercase if flag is nonzero, and returns    */
-/* the resulting code point.  The code point is unchanged if it  */
-/* is caseless.  The behavior is undefined if bcp is not a basic */
-/* code point.                                                   */
-
-static char encode_basic(punycode_uint bcp, int flag)
-{
-
-
-
-Costello                    Standards Track                    [Page 25]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  bcp -= (bcp - 97 < 26) << 5;
-  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
-}
-
-/*** Platform-specific constants ***/
-
-/* maxint is the maximum value of a punycode_uint variable: */
-static const punycode_uint maxint = -1;
-/* Because maxint is unsigned, -1 becomes the maximum value. */
-
-/*** Bias adaptation function ***/
-
-static punycode_uint adapt(
-  punycode_uint delta, punycode_uint numpoints, int firsttime )
-{
-  punycode_uint k;
-
-  delta = firsttime ? delta / damp : delta >> 1;
-  /* delta >> 1 is a faster way of doing delta / 2 */
-  delta += delta / numpoints;
-
-  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
-    delta /= base - tmin;
-  }
-
-  return k + (base - tmin + 1) * delta / (delta + skew);
-}
-
-/*** Main encode function ***/
-
-enum punycode_status punycode_encode(
-  punycode_uint input_length,
-  const punycode_uint input[],
-  const unsigned char case_flags[],
-  punycode_uint *output_length,
-  char output[] )
-{
-  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  delta = out = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points: */
-
-
-
-
-Costello                    Standards Track                    [Page 26]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-  for (j = 0;  j < input_length;  ++j) {
-    if (basic(input[j])) {
-      if (max_out - out < 2) return punycode_big_output;
-      output[out++] =
-        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
-    }
-    /* else if (input[j] < n) return punycode_bad_input; */
-    /* (not needed for Punycode with unsigned code points) */
-  }
-
-  h = b = out;
-
-  /* h is the number of code points that have been handled, b is the  */
-  /* number of basic code points, and out is the number of characters */
-  /* that have been output.                                           */
-
-  if (b > 0) output[out++] = delimiter;
-
-  /* Main encoding loop: */
-
-  while (h < input_length) {
-    /* All non-basic code points < n have been     */
-    /* handled already.  Find the next larger one: */
-
-    for (m = maxint, j = 0;  j < input_length;  ++j) {
-      /* if (basic(input[j])) continue; */
-      /* (not needed for Punycode) */
-      if (input[j] >= n && input[j] < m) m = input[j];
-    }
-
-    /* Increase delta enough to advance the decoder's    */
-    /* <n,i> state to <m,0>, but guard against overflow: */
-
-    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
-    delta += (m - n) * (h + 1);
-    n = m;
-
-    for (j = 0;  j < input_length;  ++j) {
-      /* Punycode does not need to check whether input[j] is basic: */
-      if (input[j] < n /* || basic(input[j]) */ ) {
-        if (++delta == 0) return punycode_overflow;
-      }
-
-      if (input[j] == n) {
-        /* Represent delta as a generalized variable-length integer: */
-
-        for (q = delta, k = base;  ;  k += base) {
-          if (out >= max_out) return punycode_big_output;
-
-
-
-Costello                    Standards Track                    [Page 27]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-              k >= bias + tmax ? tmax : k - bias;
-          if (q < t) break;
-          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
-          q = (q - t) / (base - t);
-        }
-
-        output[out++] = encode_digit(q, case_flags && case_flags[j]);
-        bias = adapt(delta, h + 1, h == b);
-        delta = 0;
-        ++h;
-      }
-    }
-
-    ++delta, ++n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/*** Main decode function ***/
-
-enum punycode_status punycode_decode(
-  punycode_uint input_length,
-  const char input[],
-  punycode_uint *output_length,
-  punycode_uint output[],
-  unsigned char case_flags[] )
-{
-  punycode_uint n, out, i, max_out, bias,
-                 b, j, in, oldi, w, k, digit, t;
-
-  /* Initialize the state: */
-
-  n = initial_n;
-  out = i = 0;
-  max_out = *output_length;
-  bias = initial_bias;
-
-  /* Handle the basic code points:  Let b be the number of input code */
-  /* points before the last delimiter, or 0 if there is none, then    */
-  /* copy the first b code points to the output.                      */
-
-  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
-  if (b > max_out) return punycode_big_output;
-
-  for (j = 0;  j < b;  ++j) {
-
-
-
-Costello                    Standards Track                    [Page 28]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (case_flags) case_flags[out] = flagged(input[j]);
-    if (!basic(input[j])) return punycode_bad_input;
-    output[out++] = input[j];
-  }
-
-  /* Main decoding loop:  Start just after the last delimiter if any  */
-  /* basic code points were copied; start at the beginning otherwise. */
-
-  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
-
-    /* in is the index of the next character to be consumed, and */
-    /* out is the number of code points in the output array.     */
-
-    /* Decode a generalized variable-length integer into delta,  */
-    /* which gets added to i.  The overflow checking is easier   */
-    /* if we increase i as we go, then subtract off its starting */
-    /* value at the end to obtain delta.                         */
-
-    for (oldi = i, w = 1, k = base;  ;  k += base) {
-      if (in >= input_length) return punycode_bad_input;
-      digit = decode_digit(input[in++]);
-      if (digit >= base) return punycode_bad_input;
-      if (digit > (maxint - i) / w) return punycode_overflow;
-      i += digit * w;
-      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
-          k >= bias + tmax ? tmax : k - bias;
-      if (digit < t) break;
-      if (w > maxint / (base - t)) return punycode_overflow;
-      w *= (base - t);
-    }
-
-    bias = adapt(i - oldi, out + 1, oldi == 0);
-
-    /* i was supposed to wrap around from out+1 to 0,   */
-    /* incrementing n each time, so we'll fix that now: */
-
-    if (i / (out + 1) > maxint - n) return punycode_overflow;
-    n += i / (out + 1);
-    i %= (out + 1);
-
-    /* Insert n at position i of the output: */
-
-    /* not needed for Punycode: */
-    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
-    if (out >= max_out) return punycode_big_output;
-
-    if (case_flags) {
-      memmove(case_flags + i + 1, case_flags + i, out - i);
-
-
-
-Costello                    Standards Track                    [Page 29]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      /* Case of last character determines uppercase flag: */
-      case_flags[i] = flagged(input[in - 1]);
-    }
-
-    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
-    output[i++] = n;
-  }
-
-  *output_length = out;
-  return punycode_success;
-}
-
-/******************************************************************/
-/* Wrapper for testing (would normally go in a separate .c file): */
-
-#include <assert.h>
-#include <stdio.h>
-#include <stdlib.h>
-#include <string.h>
-
-/* For testing, we'll just set some compile-time limits rather than */
-/* use malloc(), and set a compile-time option rather than using a  */
-/* command-line option.                                             */
-
-enum {
-  unicode_max_length = 256,
-  ace_max_length = 256
-};
-
-static void usage(char **argv)
-{
-  fprintf(stderr,
-    "\n"
-    "%s -e reads code points and writes a Punycode string.\n"
-    "%s -d reads a Punycode string and writes code points.\n"
-    "\n"
-    "Input and output are plain text in the native character set.\n"
-    "Code points are in the form u+hex separated by whitespace.\n"
-    "Although the specification allows Punycode strings to contain\n"
-    "any characters from the ASCII repertoire, this test code\n"
-    "supports only the printable characters, and needs the Punycode\n"
-    "string to be followed by a newline.\n"
-    "The case of the u in u+hex is the force-to-uppercase flag.\n"
-    , argv[0], argv[0]);
-  exit(EXIT_FAILURE);
-}
-
-static void fail(const char *msg)
-
-
-
-Costello                    Standards Track                    [Page 30]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-{
-  fputs(msg,stderr);
-  exit(EXIT_FAILURE);
-}
-
-static const char too_big[] =
-  "input or output is too large, recompile with larger limits\n";
-static const char invalid_input[] = "invalid input\n";
-static const char overflow[] = "arithmetic overflow\n";
-static const char io_error[] = "I/O error\n";
-
-/* The following string is used to convert printable */
-/* characters between ASCII and the native charset:  */
-
-static const char print_ascii[] =
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
-  " !\"#$%&'()*+,-./"
-  "0123456789:;<=>?"
-  "@ABCDEFGHIJKLMNO"
-  "PQRSTUVWXYZ[\\]^_"
-  "`abcdefghijklmno"
-  "pqrstuvwxyz{|}~\n";
-
-int main(int argc, char **argv)
-{
-  enum punycode_status status;
-  int r;
-  unsigned int input_length, output_length, j;
-  unsigned char case_flags[unicode_max_length];
-
-  if (argc != 2) usage(argv);
-  if (argv[1][0] != '-') usage(argv);
-  if (argv[1][2] != 0) usage(argv);
-
-  if (argv[1][1] == 'e') {
-    punycode_uint input[unicode_max_length];
-    unsigned long codept;
-    char output[ace_max_length+1], uplus[3];
-    int c;
-
-    /* Read the input code points: */
-
-    input_length = 0;
-
-    for (;;) {
-      r = scanf("%2s%lx", uplus, &codept);
-      if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 31]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-      if (r == EOF || r == 0) break;
-
-      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
-        fail(invalid_input);
-      }
-
-      if (input_length == unicode_max_length) fail(too_big);
-
-      if (uplus[0] == 'u') case_flags[input_length] = 0;
-      else if (uplus[0] == 'U') case_flags[input_length] = 1;
-      else fail(invalid_input);
-
-      input[input_length++] = codept;
-    }
-
-    /* Encode: */
-
-    output_length = ace_max_length;
-    status = punycode_encode(input_length, input, case_flags,
-                             &output_length, output);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Convert to native charset and output: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      c = output[j];
-      assert(c >= 0 && c <= 127);
-      if (print_ascii[c] == 0) fail(invalid_input);
-      output[j] = print_ascii[c];
-    }
-
-    output[j] = 0;
-    r = puts(output);
-    if (r == EOF) fail(io_error);
-    return EXIT_SUCCESS;
-  }
-
-  if (argv[1][1] == 'd') {
-    char input[ace_max_length+2], *p, *pp;
-    punycode_uint output[unicode_max_length];
-
-    /* Read the Punycode input string and convert to ASCII: */
-
-    fgets(input, ace_max_length+2, stdin);
-    if (ferror(stdin)) fail(io_error);
-
-
-
-Costello                    Standards Track                    [Page 32]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-    if (feof(stdin)) fail(invalid_input);
-    input_length = strlen(input) - 1;
-    if (input[input_length] != '\n') fail(too_big);
-    input[input_length] = 0;
-
-    for (p = input;  *p != 0;  ++p) {
-      pp = strchr(print_ascii, *p);
-      if (pp == 0) fail(invalid_input);
-      *p = pp - print_ascii;
-    }
-
-    /* Decode: */
-
-    output_length = unicode_max_length;
-    status = punycode_decode(input_length, input, &output_length,
-                             output, case_flags);
-    if (status == punycode_bad_input) fail(invalid_input);
-    if (status == punycode_big_output) fail(too_big);
-    if (status == punycode_overflow) fail(overflow);
-    assert(status == punycode_success);
-
-    /* Output the result: */
-
-    for (j = 0;  j < output_length;  ++j) {
-      r = printf("%s+%04lX\n",
-                 case_flags[j] ? "U" : "u",
-                 (unsigned long) output[j] );
-      if (r < 0) fail(io_error);
-    }
-
-    return EXIT_SUCCESS;
-  }
-
-  usage(argv);
-  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
-}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 33]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Author's Address
-
-   Adam M. Costello
-   University of California, Berkeley
-   http://www.nicemice.net/amc/
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 34]
-
-RFC 3492                     IDNA Punycode                    March 2003
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2003).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Costello                    Standards Track                    [Page 35]
-

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4013.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4013.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4013.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        K. Zeilenga
-Request for Comments: 4013                           OpenLDAP Foundation
-Category: Standards Track                                  February 2005
-
-
-       SASLprep: Stringprep Profile for User Names and Passwords
-
-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 (2005).
-
-Abstract
-
-   This document describes how to prepare Unicode strings representing
-   user names and passwords for comparison.  The document defines the
-   "SASLprep" profile of the "stringprep" algorithm to be used for both
-   user names and passwords.  This profile is intended to be used by
-   Simple Authentication and Security Layer (SASL) mechanisms (such as
-   PLAIN, CRAM-MD5, and DIGEST-MD5), as well as other protocols
-   exchanging simple user names and/or passwords.
-
-1.  Introduction
-
-   The use of simple user names and passwords in authentication and
-   authorization is pervasive on the Internet.  To increase the
-   likelihood that user name and password input and comparison work in
-   ways that make sense for typical users throughout the world, this
-   document defines rules for preparing internationalized user names and
-   passwords for comparison.  For simplicity and implementation ease, a
-   single algorithm is defined for both user names and passwords.
-
-   The algorithm assumes all strings are comprised of characters from
-   the Unicode [Unicode] character set.
-
-   This document defines the "SASLprep" profile of the "stringprep"
-   algorithm [StringPrep].
-
-   The profile is designed for use in Simple Authentication and Security
-   Layer ([SASL]) mechanisms, such as [PLAIN], [CRAM-MD5], and
-   [DIGEST-MD5].  It may be applicable where simple user names and
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-   passwords are used.  This profile is not intended for use in
-   preparing identity strings that are not simple user names (e.g.,
-   email addresses, domain names, distinguished names), or where
-   identity or password strings that are not character data, or require
-   different handling (e.g., case folding).
-
-   This document does not alter the technical specification of any
-   existing protocols.  Any specification that wishes to use the
-   algorithm described in this document needs to explicitly incorporate
-   this document and provide precise details as to where and how this
-   algorithm is used by implementations of that specification.
-
-2.  The SASLprep Profile
-
-   This section defines the "SASLprep" profile of the "stringprep"
-   algorithm [StringPrep].  This profile is intended for use in
-   preparing strings representing simple user names and passwords.
-
-   This profile uses Unicode 3.2 [Unicode].
-
-   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
-   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].
-
-2.1.  Mapping
-
-   This profile specifies:
-
-      -  non-ASCII space characters [StringPrep, C.1.2] that can be
-         mapped to SPACE (U+0020), and
-
-      -  the "commonly mapped to nothing" characters [StringPrep, B.1]
-         that can be mapped to nothing.
-
-2.2.  Normalization
-
-   This profile specifies using Unicode normalization form KC, as
-   described in Section 4 of [StringPrep].
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-2.3.  Prohibited Output
-
-   This profile specifies the following characters as prohibited input:
-
-      - Non-ASCII space characters [StringPrep, C.1.2]
-      - ASCII control characters [StringPrep, C.2.1]
-      - Non-ASCII control characters [StringPrep, C.2.2]
-      - Private Use characters [StringPrep, C.3]
-      - Non-character code points [StringPrep, C.4]
-      - Surrogate code points [StringPrep, C.5]
-      - Inappropriate for plain text characters [StringPrep, C.6]
-      - Inappropriate for canonical representation characters
-        [StringPrep, C.7]
-      - Change display properties or deprecated characters
-        [StringPrep, C.8]
-      - Tagging characters [StringPrep, C.9]
-
-2.4.  Bidirectional Characters
-
-   This profile specifies checking bidirectional strings as described in
-   [StringPrep, Section 6].
-
-2.5.  Unassigned Code Points
-
-   This profile specifies the [StringPrep, A.1] table as its list of
-   unassigned code points.
-
-3.  Examples
-
-   The following table provides examples of how various character data
-   is transformed by the SASLprep string preparation algorithm
-
-   #  Input            Output     Comments
-   -  -----            ------     --------
-   1  I<U+00AD>X       IX         SOFT HYPHEN mapped to nothing
-   2  user             user       no transformation
-   3  USER             USER       case preserved, will not match #2
-   4  <U+00AA>         a          output is NFKC, input in ISO 8859-1
-   5  <U+2168>         IX         output is NFKC, will match #1
-   6  <U+0007>                    Error - prohibited character
-   7  <U+0627><U+0031>            Error - bidirectional check
-
-4.  Security Considerations
-
-   This profile is intended to prepare simple user name and password
-   strings for comparison or use in cryptographic functions (e.g.,
-   message digests).  The preparation algorithm was specifically
-   designed such that its output is canonical, and it is well-formed.
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-   However, due to an anomaly [PR29] in the specification of Unicode
-   normalization, canonical equivalence is not guaranteed for a select
-   few character sequences.  These sequences, however, do not appear in
-   well-formed text.  This specification was published despite this
-   known technical problem.  It is expected that this specification will
-   be revised before further progression on the Standards Track (after
-   [Unicode] and/or [StringPrep] specifications have been updated to
-   address this problem).
-
-   It is not intended for preparing identity strings that are not simple
-   user names (e.g., distinguished names, domain names), nor is the
-   profile intended for use of simple user names that require different
-   handling (such as case folding).  Protocols (or applications of those
-   protocols) that have application-specific identity forms and/or
-   comparison algorithms should use mechanisms specifically designed for
-   these forms and algorithms.
-
-   Application of string preparation may have an impact upon the
-   feasibility of brute force and dictionary attacks.  While the number
-   of possible prepared strings is less than the number of possible
-   Unicode strings, the number of usable names and passwords is greater
-   than as if only ASCII was used.  Though SASLprep eliminates some
-   Unicode code point sequences as possible prepared strings, that
-   elimination generally makes the (canonical) output forms practicable
-   and prohibits nonsensical inputs.
-
-   User names and passwords should be protected from eavesdropping.
-
-   General "stringprep" and Unicode security considerations apply.  Both
-   are discussed in [StringPrep].
-
-5.  IANA Considerations
-
-   This document details the "SASLprep" profile of the [StringPrep]
-   protocol.  This profile has been registered in the stringprep profile
-   registry.
-
-      Name of this profile: SASLprep
-      RFC in which the profile is defined: RFC 4013
-      Indicator whether or not this is the newest version of the
-      profile: This is the first version of the SASPprep profile.
-
-6.  Acknowledgement
-
-   This document borrows text from "Preparation of Internationalized
-   Strings ('stringprep')" and "Nameprep: A Stringprep Profile for
-   Internationalized Domain Names", both by Paul Hoffman and Marc
-   Blanchet.  This document is a product of the IETF SASL WG.
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-7.  Normative References
-
-   [StringPrep]  Hoffman, P. and M. Blanchet, "Preparation of
-                 Internationalized Strings ("stringprep")", RFC 3454,
-                 December 2002.
-
-   [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/).
-
-8.  Informative References
-
-   [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.
-
-   [SASL]        Melnikov, A., Ed., "Simple Authentication and Security
-                 Layer (SASL)", Work in Progress.
-
-   [CRAM-MD5]    Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
-                 Progress.
-
-   [DIGEST-MD5]  Leach, P., Newman, C., and A. Melnikov, "Using Digest
-                 Authentication as a SASL Mechanism", Work in Progress.
-
-   [PLAIN]       Zeilenga, K., Ed., "The Plain SASL Mechanism", Work in
-                 Progress.
-
-   [PR29]        "Public Review Issue #29: Normalization Issue",
-                 <http://www.unicode.org/review/pr-29.html>, February
-                 2004.
-
-Author's Address
-
-   Kurt D. Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt at OpenLDAP.org
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4013                        SASLprep                   February 2005
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2005).
-
-   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 IETF's procedures with respect to rights in IETF 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 at ietf.org.
-
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-

Deleted: branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4518.txt
===================================================================
--- branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4518.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/heimdal/lib/wind/rfc4518.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-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 at 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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 14]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2307.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2307.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2307.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          L. Howard
-Request for Comments: 2307                        Independent Consultant
-Category: Experimental                                        March 1998
-
-
-      An Approach for Using LDAP as a Network Information Service
-
-Status of this Memo
-
-   This memo defines an Experimental Protocol for the Internet
-   community.  It does not specify an Internet standard of any kind.
-   Discussion and suggestions for improvement are requested.
-   Distribution of this memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-Abstract
-
-   This document describes an experimental mechanism for mapping
-   entities related to TCP/IP and the UNIX system into X.500 [X500]
-   entries so that they may be resolved with the Lightweight Directory
-   Access Protocol [RFC2251]. A set of attribute types and object
-   classes are proposed, along with specific guidelines for interpreting
-   them.
-
-   The intention is to assist the deployment of LDAP as an
-   organizational nameservice. No proposed solutions are intended as
-   standards for the Internet. Rather, it is hoped that a general
-   consensus will emerge as to the appropriate solution to such
-   problems, leading eventually to the adoption of standards. The
-   proposed mechanism has already been implemented with some success.
-
-1. Background and Motivation
-
-   The UNIX (R) operating system, and its derivatives (specifically,
-   those which support TCP/IP and conform to the X/Open Single UNIX
-   specification [XOPEN]) require a means of looking up entities, by
-   matching them against search criteria or by enumeration. (Other
-   operating systems that support TCP/IP may provide some means of
-   resolving some of these entities. This schema is applicable to those
-   environments also.)
-
-   These entities include users, groups, IP services (which map names to
-   IP ports and protocols, and vice versa), IP protocols (which map
-   names to IP protocol numbers and vice versa), RPCs (which map names
-   to ONC Remote Procedure Call [RFC1057] numbers and vice versa), NIS
-
-
-
-Howard                        Experimental                      [Page 1]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   netgroups, booting information (boot parameters and MAC address
-   mappings), filesystem mounts, IP hosts and networks, and RFC822 mail
-   aliases.
-
-   Resolution requests are made through a set of C functions, provided
-   in the UNIX system's C library. For example, the UNIX system utility
-   "ls", which enumerates the contents of a filesystem directory, uses
-   the C library function getpwuid() in order to map user IDs to login
-   names. Once the request is made, it is resolved using a "nameservice"
-   which is supported by the client library. The nameservice may be, at
-   its simplest, a collection of files in the local filesystem which are
-   opened and searched by the C library. Other common nameservices
-   include the Network Information Service (NIS) and the Domain Name
-   System (DNS). (The latter is typically used for resolving hosts,
-   services and networks.) Both these nameservices have the advantage of
-   being distributed and thus permitting a common set of entities to be
-   shared amongst many clients.
-
-   LDAP is a distributed, hierarchical directory service access protocol
-   which is used to access repositories of users and other network-
-   related entities. Because LDAP is often not tightly integrated with
-   the host operating system, information such as users may need to be
-   kept both in LDAP and in an operating system supported nameservice
-   such as NIS. By using LDAP as the the primary means of resolving
-   these entities, these redundancy issues are minimized and the
-   scalability of LDAP can be exploited. (By comparison, NIS services
-   based on flat files do not have the scalability or extensibility of
-   LDAP or X.500.)
-
-   The object classes and attributes defined below are suitable for
-   representing the aforementioned entities in a form compatible with
-   LDAP and X.500 directory services.
-
-2. General Issues
-
-2.1. Terminology
-
-   The key words "MUST", "SHOULD", and "MAY" used in this document are
-   to be interpreted as described in [RFC2119].
-
-   For the purposes of this document, the term "nameservice" refers to a
-   service, such as NIS or flat files, that is used by the operating
-   system to resolve entities within a single, local naming context.
-   Contrast this with a "directory service" such as LDAP, which supports
-   extensible schema and multiple naming contexts.
-
-
-
-
-
-
-Howard                        Experimental                      [Page 2]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   The term "NIS-related entities" broadly refers to entities which are
-   typically resolved using the Network Information Service. (NIS was
-   previously known as YP.) Deploying LDAP for resolving these entities
-   does not imply that NIS be used, as a gateway or otherwise. In
-   particular, the host and network classes are generically applicable,
-   and may be implemented on any system that wishes to use LDAP or X.500
-   for host and network resolution.
-
-   The "DUA" (directory user agent) refers to the LDAP client querying
-   these entities, such as an LDAP to NIS gateway or the C library.  The
-   "client" refers to the application which ultimately makes use of the
-   information returned by the resolution. It is irrelevant whether the
-   DUA and the client reside within the same address space. The act of
-   the DUA making this information to the client is termed
-   "republishing".
-
-   To avoid confusion, the term "login name" refers to the user's login
-   name (being the value of the uid attribute) and the term "user ID"
-   refers to he user's integer identification number (being the value of
-   the uidNumber attribute).
-
-   The phrases "resolving an entity" and "resolution of entities" refer
-   respectively to enumerating NIS-related entities of a given type, and
-   matching them against a given search criterion. One or more entities
-   are returned as a result of successful "resolutions" (a "match"
-   operation will only return one entity).
-
-   The use of the term UNIX does not confer upon this schema the
-   endorsement of owners of the UNIX trademark. Where necessary, the
-   term "TCP/IP entity" is used to refer to protocols, services, hosts,
-   and networks, and the term "UNIX entity" to its complement. (The
-   former category does not mandate the host operating system supporting
-   the interfaces required for resolving UNIX entities.)
-
-   The OIDs defined below are derived from iso(1) org(3) dod(6)
-   internet(1) directory(1) nisSchema(1).
-
-2.2. Attributes
-
-   The attributes and classes defined in this document are summarized
-   below.
-
-   The following attributes are defined in this document:
-
-           uidNumber
-           gidNumber
-           gecos
-           homeDirectory
-
-
-
-Howard                        Experimental                      [Page 3]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-           loginShell
-           shadowLastChange
-           shadowMin
-           shadowMax
-           shadowWarning
-           shadowInactive
-           shadowExpire
-           shadowFlag
-           memberUid
-           memberNisNetgroup
-           nisNetgroupTriple
-           ipServicePort
-           ipServiceProtocol
-           ipProtocolNumber
-           oncRpcNumber
-           ipHostNumber
-           ipNetworkNumber
-           ipNetmaskNumber
-           macAddress
-           bootParameter
-           bootFile
-           nisMapName
-           nisMapEntry
-
-   Additionally, some of the attributes defined in [RFC2256] are
-   required.
-
-2.3. Object classes
-
-   The following object classes are defined in this document:
-
-           posixAccount
-           shadowAccount
-           posixGroup
-           ipService
-           ipProtocol
-           oncRpc
-           ipHost
-           ipNetwork
-           nisNetgroup
-           nisMap
-           nisObject
-           ieee802Device
-           bootableDevice
-
-   Additionally, some of the classes defined in [RFC2256] are required.
-
-
-
-
-
-Howard                        Experimental                      [Page 4]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-2.4. Syntax definitions
-
-   The following syntax definitions [RFC2252] are used by this schema.
-   The nisNetgroupTripleSyntax represents NIS netgroup triples:
-
-           ( nisSchema.0.0 NAME 'nisNetgroupTripleSyntax'
-             DESC 'NIS netgroup triple' )
-
-   Values in this syntax are represented by the following:
-
-        nisnetgrouptriple = "(" hostname "," username "," domainname ")"
-        hostname          = "" / "-" / keystring
-        username          = "" / "-" / keystring
-        domainname        = "" / "-" / keystring
-
-   X.500 servers may use the following representation of the above
-   syntax:
-
-        nisNetgroupTripleSyntax ::= SEQUENCE {
-         hostname  [0] IA5String OPTIONAL,
-         username  [1] IA5String OPTIONAL,
-         domainname  [2] IA5String OPTIONAL
-        }
-
-   The bootParameterSyntax syntax represents boot parameters:
-
-           ( nisSchema.0.1 NAME 'bootParameterSyntax'
-             DESC 'Boot parameter' )
-
-   where:
-
-        bootparameter     = key "=" server ":" path
-        key               = keystring
-        server            = keystring
-        path              = keystring
-
-   X.500 servers may use the following representation of the above
-   syntax:
-
-        bootParameterSyntax ::= SEQUENCE {
-         key     IA5String,
-         server  IA5String,
-         path    IA5String
-        }
-
-   Values adhering to these syntaxes are encoded as strings by LDAP
-   servers.
-
-
-
-
-Howard                        Experimental                      [Page 5]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-3. Attribute definitions
-
-   This section contains attribute definitions to be implemented by DUAs
-   supporting this schema.
-
-        ( nisSchema.1.0 NAME 'uidNumber'
-          DESC 'An integer uniquely identifying a user in an
-                administrative domain'
-          EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.1 NAME 'gidNumber'
-          DESC 'An integer uniquely identifying a group in an
-                administrative domain'
-          EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.2 NAME 'gecos'
-          DESC 'The GECOS field; the common name'
-          EQUALITY caseIgnoreIA5Match
-          SUBSTRINGS caseIgnoreIA5SubstringsMatch
-          SYNTAX 'IA5String' SINGLE-VALUE )
-
-        ( nisSchema.1.3 NAME 'homeDirectory'
-          DESC 'The absolute path to the home directory'
-          EQUALITY caseExactIA5Match
-          SYNTAX 'IA5String' SINGLE-VALUE )
-
-        ( nisSchema.1.4 NAME 'loginShell'
-          DESC 'The path to the login shell'
-          EQUALITY caseExactIA5Match
-          SYNTAX 'IA5String' SINGLE-VALUE )
-
-        ( nisSchema.1.5 NAME 'shadowLastChange'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.6 NAME 'shadowMin'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.7 NAME 'shadowMax'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.8 NAME 'shadowWarning'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.9 NAME 'shadowInactive'
-
-
-
-Howard                        Experimental                      [Page 6]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.10 NAME 'shadowExpire'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.11 NAME 'shadowFlag'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.12 NAME 'memberUid'
-          EQUALITY caseExactIA5Match
-          SUBSTRINGS caseExactIA5SubstringsMatch
-          SYNTAX 'IA5String' )
-
-        ( nisSchema.1.13 NAME 'memberNisNetgroup'
-          EQUALITY caseExactIA5Match
-          SUBSTRINGS caseExactIA5SubstringsMatch
-          SYNTAX 'IA5String' )
-
-        ( nisSchema.1.14 NAME 'nisNetgroupTriple'
-          DESC 'Netgroup triple'
-          SYNTAX 'nisNetgroupTripleSyntax' )
-
-        ( nisSchema.1.15 NAME 'ipServicePort'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.16 NAME 'ipServiceProtocol'
-          SUP name )
-
-        ( nisSchema.1.17 NAME 'ipProtocolNumber'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.18 NAME 'oncRpcNumber'
-          EQUALITY integerMatch
-          SYNTAX 'INTEGER' SINGLE-VALUE )
-
-        ( nisSchema.1.19 NAME 'ipHostNumber'
-          DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
-                omitting leading zeros'
-          EQUALITY caseIgnoreIA5Match
-          SYNTAX 'IA5String{128}' )
-
-        ( nisSchema.1.20 NAME 'ipNetworkNumber'
-          DESC 'IP network as a dotted decimal, eg. 192.168,
-
-
-
-Howard                        Experimental                      [Page 7]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-                omitting leading zeros'
-          EQUALITY caseIgnoreIA5Match
-          SYNTAX 'IA5String{128}' SINGLE-VALUE )
-
-        ( nisSchema.1.21 NAME 'ipNetmaskNumber'
-          DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
-                omitting leading zeros'
-          EQUALITY caseIgnoreIA5Match
-          SYNTAX 'IA5String{128}' SINGLE-VALUE )
-
-        ( nisSchema.1.22 NAME 'macAddress'
-          DESC 'MAC address in maximal, colon separated hex
-                notation, eg. 00:00:92:90:ee:e2'
-          EQUALITY caseIgnoreIA5Match
-          SYNTAX 'IA5String{128}' )
-
-        ( nisSchema.1.23 NAME 'bootParameter'
-          DESC 'rpc.bootparamd parameter'
-          SYNTAX 'bootParameterSyntax' )
-
-        ( nisSchema.1.24 NAME 'bootFile'
-          DESC 'Boot image name'
-          EQUALITY caseExactIA5Match
-          SYNTAX 'IA5String' )
-
-        ( nisSchema.1.26 NAME 'nisMapName'
-          SUP name )
-
-        ( nisSchema.1.27 NAME 'nisMapEntry'
-          EQUALITY caseExactIA5Match
-          SUBSTRINGS caseExactIA5SubstringsMatch
-          SYNTAX 'IA5String{1024}' SINGLE-VALUE )
-
-4. Class definitions
-
-   This section contains class definitions to be implemented by DUAs
-   supporting the schema.
-
-   The rfc822MailGroup object class MAY be used to represent a mail
-   group for the purpose of alias expansion. Several alternative schemes
-   for mail routing and delivery using LDAP directories, which are
-   outside the scope of this document.
-
-        ( nisSchema.2.0 NAME 'posixAccount' SUP top AUXILIARY
-          DESC 'Abstraction of an account with POSIX attributes'
-          MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
-          MAY ( userPassword $ loginShell $ gecos $ description ) )
-
-
-
-
-Howard                        Experimental                      [Page 8]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-        ( nisSchema.2.1 NAME 'shadowAccount' SUP top AUXILIARY
-          DESC 'Additional attributes for shadow passwords'
-          MUST uid
-          MAY ( userPassword $ shadowLastChange $ shadowMin
-                shadowMax $ shadowWarning $ shadowInactive $
-                shadowExpire $ shadowFlag $ description ) )
-
-        ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
-          DESC 'Abstraction of a group of accounts'
-          MUST ( cn $ gidNumber )
-          MAY ( userPassword $ memberUid $ description ) )
-
-        ( nisSchema.2.3 NAME 'ipService' SUP top STRUCTURAL
-          DESC 'Abstraction an Internet Protocol service.
-                Maps an IP port and protocol (such as tcp or udp)
-                to one or more names; the distinguished value of
-                the cn attribute denotes the service's canonical
-                name'
-          MUST ( cn $ ipServicePort $ ipServiceProtocol )
-          MAY ( description ) )
-
-        ( nisSchema.2.4 NAME 'ipProtocol' SUP top STRUCTURAL
-          DESC 'Abstraction of an IP protocol. Maps a protocol number
-                to one or more names. The distinguished value of the cn
-                attribute denotes the protocol's canonical name'
-          MUST ( cn $ ipProtocolNumber $ description )
-          MAY description )
-
-        ( nisSchema.2.5 NAME 'oncRpc' SUP top STRUCTURAL
-          DESC 'Abstraction of an Open Network Computing (ONC)
-               [RFC1057] Remote Procedure Call (RPC) binding.
-               This class maps an ONC RPC number to a name.
-               The distinguished value of the cn attribute denotes
-               the RPC service's canonical name'
-          MUST ( cn $ oncRpcNumber $ description )
-          MAY description )
-
-        ( nisSchema.2.6 NAME 'ipHost' SUP top AUXILIARY
-
-          DESC 'Abstraction of a host, an IP device. The distinguished
-                value of the cn attribute denotes the host's canonical
-                name. Device SHOULD be used as a structural class'
-          MUST ( cn $ ipHostNumber )
-          MAY ( l $ description $ manager ) )
-
-        ( nisSchema.2.7 NAME 'ipNetwork' SUP top STRUCTURAL
-          DESC 'Abstraction of a network. The distinguished value of
-                the cn attribute denotes the network's canonical name'
-
-
-
-Howard                        Experimental                      [Page 9]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-          MUST ( cn $ ipNetworkNumber )
-          MAY ( ipNetmaskNumber $ l $ description $ manager ) )
-
-        ( nisSchema.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
-          DESC 'Abstraction of a netgroup. May refer to other netgroups'
-          MUST cn
-          MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
-
-        ( nisSchema.2.09 NAME 'nisMap' SUP top STRUCTURAL
-          DESC 'A generic abstraction of a NIS map'
-          MUST nisMapName
-          MAY description )
-
-        ( nisSchema.2.10 NAME 'nisObject' SUP top STRUCTURAL
-          DESC 'An entry in a NIS map'
-          MUST ( cn $ nisMapEntry $ nisMapName )
-          MAY description )
-
-        ( nisSchema.2.11 NAME 'ieee802Device' SUP top AUXILIARY
-          DESC 'A device with a MAC address; device SHOULD be
-                used as a structural class'
-          MAY macAddress )
-
-        ( nisSchema.2.12 NAME 'bootableDevice' SUP top AUXILIARY
-          DESC 'A device with boot parameters; device SHOULD be
-                used as a structural class'
-          MAY ( bootFile $ bootParameter ) )
-
-5. Implementation details
-
-5.1. Suggested resolution methods
-
-   The preferred means of directing a client application (one using the
-   shared services of the C library) to use LDAP as its information
-   source for the functions listed in 5.2 is to modify the source code
-   to directly query LDAP. As the source to commercial C libraries and
-   applications is rarely available to the end-user, one could emulate a
-   supported nameservice (such as NIS). (This is also an appropriate
-   opportunity to perform caching of entries across process address
-   spaces.) In the case of NIS, reference implementations are widely
-   available and the RPC interface is well known.
-
-   The means by which the operating system is directed to use LDAP is
-   implementation dependent. For example, some operating systems and C
-   libraries support end-user extensible resolvers using dynamically
-   loadable libraries and a nameservice "switch". The means in which the
-   DUA locates LDAP servers is also implementation dependent.
-
-
-
-
-Howard                        Experimental                     [Page 10]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-5.2. Affected library functions
-
-   The following functions are typically found in the C libraries of
-   most UNIX and POSIX compliant systems. An LDAP search filter
-   [RFC2254] which may be used to satisfy the function call is included
-   alongside each function name. Parameters are denoted by %s and %d for
-   string and integer arguments, respectively. Long lines are broken.
-
-        getpwnam()              (&(objectClass=posixAccount)(uid=%s))
-        getpwuid()              (&(objectClass=posixAccount)
-                                (uidNumber=%d))
-        getpwent()              (objectClass=posixAccount)
-
-        getspnam()              (&(objectClass=shadowAccount)(uid=%s))
-        getspent()              (objectClass=shadowAccount)
-
-        getgrnam()              (&(objectClass=posixGroup)(cn=%s))
-        getgrgid()              (&(objectClass=posixGroup)
-                                (gidNumber=%d))
-        getgrent()              (objectClass=posixGroup)
-
-        getservbyname()         (&(objectClass=ipService)
-                                (cn=%s)(ipServiceProtocol=%s))
-        getservbyport()         (&(objectClass=ipService)
-                                (ipServicePort=%d)
-                                (ipServiceProtocol=%s))
-        getservent()            (objectClass=ipService)
-
-        getrpcbyname()          (&(objectClass=oncRpc)(cn=%s))
-        getrpcbynumber()        (&(objectClass=oncRpc)(oncRpcNumber=%d))
-        getrpcent()             (objectClass=oncRpc)
-
-        getprotobyname()        (&(objectClass=ipProtocol)(cn=%s))
-        getprotobynumber()      (&(objectClass=ipProtocol)
-                                (ipProtocolNumber=%d))
-        getprotoent()           (objectClass=ipProtocol)
-
-        gethostbyname()         (&(objectClass=ipHost)(cn=%s))
-        gethostbyaddr()         (&(objectClass=ipHost)(ipHostNumber=%s))
-        gethostent()            (objectClass=ipHost)
-
-        getnetbyname()          (&(objectClass=ipNetwork)(cn=%s))
-        getnetbyaddr()          (&(objectClass=ipNetwork)
-                                (ipNetworkNumber=%s))
-        getnetent()             (objectClass=ipNetwork)
-
-        setnetgrent()           (&(objectClass=nisNetgroup)(cn=%s))
-
-
-
-
-Howard                        Experimental                     [Page 11]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-5.3. Interpreting user and group entries
-
-   User and group resolution is initiated by the functions prefixed by
-   getpw and getgr respectively. The uid attribute contains the user's
-   login name. The cn attribute, in posixGroup entries, contains the
-   group's name.
-
-   The account object class provides a convenient structural class for
-   posixAccount, and SHOULD be used where additional attributes are not
-   required.
-
-   It is suggested that uid and cn are used as the RDN attribute type
-   for posixAccount and posixGroup entries, respectively.
-
-   An account's GECOS field is preferably determined by a value of the
-   gecos attribute. If no gecos attribute exists, the value of the cn
-   attribute MUST be used. (The existence of the gecos attribute allows
-   information embedded in the GECOS field, such as a user's telephone
-   number, to be returned to the client without overloading the cn
-   attribute. It also accommodates directories where the common name
-   does not contain the user's full name.)
-
-   An entry of class posixAccount, posixGroup, or shadowAccount without
-   a userPassword attribute MUST NOT be used for authentication. The
-   client should be returned a non-matchable password such as "x".
-
-   userPassword values MUST be represented by following syntax:
-
-        passwordvalue          = schemeprefix encryptedpassword
-        schemeprefix           = "{" scheme "}"
-        scheme                 = "crypt" / "md5" / "sha" / altscheme
-        altscheme              = "x-" keystring
-        encryptedpassword      = encrypted password
-
-   The encrypted password contains of a plaintext key hashed using the
-   algorithm scheme.
-
-   userPassword values which do not adhere to this syntax MUST NOT be
-   used for authentication. The DUA MUST iterate through the values of
-   the attribute until a value matching the above syntax is found. Only
-   if encryptedpassword is an empty string does the user have no
-   password. DUAs are not required to consider encryption schemes which
-   the client will not recognize; in most cases, it may be sufficient to
-   consider only "crypt".
-
-   Below is an example of a userPassword attribute:
-
-                    userPassword: {crypt}X5/DBrWPOQQaI
-
-
-
-Howard                        Experimental                     [Page 12]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   A future standard may specify LDAP v3 attribute descriptions to
-   represent hashed userPasswords, as noted below. This schema MUST NOT
-   be used with LDAP v2 DUAs and DSAs.
-
-        attributetype           = attributename sep attributeoption
-        attributename           = "userPassword"
-        sep                     = ";"
-        attributeoption         = schemeclass "-" scheme
-        schemeclass             = "hash" / altschemeclass
-        scheme                  = "crypt" / "md5" / "sha" / altscheme
-        altschemeclass          = "x-" keystring
-        altscheme               = keystring
-
-
-   Below is an example of a userPassword attribute, represented with an
-   LDAP v3 attribute description:
-
-           userPassword;hash-crypt: X5/DBrWPOQQaI
-
-
-   A DUA MAY utilise the attributes in the shadowAccount class to
-   provide shadow password service (getspnam() and getspent()). In such
-   cases, the DUA MUST NOT make use of the userPassword attribute for
-   getpwnam() et al, and MUST return a non-matchable password (such as
-   "x") to the client instead.
-
-5.4. Interpreting hosts and networks
-
-   The ipHostNumber and ipNetworkNumber attributes are defined in
-   preference to dNSRecord (defined in [RFC1279]), in order to simplify
-   the DUA's role in interpreting entries in the directory. A dNSRecord
-   expresses a complete resource record, including time to live and
-   class data, which is extraneous to this schema.
-
-   Additionally, the ipHost and ipNetwork classes permit a host or
-   network (respectively) and all its aliases to be represented by a
-   single entry in the directory. This is not necessarily possible if a
-   DNS resource record is mapped directly to an LDAP entry.
-   Implementations that wish to use LDAP to master DNS zone information
-   are not precluded from doing so, and may simply avoid the ipHost and
-   ipNetwork classes.
-
-   This document redefines, although not exclusively, the ipNetwork
-   class defined in [RFC1279], in order to achieve consistent naming
-   with ipHost. The ipNetworkNumber attribute is also used in the
-   siteContact object class [ROSE].
-
-
-
-
-
-Howard                        Experimental                     [Page 13]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   The trailing zeros in a network address MUST be omitted. CIDR-style
-   network addresses (eg. 192.168.1/24) MAY be used.
-
-   Hosts with IPv6 addresses MUST be written in their "preferred" form
-   as defined in section 2.2.1 of [RFC1884], such that all components of
-   the address are indicated and leading zeros are omitted. This
-   provides a consistent means of resolving ipHosts by address.
-
-5.5. Interpreting other entities
-
-   In general, a one-to-one mapping between entities and LDAP entries is
-   proposed, in that each entity has exactly one representation in the
-   DIT. In some cases this is not feasible; for example, a service which
-   is represented in more than one protocol domain. Consider the
-   following entry:
-
-           dn: cn=domain, dc=aja, dc=com
-           cn: domain
-           cn: nameserver
-           objectClass: top
-           objectClass: ipService
-           ipServicePort: 53
-           ipServiceProtocol: tcp
-           ipServiceProtocol: udp
-
-   This entry MUST map to the following two (2) services entities:
-
-           domain  53/tcp  nameserver
-           domain  53/udp  nameserver
-
-   While the above two entities may be represented as separate LDAP
-   entities, with different distinguished names (such as
-   cn=domain+ipServiceProtocol=tcp, ... and
-   cn=domain+ipServiceProtocol=udp, ...) it is convenient to represent
-   them as a single entry. (If a service is represented in multiple
-   protocol domains with different ports, then multiple entries are
-   required; multivalued RDNs may be used to distinguish them.)
-
-   With the exception of userPassword values, which are parsed according
-   to the syntax considered in section 5.2, any empty values (consisting
-   of a zero length string) are returned by the DUA to the client. The
-   DUA MUST reject any entries which do not conform to the schema
-   (missing mandatory attributes). Non-conforming entries SHOULD be
-   ignored while enumerating entries.
-
-   The nisObject object class MAY be used as a generic means of
-   representing NIS entities. Its use is not encouraged; where support
-   for entities not described in this schema is desired, an appropriate
-
-
-
-Howard                        Experimental                     [Page 14]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   schema should be devised. Implementors are strongly advised to
-   support end-user extensible mappings between NIS entities and object
-   classes. (Where the nisObject class is used, the nisMapName attribute
-   may be used as a RDN.)
-
-5.6. Canonicalizing entries with multi-valued naming attributes
-
-   For entities such as hosts, services, networks, protocols, and RPCs,
-   where there may be one or more aliases, the respective entry's
-   relative distinguished name SHOULD be used to determine the canonical
-   name.  Any other values for the same attribute are used as aliases.
-   For example, the service described in section 5.5 has the canonical
-   name "domain" and exactly one alias, "nameserver".
-
-   The schema in this document generally only defines one attribute per
-   class which is suitable for distinguishing an entity (excluding any
-   attributes with integer syntax; it is assumed that entries will be
-   distinguished on name). Usually, this is the common name (cn)
-   attribute.  This aids the DUA in determining the canonical name of an
-   entity, as it can examine the value of the relative distinguished
-   name. Aliases are thus any values of the distinguishing attribute
-   (such as cn) which do not match the canonical name of the entity.
-
-   In the event that a different attribute is used to distinguish the
-   entry, as may be the case where these object classes are used as
-   auxiliary classes, the entry's canonical name may not be present in
-   the RDN. In this case, the DUA MUST choose one of the non-
-   distinguished values to represent the entity's canonical name. As the
-   directory server guarantees no ordering of attribute values, it may
-   not be possible to distinguish an entry deterministically. This
-   ambiguity SHOULD NOT be resolved by mapping one directory entry into
-   multiple entities.
-
-6. Implementation focus
-
-   A NIS server which uses LDAP instead of local files has been
-   developed which supports the schema defined in this document.
-
-   A reference implementation of the C library resolution code has been
-   written for the Free Software Foundation. It may support other C
-   libraries which support the Name Service Switch (NSS) or the
-   Information Retrieval Service (IRS).
-
-   The author has made available a freely distributable set of scripts
-   which parses local databases such as /etc/passwd and /etc/hosts into
-   a form suitable for loading into an LDAP server.
-
-
-
-
-
-Howard                        Experimental                     [Page 15]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-7. Security Considerations
-
-   The entirety of related security considerations are outside the scope
-   of this document. It is noted that making passwords encrypted with a
-   widely understood hash function (such as crypt()) available to non-
-   privileged users is dangerous because it exposes them to dictionary
-   and brute-force attacks.  This is proposed only for compatibility
-   with existing UNIX system implementations. Sites where security is
-   critical SHOULD consider using a strong authentication service for
-   user authentication.
-
-   Alternatively, the encrypted password could be made available only to
-   a subset of privileged DUAs, which would provide "shadow" password
-   service to client applications. This may be difficult to enforce.
-
-   Because the schema represents operating system-level entities, access
-   to these entities SHOULD be granted on a discretionary basis. (There
-   is little point in restricting access to data which will be
-   republished without restriction, however.) It is particularly
-   important that only administrators can modify entries defined in this
-   schema, with the exception of allowing a principal to change their
-   password (which may be done on behalf of the user by a client bound
-   as a superior principal, such that password restrictions may be
-   enforced). For example, if a user were allowed to change the value of
-   their uidNumber attribute, they could subvert security by
-   equivalencing their account with the superuser account.
-
-   A subtree of the DIT which is to be republished by a DUA (such as a
-   NIS gateway) SHOULD be within the same administrative domain that the
-   republishing DUA represents. (For example, principals outside an
-   organization, while conceivably part of the DIT, should not be
-   considered with the same degree of authority as those within the
-   organization.)
-
-   Finally, care should be exercised with integer attributes of a
-   sensitive nature (particularly the uidNumber and gidNumber
-   attributes) which contain zero-length values. DUAs MAY treat such
-   values as corresponding to the "nobody" or "nogroup" user and group,
-   respectively.
-
-8. Acknowledgements
-
-   Thanks to Leif Hedstrom of Netscape Communications Corporation,
-   Michael Grant and Rosanna Lee of Sun Microsystems Inc., Ed Reed of
-   Novell Inc., and Mark Wahl of Critical Angle Inc. for their valuable
-   contributions to the development of this schema. Thanks to Andrew
-   Josey of The Open Group for clarifying the use of the UNIX trademark,
-   and to Tim Howes and Peter J. Cherny for their support.
-
-
-
-Howard                        Experimental                     [Page 16]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   UNIX is a registered trademark of The Open Group.
-
-9. References
-
-   [RFC1057]
-        Sun Microsystems, Inc., "RPC: Remote Procedure Call: Protocol
-        Specification Version 2", RFC 1057, June 1988.
-
-   [RFC1279]
-        Kille, S., "X.500 and Domains", RFC 1279, November 1991.
-
-   [RFC1884]
-        Hinden, R., and S. Deering, "IP Version 6 Addressing
-        Architecture", RFC 1884, December 1995.
-
-   [RFC2119]
-        Bradner, S., "Key Words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2251]
-        Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
-        Protocol (v3)", RFC 2251, December 1997.
-
-   [RFC2252]
-        Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight
-        Directory Access Protocol (v3): Attribute Syntax Definitions",
-        RFC 2252, December 1997.
-
-   [RFC2254]
-        Howes, T., "The String Representation of LDAP Search Filters",
-        RFC 2254, December 1997.
-
-   [RFC2256]
-        Wahl, M., "A Summary of the X.500(96) User Schema for use with
-        LDAPv3", RFC 2256, December 1997.
-
-   [ROSE]
-        M. T. Rose, "The Little Black Book: Mail Bonding with OSI
-        Directory Services", ISBN 0-13-683210-5, Prentice-Hall, Inc.,
-        1992.
-
-   [X500]
-        "Information Processing Systems - Open Systems Interconnection -
-        The Directory: Overview of Concepts, Models and Service",
-        ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988.
-
-
-
-
-
-
-Howard                        Experimental                     [Page 17]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   [XOPEN]
-        ISO/IEC 9945-1:1990, Information Technology - Portable Operating
-        Systems Interface (POSIX) - Part 1: Systems Application
-        Programming Interface (API) [C Language]
-
-10. Author's Address
-
-   Luke Howard
-   PO Box 59
-   Central Park Vic 3145
-   Australia
-
-   EMail: lukeh at xedoc.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howard                        Experimental                     [Page 18]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-A. Example entries
-
-   The examples described in this section are provided to illustrate the
-   schema described in this memo. They are not meant to be exhaustive.
-
-   The following entry is an example of the posixAccount class:
-
-           dn: uid=lester, dc=aja, dc=com
-           objectClass: top
-           objectClass: account
-           objectClass: posixAccount
-           uid: lester
-           cn: Lester the Nightfly
-           userPassword: {crypt}X5/DBrWPOQQaI
-           gecos: Lester
-           loginShell: /bin/csh
-           uidNumber: 10
-           gidNumber: 10
-           homeDirectory: /home/lester
-
-
-   This corresponds the UNIX system password file entry:
-
-        lester:X5/DBrWPOQQaI:10:10:Lester:/home/lester:/bin/sh
-
-   The following entry is an example of the ipHost class:
-
-           dn: cn=peg.aja.com, dc=aja, dc=com
-           objectClass: top
-           objectClass: device
-           objectClass: ipHost
-           objectClass: bootableDevice
-           objectClass: ieee802Device
-           cn: peg.aja.com
-           cn: www.aja.com
-           ipHostNumber: 10.0.0.1
-           macAddress: 00:00:92:90:ee:e2
-           bootFile: mach
-           bootParameter: root=fs:/nfsroot/peg
-           bootParameter: swap=fs:/nfsswap/peg
-           bootParameter: dump=fs:/nfsdump/peg
-
-   This entry represents the host canonically peg.aja.com, also known as
-   www.aja.com. The Ethernet address and four boot parameters are also
-   specified.
-
-
-
-
-
-
-Howard                        Experimental                     [Page 19]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-   An example of the nisNetgroup class:
-
-           dn: cn=nightfly, dc=aja, dc=com
-           objectClass: top
-           objectClass: nisNetgroup
-           cn: nightfly
-           nisNetgroupTriple: (charlemagne,peg,dunes.aja.com)
-           nisNetgroupTriple: (lester,-,)
-           memberNisNetgroup: kamakiriad
-
-   This entry represents the netgroup nightfly, which contains two
-   triples (the user charlemagne, the host peg, and the domain
-   dunes.aja.com; and, the user lester, no host, and any domain) and one
-   netgroup (kamakiriad).
-
-   Finally, an example of the nisObject class:
-
-           dn: nisMapName=tracks, dc=dunes, dc=aja, dc=com
-           objectClass: top
-           objectClass: nisMap
-           nisMapName: tracks
-
-           dn: cn=Maxine, nisMapName=tracks, dc=dunes, dc=aja, dc=com
-           objectClass: top
-           objectClass: nisObject
-           cn: Maxine
-           nisMapName: tracks
-           nisMapEntry: Nightfly$4
-
-   This entry represents the NIS map tracks, and a single map entry.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howard                        Experimental                     [Page 20]
-
-RFC 2307      Using LDAP as a Network Information Service     March 1998
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (1998).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howard                        Experimental                     [Page 21]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2696.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2696.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2696.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        C. Weider
-Request for Comments: 2696                                   A. Herron
-Category: Informational                                     A. Anantha
-                                                             Microsoft
-                                                              T. Howes
-                                                              Netscape
-                                                        September 1999
-
-
-      LDAP Control Extension for Simple Paged Results Manipulation
-
-Status of this Memo
-
-   This memo provides information for the Internet community.  It does
-   not specify an Internet standard of any kind.  Distribution of this
-   memo is unlimited.
-
-Copyright Notice
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-1. Abstract
-
-   This document describes an LDAPv3 control extension for simple paging
-   of search results. This control extension allows a client to control
-   the rate at which an LDAP server returns the results of an LDAP
-   search operation. This control may be useful when the LDAP client has
-   limited resources and may not be able to process the entire result
-   set from a given LDAP query, or when the LDAP client is connected
-   over a low-bandwidth connection. Other operations on the result set
-   are not defined in this extension. This extension is not designed to
-   provide more sophisticated result set management.
-
-   The key words "MUST", "SHOULD", and "MAY" used in this document are
-   to be interpreted as described in [bradner97].
-
-2. The Control
-
-   This control is included in the searchRequest and searchResultDone
-   messages as part of the controls field of the LDAPMessage, as defined
-   in Section 4.1.12 of [LDAPv3]. The structure of this control is as
-   follows:
-
-
-
-
-
-
-
-
-
-Weider, et al.               Informational                      [Page 1]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-pagedResultsControl ::= SEQUENCE {
-        controlType     1.2.840.113556.1.4.319,
-        criticality     BOOLEAN DEFAULT FALSE,
-        controlValue    searchControlValue
-}
-
-The searchControlValue is an OCTET STRING wrapping the BER-encoded
-version of the following SEQUENCE:
-
-realSearchControlValue ::= SEQUENCE {
-        size            INTEGER (0..maxInt),
-                                -- requested page size from client
-                                -- result set size estimate from server
-        cookie          OCTET STRING
-}
-
-3. Client-Server Interaction
-
-   An LDAP client application that needs to control the rate at which
-   results are returned MAY specify on the searchRequest a
-   pagedResultsControl with size set to the desired page size and cookie
-   set to the zero-length string. The page size specified MAY be greater
-   than zero and less than the sizeLimit value specified in the
-   searchRequest.
-
-   If the page size is greater than or equal to the sizeLimit value, the
-   server should ignore the control as the request can be satisfied in a
-   single page. If the server does not support this control, the server
-   MUST return an error of unsupportedCriticalExtension if the client
-   requested it as critical, otherwise the server SHOULD ignore the
-   control. The remainder of this section assumes the server does not
-   ignore the client's pagedResultsControl.
-
-   Each time the server returns a set of results to the client when
-   processing a search request containing the pagedResultsControl, the
-   server includes the pagedResultsControl control in the
-   searchResultDone message. In the control returned to the client, the
-   size MAY be set to the server's estimate of the total number of
-   entries in the entire result set. Servers that cannot provide such an
-   estimate MAY set this size to zero (0).  The cookie MUST be set to an
-   empty value if there are no more entries to return (i.e., the page of
-   search results returned was the last), or, if there are more entries
-   to return, to an octet string of the server's choosing,used to resume
-   the search.
-
-   The client MUST consider the cookie to be an opaque structure and
-   make no assumptions about its internal organization or value. When
-   the client wants to retrieve more entries for the result set, it MUST
-
-
-
-Weider, et al.               Informational                      [Page 2]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-   send to the server a searchRequest with all values identical to the
-   initial request with the exception of the messageID, the cookie, and
-   optionally a modified pageSize. The cookie MUST be the octet string
-   on the last searchResultDone response returned by the server.
-   Returning cookies from previous searchResultDone responses besides
-   the last one is undefined, as the server implementation may restrict
-   cookies from being reused.
-
-   The server will then return the next set of results from the whole
-   result set. This interaction will continue until the client has
-   retrieved all the results, in which case the cookie in the
-   searchResultDone field will be empty, or until the client abandons
-   the search sequence as described below. Once the paged search
-   sequence has been completed, the cookie is no longer valid and MUST
-   NOT be used.
-
-   A sequence of paged search requests is abandoned by the client
-   sending a search request containing a pagedResultsControl with the
-   size set to zero (0) and the cookie set to the last cookie returned
-   by the server.  A client MAY use the LDAP Abandon operation to
-   abandon one paged search request in progress, but this is discouraged
-   as it MAY invalidate the client's cookie.
-
-   If, for any reason, the server cannot resume a paged search operation
-   for a client, then it SHOULD return the appropriate error in a
-   searchResultDone entry. If this occurs, both client and server should
-   assume the paged result set is closed and no longer resumable.
-
-   A client may have any number of outstanding search requests pending,
-   any of which may have used the pagedResultsControl.  A server
-   implementation which requires a limit on the number of outstanding
-   paged search requests from a given client MAY either return
-   unwillingToPerform when the client attempts to create a new paged
-   search request, or age out an older result set.  If the server
-   implementation ages out an older paged search request, it SHOULD
-   return "unwilling to perform" if the client attempts to resume the
-   paged search that was aged out.
-
-   A client may safely assume that all entries that satisfy a given
-   search query are returned once and only once during the set of paged
-   search requests/responses necessary to enumerate the entire result
-   set, unless the result set for that query has changed since the
-   searchRequest starting the request/response sequence was processed.
-   In that case, the client may receive a given entry multiple times
-   and/or may not receive all entries matching the given search
-   criteria.
-
-
-
-
-
-Weider, et al.               Informational                      [Page 3]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-4. Example
-
-   The following example illustrates the client-server interaction
-   between a client doing a search requesting a page size limit of 3.
-   The entire result set returned by the server contains 5 entries.
-
-   Lines beginning with "C:" indicate requests sent from client to
-   server. Lines beginning with "S:" indicate responses sent from server
-   to client. Lines beginning with "--" are comments to help explain the
-   example.
-
-   -- Client sends a search request asking for paged results
-   -- with a page size of 3.
-   C: SearchRequest + pagedResultsControl(3,"")
-   -- Server responds with three entries plus an indication
-   -- of 5 total entries in the search result and an opaque
-   -- cooking to be used by the client when retrieving subsequent
-   -- pages.
-   S: SearchResultEntry
-   S: SearchResultEntry
-   S: SearchResultEntry
-   S: SearchResultDone + pagedResultsControl(5, "opaque")
-   -- Client sends an identical search request (except for
-   -- message id), returning the opaque cooking, asking for
-   -- the next page.
-   C: SearchRequest + PagedResultsControl(3, "opaque")
-   -- Server responds with two entries plus an indication
-   -- that there are no more entries (null cookie).
-   S: SearchResultEntry
-   S: SearchResultEntry
-   S: SearchResultDone + pagedResultsControl(5,"")
-
-5. Relationship to X.500
-
-   For LDAP servers providing a front end to X.500 (93) directories, the
-   paged results control defined in this document may be mapped directly
-   onto the X.500 (93) PagedResultsRequest defined in X.511 [x500]. The
-   size parameter may be mapped onto pageSize.  The cookie parameter may
-   be mapped onto queryReference.  The sortKeys and reverse fields in
-   the X.500 PagedResultsRequest are excluded.
-
-
-
-
-
-
-
-
-
-
-
-Weider, et al.               Informational                      [Page 4]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-6. Security Considerations
-
-   Server implementors should consider the resources used when clients
-   send searches with the simple paged control, to ensure that a
-   client's misuse of this control does not lock out other legitimate
-   operations.
-
-   Servers implementations may enforce an overriding sizelimit, to
-   prevent the retrieval of large portions of a publically-accessible
-   directory.
-
-   Clients can, using this control, determine how many entries match a
-   particular filter, before the entries are returned to the client.
-   This may require special processing in servers which perform access
-   control checks on entries to determine whether the existence of the
-   entry can be disclosed to the client.
-
-7. References
-
-   [LDAPv3]    Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
-               Access Protocol (v3)", RFC 2251, December 1997.
-
-   [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weider, et al.               Informational                      [Page 5]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-8. Authors' Addresses
-
-   Chris Weider
-   Microsoft Corp.
-   1 Microsoft Way
-   Redmond, WA 98052
-   USA
-
-   Phone: +1 425 882-8080
-   EMail: cweider at microsoft.com
-
-
-   Andy Herron
-   Microsoft Corp.
-   1 Microsoft Way
-   Redmond, WA 98052
-   USA
-
-   Phone: +1 425 882-8080
-   EMail: andyhe at microsoft.com
-
-
-   Anoop Anantha
-   Microsoft Corp.
-   1 Microsoft Way
-   Redmond, WA 98052
-   USA
-
-   Phone: +1 425 882-8080
-   EMail: anoopa at microsoft.com
-
-
-   Tim Howes
-   Netscape Communications Corp.
-   501 E. Middlefield Road
-   Mountain View, CA 94043
-   USA
-
-   Phone: +1 415 937-2600
-   EMail: howes at netscape.com
-
-
-
-
-
-
-
-
-
-
-
-Weider, et al.               Informational                      [Page 6]
-
-RFC 2696       LDAP Control Ext. for Simple Paged Results September 1999
-
-
-9.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (1999).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Weider, et al.               Informational                      [Page 7]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2849.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2849.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2849.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                             G. Good
-Request for Comments: 2849                   iPlanet e-commerce Solutions
-Category: Standards Track                                       June 2000
-
-
-   The LDAP Data Interchange Format (LDIF) - Technical Specification
-
-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 (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes a file format suitable for describing
-   directory information or modifications made to directory information.
-   The file format, known as LDIF, for LDAP Data Interchange Format, is
-   typically used to import and export directory information between
-   LDAP-based directory servers, or to describe a set of changes which
-   are to be applied to a directory.
-
-Background and Intended Usage
-
-   There are a number of situations where a common interchange format is
-   desirable.  For example, one might wish to export a copy of the
-   contents of a directory server to a file, move that file to a
-   different machine, and import the contents into a second directory
-   server.
-
-   Additionally, by using a well-defined interchange format, development
-   of data import tools from legacy systems is facilitated.  A fairly
-   simple set of tools written in awk or perl can, for example, convert
-   a database of personnel information into an LDIF file. This file can
-   then be imported into a directory server, regardless of the internal
-   database representation the target directory server uses.
-
-   The LDIF format was originally developed and used in the University
-   of Michigan LDAP implementation.  The first use of LDIF was in
-   describing directory entries.  Later, the format was expanded to
-   allow representation of changes to directory entries.
-
-
-
-
-Good                        Standards Track                     [Page 1]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-   Relationship to the application/directory MIME content-type:
-
-   The application/directory MIME content-type [1] is a general
-   framework and format for conveying directory information, and is
-   independent of any particular directory service.  The LDIF format is
-   a simpler format which is perhaps easier to create, and may also be
-   used, as noted, to describe a set of changes to be applied to a
-   directory.
-
-   The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
-   used in this document are to be interpreted as described in [7].
-
-Definition of the LDAP Data Interchange Format
-
-   The LDIF format is used to convey directory information, or a
-   description of a set of changes made to directory entries.  An LDIF
-   file consists of a series of records separated by line separators.  A
-   record consists of a sequence of lines describing a directory entry,
-   or a sequence of lines describing a set of changes to a directory
-   entry.  An LDIF file specifies a set of directory entries, or a set
-   of changes to be applied to directory entries, but not both.
-
-   There is a one-to-one correlation between LDAP operations that modify
-   the directory (add, delete, modify, and modrdn), and the types of
-   changerecords described below ("add", "delete", "modify", and
-   "modrdn" or "moddn").  This correspondence is intentional, and
-   permits a straightforward translation from LDIF changerecords to
-   protocol operations.
-
-Formal Syntax Definition of LDIF
-
-   The following definition uses the augmented Backus-Naur Form
-   specified in RFC 2234 [2].
-
-ldif-file                = ldif-content / ldif-changes
-
-ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)
-
-ldif-changes             = version-spec 1*(1*SEP ldif-change-record)
-
-ldif-attrval-record      = dn-spec SEP 1*attrval-spec
-
-ldif-change-record       = dn-spec SEP *control changerecord
-
-version-spec             = "version:" FILL version-number
-
-
-
-
-
-
-Good                        Standards Track                     [Page 2]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-version-number           = 1*DIGIT
-                           ; version-number MUST be "1" for the
-                           ; LDIF format described in this document.
-
-dn-spec                  = "dn:" (FILL distinguishedName /
-                                  ":" FILL base64-distinguishedName)
-
-distinguishedName        = SAFE-STRING
-                           ; a distinguished name, as defined in [3]
-
-base64-distinguishedName = BASE64-UTF8-STRING
-                           ; a distinguishedName which has been base64
-                           ; encoded (see note 10, below)
-
-rdn                      = SAFE-STRING
-                           ; a relative distinguished name, defined as
-                           ; <name-component> in [3]
-
-base64-rdn               = BASE64-UTF8-STRING
-                           ; an rdn which has been base64 encoded (see
-                           ; note 10, below)
-
-control                  = "control:" FILL ldap-oid        ; controlType
-                           0*1(1*SPACE ("true" / "false")) ; criticality
-                           0*1(value-spec)                ; controlValue
-                           SEP
-                           ; (See note 9, below)
-
-ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
-                           ; An LDAPOID, as defined in [4]
-
-attrval-spec             = AttributeDescription value-spec SEP
-
-value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
-                                ":" FILL (BASE64-STRING) /
-                                "<" FILL url)
-                           ; See notes 7 and 8, below
-
-url                      = <a Uniform Resource Locator,
-                            as defined in [6]>
-                                   ; (See Note 6, below)
-
-AttributeDescription     = AttributeType [";" options]
-                           ; Definition taken from [4]
-
-AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
-
-options                  = option / (option ";" options)
-
-
-
-Good                        Standards Track                     [Page 3]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-option                   = 1*opt-char
-
-attr-type-chars          = ALPHA / DIGIT / "-"
-
-opt-char                 = attr-type-chars
-
-changerecord             = "changetype:" FILL
-                           (change-add / change-delete /
-                            change-modify / change-moddn)
-
-change-add               = "add"                SEP 1*attrval-spec
-
-change-delete            = "delete"             SEP
-
-change-moddn             = ("modrdn" / "moddn") SEP
-                            "newrdn:" (    FILL rdn /
-                                       ":" FILL base64-rdn) SEP
-                            "deleteoldrdn:" FILL ("0" / "1")  SEP
-                            0*1("newsuperior:"
-                            (    FILL distinguishedName /
-                             ":" FILL base64-distinguishedName) SEP)
-
-change-modify            = "modify"             SEP *mod-spec
-
-mod-spec                 = ("add:" / "delete:" / "replace:")
-                           FILL AttributeDescription SEP
-                           *attrval-spec
-                           "-" SEP
-
-SPACE                    = %x20
-                           ; ASCII SP, space
-
-FILL                     = *SPACE
-
-SEP                      = (CR LF / LF)
-
-CR                       = %x0D
-                           ; ASCII CR, carriage return
-
-LF                       = %x0A
-                           ; ASCII LF, line feed
-
-ALPHA                    = %x41-5A / %x61-7A
-                           ; A-Z / a-z
-
-DIGIT                    = %x30-39
-                           ; 0-9
-
-
-
-
-Good                        Standards Track                     [Page 4]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-UTF8-1                   = %x80-BF
-
-UTF8-2                   = %xC0-DF UTF8-1
-
-UTF8-3                   = %xE0-EF 2UTF8-1
-
-UTF8-4                   = %xF0-F7 3UTF8-1
-
-UTF8-5                   = %xF8-FB 4UTF8-1
-
-UTF8-6                   = %xFC-FD 5UTF8-1
-
-SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
-                           ; any value <= 127 decimal except NUL, LF,
-                           ; and CR
-
-SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
-                           %x21-39 / %x3B / %x3D-7F
-                           ; any value <= 127 except NUL, LF, CR,
-                           ; SPACE, colon (":", ASCII 58 decimal)
-                           ; and less-than ("<" , ASCII 60 decimal)
-
-SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
-
-UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
-                           UTF8-4 / UTF8-5 / UTF8-6
-
-UTF8-STRING              = *UTF8-CHAR
-
-BASE64-UTF8-STRING       = BASE64-STRING
-                           ; MUST be the base64 encoding of a
-                           ; UTF8-STRING
-
-BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
-                           %x61-7A
-                           ; +, /, 0-9, =, A-Z, and a-z
-                           ; as specified in [5]
-
-BASE64-STRING            = [*(BASE64-CHAR)]
-
-
-   Notes on LDIF Syntax
-
-      1)  For the LDIF format described in this document, the version
-          number MUST be "1". If the version number is absent,
-          implementations MAY choose to interpret the contents as an
-          older LDIF file format, supported by the University of
-          Michigan ldap-3.3 implementation [8].
-
-
-
-Good                        Standards Track                     [Page 5]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-      2)  Any non-empty line, including comment lines, in an LDIF file
-          MAY be folded by inserting a line separator (SEP) and a SPACE.
-          Folding MUST NOT occur before the first character of the line.
-          In other words, folding a line into two lines, the first of
-          which is empty, is not permitted. Any line that begins with a
-          single space MUST be treated as a continuation of the previous
-          (non-empty) line. When joining folded lines, exactly one space
-          character at the beginning of each continued line must be
-          discarded. Implementations SHOULD NOT fold lines in the middle
-          of a multi-byte UTF-8 character.
-
-      3)  Any line that begins with a pound-sign ("#", ASCII 35) is a
-          comment line, and MUST be ignored when parsing an LDIF file.
-
-      4)  Any dn or rdn that contains characters other than those
-          defined as "SAFE-UTF8-CHAR", or begins with a character other
-          than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
-          base-64 encoded.  Other values MAY be base-64 encoded.  Any
-          value that contains characters other than those defined as
-          "SAFE-CHAR", or begins with a character other than those
-          defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
-          Other values MAY be base-64 encoded.
-
-      5)  When a zero-length attribute value is to be included directly
-          in an LDIF file, it MUST be represented as
-          AttributeDescription ":" FILL SEP.  For example, "seeAlso:"
-          followed by a newline represents a zero-length "seeAlso"
-          attribute value.  It is also permissible for the value
-          referred to by a URL to be of zero length.
-
-      6) When a URL is specified in an attrval-spec, the following
-          conventions apply:
-
-         a) Implementations SHOULD support the file:// URL format.  The
-            contents of the referenced file are to be included verbatim
-            in the interpreted output of the LDIF file.
-         b) Implementations MAY support other URL formats.  The
-            semantics associated with each supported URL will be
-            documented in an associated Applicability Statement.
-
-      7)  Distinguished names, relative distinguished names, and
-          attribute values of DirectoryString syntax MUST be valid UTF-8
-          strings.  Implementations that read LDIF MAY interpret files
-          in which these entities are stored in some other character set
-          encoding, but implementations MUST NOT generate LDIF content
-          which does not contain valid UTF-8 data.
-
-
-
-
-
-Good                        Standards Track                     [Page 6]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-      8)  Values or distinguished names that end with SPACE SHOULD be
-          base-64 encoded.
-
-      9)  When controls are included in an LDIF file, implementations
-          MAY choose to ignore some or all of them. This may be
-          necessary if the changes described in the LDIF file are being
-          sent on an LDAPv2 connection (LDAPv2 does not support
-          controls), or the particular controls are not supported by the
-          remote server. If the criticality of a control is "true", then
-          the implementation MUST either include the control, or MUST
-          NOT send the operation to a remote server.
-
-      10) When an attrval-spec, distinguishedName, or rdn is base64-
-          encoded, the encoding rules specified in [5] are used with the
-          following exceptions:  a) The requirement that base64 output
-          streams must be represented as lines of no more than 76
-          characters is removed. Lines in LDIF files may only be folded
-          according to the folding rules described in note 2, above.  b)
-          Base64 strings in [5] may contain characters other than those
-          defined in BASE64-CHAR, and are ignored. LDIF does not permit
-          any extraneous characters, other than those used for line
-          folding.
-
-Examples of LDAP Data Interchange Format
-
-Example 1: An simple LDAP file with two entries
-
-version: 1
-dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-cn: Barbara Jensen
-cn: Barbara J Jensen
-cn: Babs Jensen
-sn: Jensen
-uid: bjensen
-telephonenumber: +1 408 555 1212
-description: A big sailing fan.
-
-dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-cn: Bjorn Jensen
-sn: Jensen
-telephonenumber: +1 408 555 1212
-
-
-
-
-Good                        Standards Track                     [Page 7]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-Example 2: A file containing an entry with a folded attribute value
-
-version: 1
-dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
-objectclass:top
-objectclass:person
-objectclass:organizationalPerson
-cn:Barbara Jensen
-cn:Barbara J Jensen
-cn:Babs Jensen
-sn:Jensen
-uid:bjensen
-telephonenumber:+1 408 555 1212
-description:Babs is a big sailing fan, and travels extensively in sea
- rch of perfect sailing conditions.
-title:Product Manager, Rod and Reel Division
-
-Example 3: A file containing a base-64-encoded value
-
-version: 1
-dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-cn: Gern Jensen
-cn: Gern O Jensen
-sn: Jensen
-uid: gernj
-telephonenumber: +1 408 555 1212
-description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
-IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
-VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
-b3V0IG1vcmUu
-
-Example 4: A file containing an entries with UTF-8-encoded attribute
-values, including language tags.  Comments indicate the contents
-of UTF-8-encoded attributes and distinguished names.
-
-version: 1
-dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
-# dn:: ou=<JapaneseOU>,o=Airius
-objectclass: top
-objectclass: organizationalUnit
-ou:: 5Za25qWt6YOo
-# ou:: <JapaneseOU>
-ou;lang-ja:: 5Za25qWt6YOo
-# ou;lang-ja:: <JapaneseOU>
-ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
-
-
-
-Good                        Standards Track                     [Page 8]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
-ou;lang-en: Sales
-description: Japanese office
-
-dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
-# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
-userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-objectclass: inetOrgPerson
-uid: rogasawara
-mail: rogasawara at airius.co.jp
-givenname;lang-ja:: 44Ot44OJ44OL44O8
-# givenname;lang-ja:: <JapaneseGivenname>
-sn;lang-ja:: 5bCP56yg5Y6f
-# sn;lang-ja:: <JapaneseSn>
-cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
-# cn;lang-ja:: <JapaneseCn>
-title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
-# title;lang-ja:: <JapaneseTitle>
-preferredlanguage: ja
-givenname:: 44Ot44OJ44OL44O8
-# givenname:: <JapaneseGivenname>
-sn:: 5bCP56yg5Y6f
-# sn:: <JapaneseSn>
-cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
-# cn:: <JapaneseCn>
-title:: 5Za25qWt6YOoIOmDqOmVtw==
-# title:: <JapaneseTitle>
-givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
-# givenname;lang-ja;phonetic::
-<JapaneseGivenname_in_phonetic_representation_kana>
-sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
-# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
-cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
-# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
-title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
-# title;lang-ja;phonetic::
-# <JapaneseTitle_in_phonetic_representation_kana>
-givenname;lang-en: Rodney
-sn;lang-en: Ogasawara
-cn;lang-en: Rodney Ogasawara
-title;lang-en: Sales, Director
-
-
-
-
-
-
-
-Good                        Standards Track                     [Page 9]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-Example 5: A file containing a reference to an external file
-
-version: 1
-dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-cn: Horatio Jensen
-
-cn: Horatio N Jensen
-sn: Jensen
-uid: hjensen
-telephonenumber: +1 408 555 1212
-jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
-
-Example 6: A file containing a series of change records and comments
-
-version: 1
-# Add a new entry
-dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
-changetype: add
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-cn: Fiona Jensen
-sn: Jensen
-uid: fiona
-telephonenumber: +1 408 555 1212
-jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
-
-# Delete an existing entry
-dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
-changetype: delete
-
-# Modify an entry's relative distinguished name
-dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
-changetype: modrdn
-newrdn: cn=Paula Jensen
-deleteoldrdn: 1
-
-# Rename an entry and move all of its children to a new location in
-# the directory tree (only implemented by LDAPv3 servers).
-dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
-changetype: modrdn
-newrdn: ou=Product Development Accountants
-deleteoldrdn: 0
-newsuperior: ou=Accounting, dc=airius, dc=com
-
-
-
-
-Good                        Standards Track                    [Page 10]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-# Modify an entry: add an additional value to the postaladdress
-# attribute, completely delete the description attribute, replace
-# the telephonenumber attribute with two values, and delete a specific
-# value from the facsimiletelephonenumber attribute
-dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
-changetype: modify
-add: postaladdress
-postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
--
-
-delete: description
--
-replace: telephonenumber
-telephonenumber: +1 408 555 1234
-telephonenumber: +1 408 555 5678
--
-delete: facsimiletelephonenumber
-facsimiletelephonenumber: +1 408 555 9876
--
-
-# Modify an entry: replace the postaladdress attribute with an empty
-# set of values (which will cause the attribute to be removed), and
-# delete the entire description attribute. Note that the first will
-# always succeed, while the second will only succeed if at least
-# one value for the description attribute is present.
-dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
-changetype: modify
-replace: postaladdress
--
-delete: description
--
-
-Example 7: An LDIF file containing a change record with a control
-version: 1
-# Delete an entry. The operation will attach the LDAPv3
-# Tree Delete Control defined in [9]. The criticality
-# field is "true" and the controlValue field is
-# absent, as required by [9].
-dn: ou=Product Development, dc=airius, dc=com
-control: 1.2.840.113556.1.4.805 true
-changetype: delete
-
-
-
-
-
-
-
-
-
-
-Good                        Standards Track                    [Page 11]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-Security Considerations
-
-   Given typical directory applications, an LDIF file is likely to
-   contain sensitive personal data.  Appropriate measures should be
-   taken to protect the privacy of those persons whose data is contained
-   in an LDIF file.
-
-   Since ":<" directives can cause external content to be included when
-   processing an LDIF file, one should be cautious of accepting LDIF
-   files from external sources.  A "trojan" LDIF file could name a file
-   with sensitive contents and cause it to be included in a directory
-   entry, which a hostile entity could read via LDAP.
-
-   LDIF does not provide any method for carrying authentication
-   information with an LDIF file.  Users of LDIF files must take care to
-   verify the integrity of an LDIF file received from an external
-   source.
-
-Acknowledgments
-
-   The LDAP Interchange Format was developed as part of the University
-   of Michigan LDAP reference implementation, and was developed by Tim
-   Howes, Mark Smith, and Gordon Good.  It is based in part upon work
-   supported by the National Science Foundation under Grant No.  NCR-
-   9416667.
-
-   Members of the IETF LDAP Extensions Working group provided many
-   helpful suggestions. In particular, Hallvard B. Furuseth of the
-   University of Oslo made many significant contributions to this
-   document, including a thorough review and rewrite of the BNF.
-
-References
-
-   [1]  Howes, T. and M. Smith, "A MIME Content-Type for Directory
-        Information", RFC 2425, September 1998.
-
-   [2]  Crocker, D., and P. Overell, "Augmented BNF for Syntax
-        Specifications: ABNF", RFC 2234, November 1997.
-
-   [3]  Wahl, M., Kille, S. and T. Howes, "A String Representation of
-        Distinguished Names", RFC 2253, December 1997.
-
-   [4]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
-        Protocol (v3)", RFC 2251, July 1997.
-
-   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-        Extensions (MIME) Part One: Format of Internet Message Bodies",
-        RFC 2045, November 1996.
-
-
-
-Good                        Standards Track                    [Page 12]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-   [6]  Berners-Lee,  T., Masinter, L. and M. McCahill, "Uniform
-        Resource Locators (URL)", RFC 1738, December 1994.
-
-   [7]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
-        Levels", BCP 14, RFC 2119, March 1997.
-
-   [8]  The SLAPD and SLURPD Administrators Guide.  University of
-        Michigan, April 1996.  <URL:
-        http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
-
-   [9]  M. P. Armijo, "Tree Delete Control", Work in Progress.
-
-Author's Address
-
-   Gordon Good
-   iPlanet e-commerce Solutions
-   150 Network Circle
-   Mailstop USCA17-201
-   Santa Clara, CA 95054, USA
-
-   Phone: +1 408 276 4351
-   EMail:  ggood at netscape.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Good                        Standards Track                    [Page 13]
-
-RFC 2849              LDAP Data Interchange Format             June 2000
-
-
-Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Good                        Standards Track                    [Page 14]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2891.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2891.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc2891.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           T. Howes
-Request for Comments: 2891                                     Loudcloud
-Category: Standards Track                                        M. Wahl
-                                                        Sun Microsystems
-                                                              A. Anantha
-                                                               Microsoft
-                                                             August 2000
-
-
-    LDAP Control Extension for Server Side Sorting of Search Results
-
-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 (2000).  All Rights Reserved.
-
-Abstract
-
-   This document describes two LDAPv3 control extensions for server side
-   sorting of search results. These controls allows a client to specify
-   the attribute types and matching rules a server should use when
-   returning the results to an LDAP search request. The controls may be
-   useful when the LDAP client has limited functionality or for some
-   other reason cannot sort the results but still needs them sorted.
-   Other permissible controls on search operations are not defined in
-   this extension.
-
-   The sort controls allow a server to return a result code for the
-   sorting of the results that is independent of the result code
-   returned for the search operation.
-
-   The key words "MUST", "SHOULD", and "MAY" used in this document are
-   to be interpreted as described in [bradner97].
-
-
-
-
-
-
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 1]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-1.  The Controls
-
-1.1 Request Control
-
-   This control is included in the searchRequest message as part of the
-   controls field of the LDAPMessage, as defined in Section 4.1.12 of
-   [LDAPv3].
-
-   The controlType is set to "1.2.840.113556.1.4.473". The criticality
-   MAY be either TRUE or FALSE (where absent is also equivalent to
-   FALSE) at the client's option. The controlValue is an OCTET STRING,
-   whose value is the BER encoding of a value of the following SEQUENCE:
-
-      SortKeyList ::= SEQUENCE OF SEQUENCE {
-                 attributeType   AttributeDescription,
-                 orderingRule    [0] MatchingRuleId OPTIONAL,
-                 reverseOrder    [1] BOOLEAN DEFAULT FALSE }
-
-   The SortKeyList sequence is in order of highest to lowest sort key
-   precedence.
-
-   The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD
-   be one that is valid for the attribute type it applies to.  If it is
-   not, the server will return inappropriateMatching.
-
-   Each attributeType should only occur in the SortKeyList once. If an
-   attributeType is included in the sort key list multiple times, the
-   server should return an error in the sortResult of
-   unwillingToPerform.
-
-   If the orderingRule is omitted, the ordering MatchingRule defined for
-   use with this attribute MUST be used.
-
-   Any conformant implementation of this control MUST allow a sort key
-   list with at least one key.
-
-1.2 Response Control
-
-   This control is included in the searchResultDone message as part of
-   the controls field of the LDAPMessage, as defined in Section  4.1.12
-   of [LDAPv3].
-
-   The controlType is set to "1.2.840.113556.1.4.474". The criticality
-   is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose
-   value is the BER encoding of a value of the following SEQUENCE:
-
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 2]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-      SortResult ::= SEQUENCE {
-         sortResult  ENUMERATED {
-             success                   (0), -- results are sorted
-             operationsError           (1), -- server internal failure
-             timeLimitExceeded         (3), -- timelimit reached before
-                                            -- sorting was completed
-             strongAuthRequired        (8), -- refused to return sorted
-                                            -- results via insecure
-                                            -- protocol
-             adminLimitExceeded       (11), -- too many matching entries
-                                            -- for the server to sort
-             noSuchAttribute          (16), -- unrecognized attribute
-                                            -- type in sort key
-             inappropriateMatching    (18), -- unrecognized or
-                                            -- inappropriate matching
-                                            -- rule in sort key
-             insufficientAccessRights (50), -- refused to return sorted
-                                            -- results to this client
-             busy                     (51), -- too busy to process
-             unwillingToPerform       (53), -- unable to sort
-             other                    (80)
-             },
-       attributeType [0] AttributeDescription OPTIONAL }
-
-2.  Client-Server Interaction
-
-   The sortKeyRequestControl specifies one or more attribute types and
-   matching rules for the results returned by a search request. The
-   server SHOULD return all results for the search request in the order
-   specified by the sort keys. If the reverseOrder field is set to TRUE,
-   then the entries will be presented in reverse sorted order for the
-   specified key.
-
-   There are six possible scenarios that may occur as a result of the
-   sort control being included on the search request:
-
-   1 - If the server does not support this sorting control and the
-       client specified TRUE for the control's criticality field, then
-       the server MUST return unavailableCriticalExtension as a return
-       code in the searchResultDone message and not send back any other
-       results. This behavior is specified in section 4.1.12 of
-       [LDAPv3].
-
-   2 - If the server does not support this sorting control and the
-       client specified FALSE for the control's criticality field, then
-       the server MUST ignore the sort control and process the search
-       request as if it were not present. This behavior is specified in
-       section 4.1.12 of [LDAPv3].
-
-
-
-Howes, et al.               Standards Track                     [Page 3]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-   3 - If the server supports this sorting control but for some reason
-       cannot sort the search results using the specified sort keys and
-       the client specified TRUE for the control's criticality field,
-       then the server SHOULD do the following: return
-       unavailableCriticalExtension as a return code in the
-       searchResultDone message; include the sortKeyResponseControl in
-       the searchResultDone message, and not send back any search result
-       entries.
-
-   4 - If the server supports this sorting control but for some reason
-       cannot sort the search results using the specified sort keys and
-       the client specified FALSE for the control's criticality field,
-       then the server should return all search results unsorted and
-       include the sortKeyResponseControl in the searchResultDone
-       message.
-
-   5 - If the server supports this sorting control and can sort the
-       search results using the specified sort keys, then it should
-       include the sortKeyResponseControl in the searchResultDone
-       message with a sortResult of success.
-
-   6 - If the search request failed for any reason and/or there are no
-       searchResultEntry messages returned for the search response, then
-       the server SHOULD omit the sortKeyResponseControl from the
-       searchResultDone message.
-
-   The client application is assured that the results are sorted in the
-   specified key order if and only if the result code in the
-   sortKeyResponseControl is success. If the server omits the
-   sortKeyResponseControl from the searchResultDone message, the client
-   SHOULD assume that the sort control was ignored by the server.
-
-   The sortKeyResponseControl, if included by the server in the
-   searchResultDone message, should have the sortResult set to either
-   success if the results were sorted in accordance with the keys
-   specified in the sortKeyRequestControl or set to the appropriate
-   error code as to why it could not sort the data (such as
-   noSuchAttribute or inappropriateMatching). Optionally, the server MAY
-   set the attributeType to the first attribute type specified in the
-   SortKeyList that was in error. The client SHOULD ignore the
-   attributeType field if the sortResult is success.
-
-   The server may not be able to sort the results using the specified
-   sort keys because it may not recognize one of the attribute types,
-   the matching rule associated with an attribute type is not
-   applicable, or none of the attributes in the search response are of
-   these types.  Servers may also restrict the number of keys allowed in
-   the control, such as only supporting a single key.
-
-
-
-Howes, et al.               Standards Track                     [Page 4]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-   Servers that chain requests to other LDAP servers should ensure that
-   the server satisfying the client's request sort the entire result set
-   prior to sending back the results.
-
-2.1 Behavior in a chained environment
-
-   If a server receives a sort request, the client expects to receive a
-   set of sorted results. If a client submits a sort request to a server
-   which chains the request and gets entries from multiple servers, and
-   the client has set the criticality of the sort extension to TRUE, the
-   server MUST merge sort the results before returning them to the
-   client or MUST return unwillingToPerform.
-
-2.2 Other sort issues
-
-   An entry that meets the search criteria may be missing one or more of
-   the sort keys. In that case, the entry is considered to have a value
-   of NULL for that key. This standard considers NULL to be a larger
-   value than all other valid values for that key. For example, if only
-   one key is specified, entries which meet the search criteria but do
-   not have that key collate after all the entries which do have that
-   key. If the reverseOrder flag is set, and only one key is specified,
-   entries which meet the search criteria but do not have that key
-   collate BEFORE all the entries which do have that key.
-
-   If a sort key is a multi-valued attribute, and an entry happens to
-   have multiple values for that attribute and no other controls are
-   present that affect the sorting order, then the server SHOULD use the
-   least value (according to the ORDERING rule for that attribute).
-
-3.  Interaction with other search controls
-
-   When the sortKeyRequestControl control is included with the
-   pagedResultsControl control as specified in [LdapPaged], then the
-   server should send the searchResultEntry messages sorted according to
-   the sort keys applied to the entire result set. The server should not
-   simply sort each page, as this will give erroneous results to the
-   client.
-
-   The sortKeyList must be present on each searchRequest message for the
-   paged result. It also must not change between searchRequests for the
-   same result set. If the server has sorted the data, then it SHOULD
-   send back a sortKeyResponseControl control on every searchResultDone
-   message for each page. This will allow clients to quickly determine
-   if the result set is sorted, rather than waiting to receive the
-   entire result set.
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 5]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-4.  Security Considerations
-
-   Implementors and administrators should be aware that allowing sorting
-   of results could enable the retrieval of a large number of records
-   from a given directory service, regardless of administrative limits
-   set on the maximum number of records to return.
-
-   A client that desired to pull all records out of a directory service
-   could use a combination of sorting and updating of search filters to
-   retrieve all records in a database in small result sets, thus
-   circumventing administrative limits.
-
-   This behavior can be overcome by the judicious use of permissions on
-   the directory entries by the administrator and by intelligent
-   implementations of administrative limits on the number of records
-   retrieved by a client.
-
-5.  References
-
-   [LDAPv3]    Wahl, M, Kille, S. and T. Howes, "Lightweight Directory
-               Access Protocol (v3)", RFC 2251, December 1997.
-
-   [Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP
-               Control Extension for Simple Paged Results Manipulation",
-               RFC 2696, September 1999.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 6]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-6.  Authors' Addresses
-
-   Anoop Anantha
-   Microsoft Corp.
-   1 Microsoft Way
-   Redmond, WA 98052
-   USA
-
-   Phone: +1 425 882-8080
-   EMail: anoopa at microsoft.com
-
-
-   Tim Howes
-   Loudcloud, Inc.
-   615 Tasman Dr.
-   Sunnyvale, CA 94089
-   USA
-
-   EMail: howes at loudcloud.com
-
-
-   Mark Wahl
-   Sun Microsystems, Inc.
-   8911 Capital of Texas Hwy Suite 4140
-   Austin, TX 78759
-   USA
-
-   EMail: Mark.Wahl at sun.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 7]
-
-RFC 2891     LDAP Control Extension for Server Side Sorting  August 2000
-
-
-7.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2000).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Howes, et al.               Standards Track                     [Page 8]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc3296.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc3296.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc3296.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        K. Zeilenga
-Request for Comments: 3296                           OpenLDAP Foundation
-Category: Standards Track                                      July 2002
-
-
-                    Named Subordinate References in
-        Lightweight Directory Access Protocol (LDAP) Directories
-
-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 (2002).  All Rights Reserved.
-
-Abstract
-
-   This document details schema and protocol elements for representing
-   and managing named subordinate references in Lightweight Directory
-   Access Protocol (LDAP) Directories.
-
-Conventions
-
-   Schema definitions are provided using LDAPv3 description formats
-   [RFC2252].  Definitions provided here are formatted (line wrapped)
-   for readability.
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in
-   this document are to be interpreted as described in BCP 14 [RFC2119].
-
-1.  Background and Intended Usage
-
-   The broadening of interest in LDAP (Lightweight Directory Access
-   Protocol) [RFC2251] directories beyond their use as front ends to
-   X.500 [X.500] directories has created a need to represent knowledge
-   information in a more general way.  Knowledge information is
-   information about one or more servers maintained in another server,
-   used to link servers and services together.
-
-   This document details schema and protocol elements for representing
-   and manipulating named subordinate references in LDAP directories.  A
-   referral object is used to hold subordinate reference information in
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   the directory.  These referral objects hold one or more URIs
-   [RFC2396] contained in values of the ref attribute type and are used
-   to generate protocol referrals and continuations.
-
-   A control, ManageDsaIT, is defined to allow manipulation of referral
-   and other special objects as normal objects.  As the name of control
-   implies, it is intended to be analogous to the ManageDsaIT service
-   option described in X.511(97) [X.511].
-
-   Other forms of knowledge information are not detailed by this
-   document.  These forms may be described in subsequent documents.
-
-   This document details subordinate referral processing requirements
-   for servers.  This document does not describe protocol syntax and
-   semantics.  This is detailed in RFC 2251 [RFC2251].
-
-   This document does not detail use of subordinate knowledge references
-   to support replicated environments nor distributed operations (e.g.,
-   chaining of operations from one server to other servers).
-
-2.  Schema
-
-2.1.  The referral Object Class
-
-   A referral object is a directory entry whose structural object class
-   is (or is derived from) the referral object class.
-
-      ( 2.16.840.1.113730.3.2.6
-          NAME 'referral'
-          DESC 'named subordinate reference object'
-          STRUCTURAL
-          MUST ref )
-
-   The referral object class is a structural object class used to
-   represent a subordinate reference in the directory.  The referral
-   object class SHOULD be used in conjunction with the extensibleObject
-   object class to support the naming attributes used in the entry's
-   Distinguished Name (DN) [RFC2253].
-
-   Referral objects are normally instantiated at DSEs immediately
-   subordinate to object entries within a naming context held by the
-   DSA.  Referral objects are analogous to X.500 subordinate knowledge
-   (subr) DSEs [X.501].
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   In the presence of a ManageDsaIT control, referral objects are
-   treated as normal entries as described in section 3.  Note that the
-   ref attribute is operational and will only be returned in a search
-   entry response when requested.
-
-   In the absence of a ManageDsaIT control, the content of referral
-   objects are used to construct referrals and search references as
-   described in Section 4 and, as such, the referral entries are not
-   themselves visible to clients.
-
-2.2  The ref Attribute Type
-
-      ( 2.16.840.1.113730.3.1.34
-          NAME 'ref'
-          DESC 'named reference - a labeledURI'
-          EQUALITY caseExactMatch
-          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-          USAGE distributedOperation )
-
-   The ref attribute type has directoryString syntax and is case
-   sensitive.  The ref attribute is multi-valued.  Values placed in the
-   attribute MUST conform to the specification given for the labeledURI
-   attribute [RFC2079].  The labeledURI specification defines a format
-   that is a URI, optionally followed by whitespace and a label.  This
-   document does not make use of the label portion of the syntax.
-   Future documents MAY enable new functionality by imposing additional
-   structure on the label portion of the syntax as it appears in the ref
-   attribute.
-
-   If the URI contained in a ref attribute value refers to a LDAP
-   [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255].
-   The LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
-   attribute description list, or any extensions.  The LDAP URL SHOULD
-   contain a non-empty DN.  The handling of LDAP URLs with absent or
-   empty DN parts or with explicit scope specifier is not defined by
-   this specification.
-
-   Other URI schemes MAY be used so long as all operations returning
-   referrals based upon the value could be performed.  This document
-   does not detail use of non-LDAP URIs.  This is left to future
-   specifications.
-
-   The referential integrity of the URI SHOULD NOT be validated by the
-   server holding or returning the URI (whether as a value of the
-   attribute or as part of a referral result or search reference
-   response).
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   When returning a referral result or search continuation, the server
-   MUST NOT return the separator or label portions of the attribute
-   values as part of the reference.  When the attribute contains
-   multiple values, the URI part of each value is used to construct the
-   referral result or search continuation.
-
-   The ref attribute values SHOULD NOT be used as a relative name-
-   component of an entry's DN [RFC2253].
-
-   This document uses the ref attribute in conjunction with the referral
-   object class to represent subordinate references.  The ref attribute
-   may be used for other purposes as defined by other documents.
-
-3.  The ManageDsaIT Control
-
-   The client may provide the ManageDsaIT control with an operation to
-   indicate that the operation is intended to manage objects within the
-   DSA (server) Information Tree.  The control causes Directory-specific
-   entries (DSEs), regardless of type, to be treated as normal entries
-   allowing clients to interrogate and update these entries using LDAP
-   operations.
-
-   A client MAY specify the following control when issuing an add,
-   compare, delete, modify, modifyDN, search request or an extended
-   operation for which the control is defined.
-
-   The control type is 2.16.840.1.113730.3.4.2.  The control criticality
-   may be TRUE or, if FALSE, absent.  The control value is absent.
-
-   When the control is present in the request, the server SHALL NOT
-   generate a referral or continuation reference based upon information
-   held in referral objects and instead SHALL treat the referral object
-   as a normal entry.  The server, however, is still free to return
-   referrals for other reasons.  When not present, referral objects
-   SHALL be handled as described above.
-
-   The control MAY cause other objects to be treated as normal entries
-   as defined by subsequent documents.
-
-4.  Named Subordinate References
-
-   A named subordinate reference is constructed by instantiating a
-   referral object in the referencing server with ref attribute values
-   which point to the corresponding subtree maintained in the referenced
-   server.  In general, the name of the referral object is the same as
-   the referenced object and this referenced object is a context prefix
-   [X.501].
-
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   That is, if server A holds "DC=example,DC=net" and server B holds
-   "DC=sub,DC=example,DC=net", server A may contain a referral object
-   named "DC=sub,DC=example,DC=net" which contains a ref attribute with
-   value of "ldap://B/DC=sub,DC=example,DC=net".
-
-      dn: DC=sub,DC=example,DC=net
-      dc: sub
-      ref: ldap://B/DC=sub,DC=example,DC=net
-      objectClass: referral
-      objectClass: extensibleObject
-
-   Typically the DN of the referral object and the DN of the object in
-   the referenced server are the same.
-
-   If the ref attribute has multiple values, all the DNs contained
-   within the LDAP URLs SHOULD be equivalent.  Administrators SHOULD
-   avoid configuring naming loops using referrals.
-
-   Named references MUST be treated as normal entries if the request
-   includes the ManageDsaIT control as described in section 3.
-
-5.  Scenarios
-
-   The following sections contain specifications of how referral objects
-   should be used in different scenarios followed by examples that
-   illustrate that usage.  The scenarios described here consist of
-   referral object handling when finding target of a non-search
-   operation, when finding the base of a search operation, and when
-   generating search references.  Lastly, other operation processing
-   considerations are presented.
-
-   It is to be noted that, in this document, a search operation is
-   conceptually divided into two distinct, sequential phases: (1)
-   finding the base object where the search is to begin, and (2)
-   performing the search itself.  The first phase is similar to, but not
-   the same as, finding the target of a non-search operation.
-
-   It should also be noted that the ref attribute may have multiple
-   values and, where these sections refer to a single ref attribute
-   value, multiple ref attribute values may be substituted and SHOULD be
-   processed and returned (in any order) as a group in a referral or
-   search reference in the same way as described for a single ref
-   attribute value.
-
-   Search references returned for a given request may be returned in any
-   order.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-5.1.  Example Configuration
-
-   For example, suppose the contacted server (hosta) holds the entry
-   "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following
-   referral objects:
-
-      dn: OU=People,O=MNN,C=WW
-      ou: People
-      ref: ldap://hostb/OU=People,O=MNN,C=US
-      ref: ldap://hostc/OU=People,O=MNN,C=US
-      objectClass: referral
-      objectClass: extensibleObject
-
-      dn: OU=Roles,O=MNN,C=WW
-      ou: Roles
-      ref: ldap://hostd/OU=Roles,O=MNN,C=WW
-      objectClass: referral
-      objectClass: extensibleObject
-
-   The first referral object provides the server with the knowledge that
-   subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one
-   is the master and the other a shadow).  The second referral object
-   provides the server with the knowledge that the subtree
-   "OU=Roles,O=MNN,C=WW" is held by hostd.
-
-   Also, in the context of this document, the "nearest naming context"
-   means the deepest context which the object is within.  That is, if
-   the object is within multiple naming contexts, the nearest naming
-   context is the one which is subordinate to all other naming contexts
-   the object is within.
-
-5.2.  Target Object Considerations
-
-   This section details referral handling for add, compare, delete,
-   modify, and modify DN operations.  If the client requests any of
-   these operations, there are four cases that the server must handle
-   with respect to the target object.
-
-   The DN part MUST be modified such that it refers to the appropriate
-   target in the referenced server (as detailed below).  Even where the
-   DN to be returned is the same as the target DN, the DN part SHOULD
-   NOT be trimmed.
-
-   In cases where the URI to be returned is a LDAP URL, the server
-   SHOULD trim any present scope, filter, or attribute list from the URI
-   before returning it.  Critical extensions MUST NOT be trimmed or
-   modified.
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   Case 1: The target object is not held by the server and is not within
-      or subordinate to any naming context nor subordinate to any
-      referral object held by the server.
-
-      The server SHOULD process the request normally as appropriate for
-      a non-existent base which is not within any naming context of the
-      server (generally return noSuchObject or a referral based upon
-      superior knowledge reference information).  This document does not
-      detail management or processing of superior knowledge reference
-      information.
-
-   Case 2: The target object is held by the server and is a referral
-      object.
-
-      The server SHOULD return the URI value contained in the ref
-      attribute of the referral object appropriately modified as
-      described above.
-
-   Example: If the client issues a modify request for the target object
-      of "OU=People,O=MNN,c=WW", the server will return:
-
-         ModifyResponse (referral) {
-             ldap://hostb/OU=People,O=MNN,C=WW
-             ldap://hostc/OU=People,O=MNN,C=WW
-         }
-
-   Case 3: The target object is not held by the server, but the nearest
-      naming context contains no referral object which the target object
-      is subordinate to.
-
-      If the nearest naming context contains no referral object which
-      the target is subordinate to, the server SHOULD process the
-      request as appropriate for a nonexistent target (generally return
-      noSuchObject).
-
-   Case 4: The target object is not held by the server, but the nearest
-      naming context contains a referral object which the target object
-      is subordinate to.
-
-      If a client requests an operation for which the target object is
-      not held by the server and the nearest naming context contains a
-      referral object which the target object is subordinate to, the
-      server SHOULD return a referral response constructed from the URI
-      portion of the ref value of the referral object.
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 7]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   Example: If the client issues an add request where the target object
-      has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
-      return:
-
-         AddResponse (referral) {
-             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
-         }
-
-      Note that the DN part of the LDAP URL is modified such that it
-      refers to the appropriate entry in the referenced server.
-
-5.3.  Base Object Considerations
-
-   This section details referral handling for base object processing
-   within search operations.  Like target object considerations for
-   non-search operations, there are the four cases.
-
-   In cases where the URI to be returned is a LDAP URL, the server MUST
-   provide an explicit scope specifier from the LDAP URL prior to
-   returning it.  In addition, the DN part MUST be modified such that it
-   refers to the appropriate target in the referenced server (as
-   detailed below).
-
-   If aliasing dereferencing was necessary in finding the referral
-   object, the DN part of the URI MUST be replaced with the base DN as
-   modified by the alias dereferencing such that the return URL refers
-   to the new target object per [RFC2251, 4.1.11].
-
-   Critical extensions MUST NOT be trimmed nor modified.
-
-   Case 1: The base object is not held by the server and is not within
-      nor subordinate to any naming context held by the server.
-
-      The server SHOULD process the request normally as appropriate for
-      a non-existent base which not within any naming context of the
-      server (generally return a superior referral or noSuchObject).
-      This document does not detail management or processing of superior
-      knowledge references.
-
-   Case 2: The base object is held by the server and is a referral
-      object.
-
-      The server SHOULD return the URI value contained in the ref
-      attribute of the referral object appropriately modified as
-      described above.
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 8]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-   Example: If the client issues a subtree search in which the base
-      object is "OU=Roles,O=MNN,C=WW", the server will return
-
-         SearchResultDone (referral) {
-             ldap://hostd/OU=Roles,O=MNN,C=WW??sub
-         }
-
-      If the client were to issue a base or oneLevel search instead of
-      subtree, the returned LDAP URL would explicitly specify "base" or
-      "one", respectively, instead of "sub".
-
-   Case 3: The base object is not held by the server, but the nearest
-      naming context contains no referral object which the base object
-      is subordinate to.
-
-      If the nearest naming context contains no referral object which
-      the base is subordinate to, the request SHOULD be processed
-      normally as appropriate for a nonexistent base (generally return
-      noSuchObject).
-
-   Case 4: The base object is not held by the server, but the nearest
-      naming context contains a referral object which the base object is
-      subordinate to.
-
-      If a client requests an operation for which the target object is
-      not held by the server and the nearest naming context contains a
-      referral object which the target object is subordinate to, the
-      server SHOULD return a referral response which is constructed from
-      the URI portion of the ref value of the referral object.
-
-   Example: If the client issues a base search request for
-      "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return
-
-         SearchResultDone (referral) {
-             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
-         }
-
-      If the client were to issue a subtree or oneLevel search instead
-      of subtree, the returned LDAP URL would explicitly specify "sub"
-      or "one", respectively, instead of "base".
-
-      Note that the DN part of the LDAP URL is modified such that it
-      refers to the appropriate entry in the referenced server.
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 9]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-5.4.  Search Continuation Considerations
-
-   For search operations, once the base object has been found and
-   determined not to be a referral object, the search may progress.  Any
-   entry matching the filter and scope of the search which is not a
-   referral object is returned to the client normally as described in
-   [RFC2251].
-
-   For each referral object within the requested scope, regardless of
-   the search filter, the server SHOULD return a SearchResultReference
-   which is constructed from the URI component of values of the ref
-   attribute.  If the URI component is not a LDAP URL, it should be
-   returned as is.  If the LDAP URL's DN part is absent or empty, the DN
-   part must be modified to contain the DN of the referral object.  If
-   the URI component is a LDAP URL, the URI SHOULD be modified to add an
-   explicit scope specifier.
-
-   Subtree Example:
-
-      If a client requests a subtree search of "O=MNN,C=WW", then in
-      addition to any entries within scope which match the filter, hosta
-      will also return two search references as the two referral objects
-      are within scope.  One possible response might be:
-
-          SearchEntry for O=MNN,C=WW
-          SearchResultReference {
-              ldap://hostb/OU=People,O=MNN,C=WW??sub
-              ldap://hostc/OU=People,O=MNN,C=WW??sub
-          }
-          SearchEntry for CN=Manager,O=MNN,C=WW
-          SearchResultReference {
-              ldap://hostd/OU=Roles,O=MNN,C=WW??sub
-          }
-          SearchResultDone (success)
-
-   One Level Example:
-
-      If a client requests a one level search of "O=MNN,C=WW" then, in
-      addition to any entries one level below the "O=MNN,C=WW" entry
-      matching the filter, the server will also return two search
-      references as the two referral objects are within scope.  One
-      possible sequence is shown:
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 10]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-          SearchResultReference {
-              ldap://hostb/OU=People,O=MNN,C=WW??base
-              ldap://hostc/OU=People,O=MNN,C=WW??base
-          }
-          SearchEntry for CN=Manager,O=MNN,C=WW
-          SearchResultReference {
-              ldap://hostd/OU=Roles,O=MNN,C=WW??base
-          }
-          SearchResultDone (success)
-
-   Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
-      URLs returned with the SearchResultReference messages contain, as
-      required by this specification, an explicit scope specifier.
-
-5.6.  Other Considerations
-
-   This section details processing considerations for other operations.
-
-5.6.1 Bind
-
-   Servers SHOULD NOT return referral result code if the bind name (or
-   authentication identity or authorization identity) is (or is
-   subordinate to) a referral object but MAY use the knowledge
-   information to process the bind request (such as in support a future
-   distributed operation specification).  Where the server makes no use
-   of the knowledge information, the server processes the request
-   normally as appropriate for a non-existent authentication or
-   authorization identity (e.g., return invalidCredentials).
-
-5.6.2 Modify DN
-
-   If the newSuperior is a referral object or is subordinate to a
-   referral object, the server SHOULD return affectsMultipleDSAs.  If
-   the newRDN already exists but is a referral object, the server SHOULD
-   return affectsMultipleDSAs instead of entryAlreadyExists.
-
-6.  Security Considerations
-
-   This document defines mechanisms that can be used to tie LDAP (and
-   other) servers together.  The information used to tie services
-   together should be protected from unauthorized modification.  If the
-   server topology information is not public information, it should be
-   protected from unauthorized disclosure as well.
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 11]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-7.  Acknowledgments
-
-   This document borrows heavily from previous work by IETF LDAPext
-   Working Group.  In particular, this document is based upon "Named
-   Referral in LDAP Directories" (an expired Internet Draft) by
-   Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
-   Mark Wahl.
-
-8. Normative References
-
-   [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
-             Object Class to Hold Uniform Resource Identifiers (URIs)",
-             RFC 2079, January 1997.
-
-   [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
-             Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
-             Access Protocol (v3)", RFC 2251, December 1997.
-
-   [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
-             "Lightweight Directory Access Protocol (v3): Attribute
-             Syntax Definitions", RFC 2252, December 1997.
-
-   [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
-             Access Protocol (v3): UTF-8 String Representation of
-             Distinguished Names", RFC 2253, December 1997.
-
-   [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
-             December, 1997.
-
-   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
-             Resource Identifiers (URI): Generic Syntax", RFC 2396,
-             August 1998.
-
-   [X.501]   ITU-T, "The Directory: Models", X.501, 1993.
-
-9. Informative References
-
-   [X.500]   ITU-T, "The Directory: Overview of Concepts, Models, and
-             Services", X.500, 1993.
-
-   [X.511]   ITU-T, "The Directory: Abstract Service Definition", X.500,
-             1997.
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 12]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-10.  Author's Address
-
-   Kurt D. Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 13]
-
-RFC 3296    Named Subordinate References in LDAP Directories   July 2002
-
-
-11.  Full Copyright Statement
-
-   Copyright (C) The Internet Society (2002).  All Rights Reserved.
-
-   This document and translations of it may be copied and furnished to
-   others, and derivative works that comment on or otherwise explain it
-   or assist in its implementation may be prepared, copied, published
-   and distributed, in whole or in part, without restriction of any
-   kind, provided that the above copyright notice and this paragraph are
-   included on all such copies and derivative works.  However, this
-   document itself may not be modified in any way, such as by removing
-   the copyright notice or references to the Internet Society or other
-   Internet organizations, except as needed for the purpose of
-   developing Internet standards in which case the procedures for
-   copyrights defined in the Internet Standards process must be
-   followed, or as required to translate it into languages other than
-   English.
-
-   The limited permissions granted above are perpetual and will not be
-   revoked by the Internet Society or its successors or assigns.
-
-   This document and the information contained herein is provided on an
-   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
-   TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is currently provided by the
-   Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 14]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4510.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4510.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4510.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   K. Zeilenga, Ed.
-Request for Comments: 4510                           OpenLDAP Foundation
-Obsoletes: 2251, 2252, 2253, 2254, 2255,                       June 2006
-           2256, 2829, 2830, 3377, 3771
-Category: Standards Track
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                    Technical Specification Road Map
-
-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 Lightweight Directory Access Protocol (LDAP) is an Internet
-   protocol for accessing distributed directory services that act in
-   accordance with X.500 data and service models.  This document
-   provides a road map of the LDAP Technical Specification.
-
-1.  The LDAP Technical Specification
-
-   The technical specification detailing version 3 of the Lightweight
-   Directory Access Protocol (LDAP), an Internet Protocol, consists of
-   this document and the following documents:
-
-      LDAP: The Protocol [RFC4511]
-      LDAP: Directory Information Models [RFC4512]
-      LDAP: Authentication Methods and Security Mechanisms [RFC4513]
-      LDAP: String Representation of Distinguished Names [RFC4514]
-      LDAP: String Representation of Search Filters [RFC4515]
-      LDAP: Uniform Resource Locator [RFC4516]
-      LDAP: Syntaxes and Matching Rules [RFC4517]
-      LDAP: Internationalized String Preparation [RFC4518]
-      LDAP: Schema for User Applications [RFC4519]
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4510                   LDAP: TS Road Map                   June 2006
-
-
-   The terms "LDAP" and "LDAPv3" are commonly used to refer informally
-   to the protocol specified by this technical specification.  The LDAP
-   suite, as defined here, should be formally identified in other
-   documents by a normative reference to this document.
-
-   LDAP is an extensible protocol.  Extensions to LDAP may be specified
-   in other documents.  Nomenclature denoting such combinations of
-   LDAP-plus-extensions is not defined by this document but may be
-   defined in some future document(s).  Extensions are expected to be
-   truly optional.  Considerations for the LDAP extensions described in
-   BCP 118, RFC 4521 [RFC4521] fully apply to this revision of the LDAP
-   Technical Specification.
-
-   IANA (Internet Assigned Numbers Authority) considerations for LDAP
-   described in BCP 64, RFC 4520 [RFC4520] apply fully to this revision
-   of the LDAP technical specification.
-
-1.1.  Conventions
-
-   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].
-
-2.  Relationship to X.500
-
-   This technical specification defines LDAP in terms of [X.500] as an
-   X.500 access mechanism.  An LDAP server MUST act in accordance with
-   the X.500 (1993) series of International Telecommunication Union -
-   Telecommunication Standardization (ITU-T) Recommendations when
-   providing the service.  However, it is not required that an LDAP
-   server make use of any X.500 protocols in providing this service.
-   For example, LDAP can be mapped onto any other directory system so
-   long as the X.500 data and service models [X.501][X.511], as used in
-   LDAP, are not violated in the LDAP interface.
-
-   This technical specification explicitly incorporates portions of
-   X.500(93).  Later revisions of X.500 do not automatically apply to
-   this technical specification.
-
-3.  Relationship to Obsolete Specifications
-
-   This technical specification, as defined in Section 1, obsoletes
-   entirely the previously defined LDAP technical specification defined
-   in RFC 3377 (and consisting of RFCs 2251-2256, 2829, 2830, 3771, and
-   3377 itself).  The technical specification was significantly
-   reorganized.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4510                   LDAP: TS Road Map                   June 2006
-
-
-   This document replaces RFC 3377 as well as Section 3.3 of RFC 2251.
-   [RFC4512] replaces portions of RFC 2251, RFC 2252, and RFC 2256.
-   [RFC4511] replaces the majority RFC 2251, portions of RFC 2252, and
-   all of RFC 3771.  [RFC4513] replaces RFC 2829, RFC 2830, and portions
-   of RFC 2251.  [RFC4517] replaces the majority of RFC 2252 and
-   portions of RFC 2256.  [RFC4519] replaces the majority of RFC 2256.
-   [RFC4514] replaces RFC 2253.  [RFC4515] replaces RFC 2254.  [RFC4516]
-   replaces RFC 2255.
-
-   [RFC4518] is new to this revision of the LDAP technical
-   specification.
-
-   Each document of this specification contains appendices summarizing
-   changes to all sections of the specifications they replace.  Appendix
-   A.1 of this document details changes made to RFC 3377.  Appendix A.2
-   of this document details changes made to Section 3.3 of RFC 2251.
-
-   Additionally, portions of this technical specification update and/or
-   replace a number of other documents not listed above.  These
-   relationships are discussed in the documents detailing these portions
-   of this technical specification.
-
-4.  Security Considerations
-
-   LDAP security considerations are discussed in each document
-   comprising the technical specification.
-
-5.  Acknowledgements
-
-   This document is based largely on RFC 3377 by J. Hodges and R.
-   Morgan, a product of the LDAPBIS and LDAPEXT Working Groups.  The
-   document also borrows from RFC 2251 by M. Wahl, T. Howes, and S.
-   Kille, a product of the ASID Working Group.
-
-   This document is a product of the IETF LDAPBIS Working Group.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4510                   LDAP: TS Road Map                   June 2006
-
-
-6.  Normative References
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
-                 (LDAP): Directory Information Models", RFC 4512, June
-                 2006.
-
-   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Authentication Methods and Security
-                 Mechanisms", RFC 4513, June 2006.
-
-   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): String Representation of Distinguished
-                 Names", RFC 4514, June 2006.
-
-   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): String Representation of Search
-                 Filters", RFC 4515, June 2006.
-
-   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): Uniform Resource Locator", RFC
-                 4516, June 2006.
-
-   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
-                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                 2006.
-
-   [RFC4518]     Zeilenga, K., "Lightweight Directory Access Protocol
-                 (LDAP): Internationalized String Preparation", RFC
-                 4518, June 2006.
-
-   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Schema for User Applications", RFC
-                 4519, June 2006.
-
-   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
-                 (IANA) Considerations for the Lightweight Directory
-                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-   [RFC4521]     Zeilenga, K., "Considerations for LDAP Extensions", BCP
-                 118, RFC 4521, June 2006.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4510                   LDAP: TS Road Map                   June 2006
-
-
-   [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.511]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory: Abstract Service Definition", X.511(1993)
-                 (also ISO/IEC 9594-3:1993).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4510                   LDAP: TS Road Map                   June 2006
-
-
-Appendix A.  Changes to Previous Documents
-
-   This appendix outlines changes this document makes relative to the
-   documents it replaces (in whole or in part).
-
-A.1. Changes to RFC 3377
-
-   This document is nearly a complete rewrite of RFC 3377 as much of the
-   material of RFC 3377 is no longer applicable.  The changes include
-   redefining the terms "LDAP" and "LDAPv3" to refer to this revision of
-   the technical specification.
-
-A.2. Changes to Section 3.3 of RFC 2251
-
-   The section was modified slightly (the word "document" was replaced
-   with "technical specification") to clarify that it applies to the
-   entire LDAP technical specification.
-
-Author's Address
-
-   Kurt D. Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
-RFC 4510                   LDAP: TS Road Map                   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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 7]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4511.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4511.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4511.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,3811 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                J. Sermersheim, Ed.
-Request for Comments: 4511                                  Novell, Inc.
-Obsoletes: 2251, 2830, 3771                                    June 2006
-Category: Standards Track
-
-
-      Lightweight Directory Access Protocol (LDAP): The Protocol
-
-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
-
-   This document describes the protocol elements, along with their
-   semantics and encodings, of the Lightweight Directory Access Protocol
-   (LDAP).  LDAP provides access to distributed directory services that
-   act in accordance with X.500 data and service models.  These protocol
-   elements are based on those described in the X.500 Directory Access
-   Protocol (DAP).
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. Relationship to Other LDAP Specifications ..................3
-   2. Conventions .....................................................3
-   3. Protocol Model ..................................................4
-      3.1. Operation and LDAP Message Layer Relationship ..............5
-   4. Elements of Protocol ............................................5
-      4.1. Common Elements ............................................5
-           4.1.1. Message Envelope ....................................6
-           4.1.2. String Types ........................................7
-           4.1.3. Distinguished Name and Relative Distinguished Name ..8
-           4.1.4. Attribute Descriptions ..............................8
-           4.1.5. Attribute Value .....................................8
-           4.1.6. Attribute Value Assertion ...........................9
-           4.1.7. Attribute and PartialAttribute ......................9
-           4.1.8. Matching Rule Identifier ...........................10
-           4.1.9. Result Message .....................................10
-           4.1.10. Referral ..........................................12
-
-
-
-Sermersheim                 Standards Track                     [Page 1]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-           4.1.11. Controls ..........................................14
-      4.2. Bind Operation ............................................16
-           4.2.1. Processing of the Bind Request .....................17
-           4.2.2. Bind Response ......................................18
-      4.3. Unbind Operation ..........................................18
-      4.4. Unsolicited Notification ..................................19
-           4.4.1. Notice of Disconnection ............................19
-      4.5. Search Operation ..........................................20
-           4.5.1. Search Request .....................................20
-           4.5.2. Search Result ......................................27
-           4.5.3. Continuation References in the Search Result .......28
-      4.6. Modify Operation ..........................................31
-      4.7. Add Operation .............................................33
-      4.8. Delete Operation ..........................................34
-      4.9. Modify DN Operation .......................................34
-      4.10. Compare Operation ........................................36
-      4.11. Abandon Operation ........................................36
-      4.12. Extended Operation .......................................37
-      4.13. IntermediateResponse Message .............................39
-           4.13.1. Usage with LDAP ExtendedRequest and
-                   ExtendedResponse ..................................40
-           4.13.2. Usage with LDAP Request Controls ..................40
-      4.14. StartTLS Operation .......................................40
-           4.14.1. StartTLS Request ..................................40
-           4.14.2. StartTLS Response .................................41
-           4.14.3. Removal of the TLS Layer ..........................41
-   5. Protocol Encoding, Connection, and Transfer ....................42
-      5.1. Protocol Encoding .........................................42
-      5.2. Transmission Control Protocol (TCP) .......................43
-      5.3. Termination of the LDAP session ...........................43
-   6. Security Considerations ........................................43
-   7. Acknowledgements ...............................................45
-   8. Normative References ...........................................46
-   9. Informative References .........................................48
-   10. IANA Considerations ...........................................48
-   Appendix A. LDAP Result Codes .....................................49
-      A.1. Non-Error Result Codes ....................................49
-      A.2. Result Codes ..............................................49
-   Appendix B. Complete ASN.1 Definition .............................54
-   Appendix C. Changes ...............................................60
-      C.1. Changes Made to RFC 2251 ..................................60
-      C.2. Changes Made to RFC 2830 ..................................66
-      C.3. Changes Made to RFC 3771 ..................................66
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                     [Page 2]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-1.  Introduction
-
-   The Directory is "a collection of open systems cooperating to provide
-   directory services" [X.500].  A directory user, which may be a human
-   or other entity, accesses the Directory through a client (or
-   Directory User Agent (DUA)).  The client, on behalf of the directory
-   user, interacts with one or more servers (or Directory System Agents
-   (DSA)).  Clients interact with servers using a directory access
-   protocol.
-
-   This document details the protocol elements of the Lightweight
-   Directory Access Protocol (LDAP), along with their semantics.
-   Following the description of protocol elements, it describes the way
-   in which the protocol elements are encoded and transferred.
-
-1.1.  Relationship to Other LDAP Specifications
-
-   This document is an integral part of the LDAP Technical Specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.
-
-   This document, together with [RFC4510], [RFC4513], and [RFC4512],
-   obsoletes RFC 2251 in its entirety.  Section 3.3 is obsoleted by
-   [RFC4510].  Sections 4.2.1 (portions) and 4.2.2 are obsoleted by
-   [RFC4513].  Sections 3.2, 3.4, 4.1.3 (last paragraph), 4.1.4, 4.1.5,
-   4.1.5.1, 4.1.9 (last paragraph), 5.1, 6.1, and 6.2 (last paragraph)
-   are obsoleted by [RFC4512].  The remainder of RFC 2251 is obsoleted
-   by this document.  Appendix C.1 summarizes substantive changes in the
-   remainder.
-
-   This document obsoletes RFC 2830, Sections 2 and 4.  The remainder of
-   RFC 2830 is obsoleted by [RFC4513].  Appendix C.2 summarizes
-   substantive changes to the remaining sections.
-
-   This document also obsoletes RFC 3771 in entirety.
-
-2.  Conventions
-
-   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
-   to be interpreted as described in [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>.
-
-
-
-
-
-
-Sermersheim                 Standards Track                     [Page 3]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   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 "transport connection" refers to the underlying transport
-   services used to carry the protocol exchange, as well as associations
-   established by these services.
-
-   The term "TLS layer" refers to Transport Layer Security (TLS)
-   services used in providing security services, as well as associations
-   established by these services.
-
-   The term "SASL layer" refers to Simply Authentication and Security
-   Layer (SASL) services used in providing security services, as well as
-   associations established by these services.
-
-   The term "LDAP message layer" refers to the LDAP Message Protocol
-   Data Unit (PDU) services used in providing directory services, as
-   well as associations established by these services.
-
-   The term "LDAP session" refers to combined services (transport
-   connection, TLS layer, SASL layer, LDAP message layer) and their
-   associations.
-
-   See the table in Section 5 for an illustration of these four terms.
-
-3.  Protocol Model
-
-   The general model adopted by this protocol is one of clients
-   performing protocol operations against servers.  In this model, a
-   client transmits a protocol request describing the operation to be
-   performed to a server.  The server is then responsible for performing
-   the necessary operation(s) in the Directory.  Upon completion of an
-   operation, the server typically returns a response containing
-   appropriate data to the requesting client.
-
-   Protocol operations are generally independent of one another.  Each
-   operation is processed as an atomic action, leaving the directory in
-   a consistent state.
-
-   Although servers are required to return responses whenever such
-   responses are defined in the protocol, there is no requirement for
-   synchronous behavior on the part of either clients or servers.
-   Requests and responses for multiple operations generally may be
-   exchanged between a client and server in any order.  If required,
-   synchronous behavior may be controlled by client applications.
-
-
-
-
-
-Sermersheim                 Standards Track                     [Page 4]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The core protocol operations defined in this document can be mapped
-   to a subset of the X.500 (1993) Directory Abstract Service [X.511].
-   However, there is not a one-to-one mapping between LDAP operations
-   and X.500 Directory Access Protocol (DAP) operations.  Server
-   implementations acting as a gateway to X.500 directories may need to
-   make multiple DAP requests to service a single LDAP request.
-
-3.1.  Operation and LDAP Message Layer Relationship
-
-   Protocol operations are exchanged at the LDAP message layer.  When
-   the transport connection is closed, any uncompleted operations at the
-   LDAP message layer are abandoned (when possible) or are completed
-   without transmission of the response (when abandoning them is not
-   possible).  Also, when the transport connection is closed, the client
-   MUST NOT assume that any uncompleted update operations have succeeded
-   or failed.
-
-4.  Elements of Protocol
-
-   The protocol is described using Abstract Syntax Notation One
-   ([ASN.1]) and is transferred using a subset of ASN.1 Basic Encoding
-   Rules ([BER]).  Section 5 specifies how the protocol elements are
-   encoded and transferred.
-
-   In order to support future extensions to this protocol, extensibility
-   is implied where it is allowed per ASN.1 (i.e., sequence, set,
-   choice, and enumerated types are extensible).  In addition, ellipses
-   (...) have been supplied in ASN.1 types that are explicitly
-   extensible as discussed in [RFC4520].  Because of the implied
-   extensibility, clients and servers MUST (unless otherwise specified)
-   ignore trailing SEQUENCE components whose tags they do not recognize.
-
-   Changes to the protocol other than through the extension mechanisms
-   described here require a different version number.  A client
-   indicates the version it is using as part of the BindRequest,
-   described in Section 4.2.  If a client has not sent a Bind, the
-   server MUST assume the client is using version 3 or later.
-
-   Clients may attempt to determine the protocol versions a server
-   supports by reading the 'supportedLDAPVersion' attribute from the
-   root DSE (DSA-Specific Entry) [RFC4512].
-
-4.1.  Common Elements
-
-   This section describes the LDAPMessage envelope Protocol Data Unit
-   (PDU) format, as well as data type definitions, which are used in the
-   protocol operations.
-
-
-
-
-Sermersheim                 Standards Track                     [Page 5]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.1.1.  Message Envelope
-
-   For the purposes of protocol exchanges, all protocol operations are
-   encapsulated in a common envelope, the LDAPMessage, which is defined
-   as follows:
-
-        LDAPMessage ::= SEQUENCE {
-             messageID       MessageID,
-             protocolOp      CHOICE {
-                  bindRequest           BindRequest,
-                  bindResponse          BindResponse,
-                  unbindRequest         UnbindRequest,
-                  searchRequest         SearchRequest,
-                  searchResEntry        SearchResultEntry,
-                  searchResDone         SearchResultDone,
-                  searchResRef          SearchResultReference,
-                  modifyRequest         ModifyRequest,
-                  modifyResponse        ModifyResponse,
-                  addRequest            AddRequest,
-                  addResponse           AddResponse,
-                  delRequest            DelRequest,
-                  delResponse           DelResponse,
-                  modDNRequest          ModifyDNRequest,
-                  modDNResponse         ModifyDNResponse,
-                  compareRequest        CompareRequest,
-                  compareResponse       CompareResponse,
-                  abandonRequest        AbandonRequest,
-                  extendedReq           ExtendedRequest,
-                  extendedResp          ExtendedResponse,
-                  ...,
-                  intermediateResponse  IntermediateResponse },
-             controls       [0] Controls OPTIONAL }
-
-        MessageID ::= INTEGER (0 ..  maxInt)
-
-        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
-   The ASN.1 type Controls is defined in Section 4.1.11.
-
-   The function of the LDAPMessage is to provide an envelope containing
-   common fields required in all protocol exchanges.  At this time, the
-   only common fields are the messageID and the controls.
-
-   If the server receives an LDAPMessage from the client in which the
-   LDAPMessage SEQUENCE tag cannot be recognized, the messageID cannot
-   be parsed, the tag of the protocolOp is not recognized as a request,
-   or the encoding structures or lengths of data fields are found to be
-   incorrect, then the server SHOULD return the Notice of Disconnection
-
-
-
-Sermersheim                 Standards Track                     [Page 6]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   described in Section 4.4.1, with the resultCode set to protocolError,
-   and MUST immediately terminate the LDAP session as described in
-   Section 5.3.
-
-   In other cases where the client or server cannot parse an LDAP PDU,
-   it SHOULD abruptly terminate the LDAP session (Section 5.3) where
-   further communication (including providing notice) would be
-   pernicious.  Otherwise, server implementations MUST return an
-   appropriate response to the request, with the resultCode set to
-   protocolError.
-
-4.1.1.1.  MessageID
-
-   All LDAPMessage envelopes encapsulating responses contain the
-   messageID value of the corresponding request LDAPMessage.
-
-   The messageID of a request MUST have a non-zero value different from
-   the messageID of any other request in progress in the same LDAP
-   session.  The zero value is reserved for the unsolicited notification
-   message.
-
-   Typical clients increment a counter for each request.
-
-   A client MUST NOT send a request with the same messageID as an
-   earlier request in the same LDAP session unless it can be determined
-   that the server is no longer servicing the earlier request (e.g.,
-   after the final response is received, or a subsequent Bind
-   completes).  Otherwise, the behavior is undefined.  For this purpose,
-   note that Abandon and successfully abandoned operations do not send
-   responses.
-
-4.1.2.  String Types
-
-   The LDAPString is a notational convenience to indicate that, although
-   strings of LDAPString type encode as ASN.1 OCTET STRING types, the
-   [ISO10646] character set (a superset of [Unicode]) is used, encoded
-   following the UTF-8 [RFC3629] algorithm.  Note that Unicode
-   characters U+0000 through U+007F are the same as ASCII 0 through 127,
-   respectively, and have the same single octet UTF-8 encoding.  Other
-   Unicode characters have a multiple octet UTF-8 encoding.
-
-        LDAPString ::= OCTET STRING -- UTF-8 encoded,
-                                    -- [ISO10646] characters
-
-   The LDAPOID is a notational convenience to indicate that the
-   permitted value of this string is a (UTF-8 encoded) dotted-decimal
-   representation of an OBJECT IDENTIFIER.  Although an LDAPOID is
-
-
-
-
-Sermersheim                 Standards Track                     [Page 7]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   encoded as an OCTET STRING, values are limited to the definition of
-   <numericoid> given in Section 1.4 of [RFC4512].
-
-        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-                                 -- [RFC4512]
-
-   For example,
-
-        1.3.6.1.4.1.1466.1.2.3
-
-4.1.3.  Distinguished Name and Relative Distinguished Name
-
-   An LDAPDN is defined to be the representation of a Distinguished Name
-   (DN) after encoding according to the specification in [RFC4514].
-
-        LDAPDN ::= LDAPString
-                   -- Constrained to <distinguishedName> [RFC4514]
-
-   A RelativeLDAPDN is defined to be the representation of a Relative
-   Distinguished Name (RDN) after encoding according to the
-   specification in [RFC4514].
-
-        RelativeLDAPDN ::= LDAPString
-                           -- Constrained to <name-component> [RFC4514]
-
-4.1.4.  Attribute Descriptions
-
-   The definition and encoding rules for attribute descriptions are
-   defined in Section 2.5 of [RFC4512].  Briefly, an attribute
-   description is an attribute type and zero or more options.
-
-        AttributeDescription ::= LDAPString
-                                -- Constrained to <attributedescription>
-                                -- [RFC4512]
-
-4.1.5.  Attribute Value
-
-   A field of type AttributeValue is an OCTET STRING containing an
-   encoded attribute value.  The attribute value is encoded according to
-   the LDAP-specific encoding definition of its corresponding syntax.
-   The LDAP-specific encoding definitions for different syntaxes and
-   attribute types may be found in other documents and in particular
-   [RFC4517].
-
-        AttributeValue ::= OCTET STRING
-
-
-
-
-
-
-Sermersheim                 Standards Track                     [Page 8]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Note that there is no defined limit on the size of this encoding;
-   thus, protocol values may include multi-megabyte attribute values
-   (e.g., photographs).
-
-   Attribute values may be defined that have arbitrary and non-printable
-   syntax.  Implementations MUST NOT display or attempt to decode an
-   attribute value if its syntax is not known.  The implementation may
-   attempt to discover the subschema of the source entry and to retrieve
-   the descriptions of 'attributeTypes' from it [RFC4512].
-
-   Clients MUST only send attribute values in a request that are valid
-   according to the syntax defined for the attributes.
-
-4.1.6.  Attribute Value Assertion
-
-   The AttributeValueAssertion (AVA) type definition is similar to the
-   one in the X.500 Directory standards.  It contains an attribute
-   description and a matching rule ([RFC4512], Section 4.1.3) assertion
-   value suitable for that type.  Elements of this type are typically
-   used to assert that the value in assertionValue matches a value of an
-   attribute.
-
-        AttributeValueAssertion ::= SEQUENCE {
-             attributeDesc   AttributeDescription,
-             assertionValue  AssertionValue }
-
-        AssertionValue ::= OCTET STRING
-
-   The syntax of the AssertionValue depends on the context of the LDAP
-   operation being performed.  For example, the syntax of the EQUALITY
-   matching rule for an attribute is used when performing a Compare
-   operation.  Often this is the same syntax used for values of the
-   attribute type, but in some cases the assertion syntax differs from
-   the value syntax.  See objectIdentiferFirstComponentMatch in
-   [RFC4517] for an example.
-
-4.1.7.  Attribute and PartialAttribute
-
-   Attributes and partial attributes consist of an attribute description
-   and attribute values.  A PartialAttribute allows zero values, while
-   Attribute requires at least one value.
-
-        PartialAttribute ::= SEQUENCE {
-             type       AttributeDescription,
-             vals       SET OF value AttributeValue }
-
-
-
-
-
-
-Sermersheim                 Standards Track                     [Page 9]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-        Attribute ::= PartialAttribute(WITH COMPONENTS {
-             ...,
-             vals (SIZE(1..MAX))})
-
-   No two of the attribute values may be equivalent as described by
-   Section 2.2 of [RFC4512].  The set of attribute values is unordered.
-   Implementations MUST NOT rely upon the ordering being repeatable.
-
-4.1.8.  Matching Rule Identifier
-
-   Matching rules are defined in Section 4.1.3 of [RFC4512].  A matching
-   rule is identified in the protocol by the printable representation of
-   either its <numericoid> or one of its short name descriptors
-   [RFC4512], e.g., 'caseIgnoreMatch' or '2.5.13.2'.
-
-        MatchingRuleId ::= LDAPString
-
-4.1.9.  Result Message
-
-   The LDAPResult is the construct used in this protocol to return
-   success or failure indications from servers to clients.  To various
-   requests, servers will return responses containing the elements found
-   in LDAPResult to indicate the final status of the protocol operation
-   request.
-
-        LDAPResult ::= SEQUENCE {
-             resultCode         ENUMERATED {
-                  success                      (0),
-                  operationsError              (1),
-                  protocolError                (2),
-                  timeLimitExceeded            (3),
-                  sizeLimitExceeded            (4),
-                  compareFalse                 (5),
-                  compareTrue                  (6),
-                  authMethodNotSupported       (7),
-                  strongerAuthRequired         (8),
-                       -- 9 reserved --
-                  referral                     (10),
-                  adminLimitExceeded           (11),
-                  unavailableCriticalExtension (12),
-                  confidentialityRequired      (13),
-                  saslBindInProgress           (14),
-                  noSuchAttribute              (16),
-                  undefinedAttributeType       (17),
-                  inappropriateMatching        (18),
-                  constraintViolation          (19),
-                  attributeOrValueExists       (20),
-                  invalidAttributeSyntax       (21),
-
-
-
-Sermersheim                 Standards Track                    [Page 10]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-                       -- 22-31 unused --
-                  noSuchObject                 (32),
-                  aliasProblem                 (33),
-                  invalidDNSyntax              (34),
-                       -- 35 reserved for undefined isLeaf --
-                  aliasDereferencingProblem    (36),
-                       -- 37-47 unused --
-                  inappropriateAuthentication  (48),
-                  invalidCredentials           (49),
-                  insufficientAccessRights     (50),
-                  busy                         (51),
-                  unavailable                  (52),
-                  unwillingToPerform           (53),
-                  loopDetect                   (54),
-                       -- 55-63 unused --
-                  namingViolation              (64),
-                  objectClassViolation         (65),
-                  notAllowedOnNonLeaf          (66),
-                  notAllowedOnRDN              (67),
-                  entryAlreadyExists           (68),
-                  objectClassModsProhibited    (69),
-                       -- 70 reserved for CLDAP --
-                  affectsMultipleDSAs          (71),
-                       -- 72-79 unused --
-                  other                        (80),
-                  ...  },
-             matchedDN          LDAPDN,
-             diagnosticMessage  LDAPString,
-             referral           [3] Referral OPTIONAL }
-
-   The resultCode enumeration is extensible as defined in Section 3.8 of
-   [RFC4520].  The meanings of the listed result codes are given in
-   Appendix A.  If a server detects multiple errors for an operation,
-   only one result code is returned.  The server should return the
-   result code that best indicates the nature of the error encountered.
-   Servers may return substituted result codes to prevent unauthorized
-   disclosures.
-
-   The diagnosticMessage field of this construct may, at the server's
-   option, be used to return a string containing a textual, human-
-   readable diagnostic message (terminal control and page formatting
-   characters should be avoided).  As this diagnostic message is not
-   standardized, implementations MUST NOT rely on the values returned.
-   Diagnostic messages typically supplement the resultCode with
-   additional information.  If the server chooses not to return a
-   textual diagnostic, the diagnosticMessage field MUST be empty.
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 11]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   For certain result codes (typically, but not restricted to
-   noSuchObject, aliasProblem, invalidDNSyntax, and
-   aliasDereferencingProblem), the matchedDN field is set (subject to
-   access controls) to the name of the last entry (object or alias) used
-   in finding the target (or base) object.  This will be a truncated
-   form of the provided name or, if an alias was dereferenced while
-   attempting to locate the entry, of the resulting name.  Otherwise,
-   the matchedDN field is empty.
-
-4.1.10.  Referral
-
-   The referral result code indicates that the contacted server cannot
-   or will not perform the operation and that one or more other servers
-   may be able to.  Reasons for this include:
-
-   - The target entry of the request is not held locally, but the server
-     has knowledge of its possible existence elsewhere.
-
-   - The operation is restricted on this server -- perhaps due to a
-     read-only copy of an entry to be modified.
-
-   The referral field is present in an LDAPResult if the resultCode is
-   set to referral, and it is absent with all other result codes.  It
-   contains one or more references to one or more servers or services
-   that may be accessed via LDAP or other protocols.  Referrals can be
-   returned in response to any operation request (except Unbind and
-   Abandon, which do not have responses).  At least one URI MUST be
-   present in the Referral.
-
-   During a Search operation, after the baseObject is located, and
-   entries are being evaluated, the referral is not returned.  Instead,
-   continuation references, described in Section 4.5.3, are returned
-   when other servers would need to be contacted to complete the
-   operation.
-
-        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-        URI ::= LDAPString     -- limited to characters permitted in
-                               -- URIs
-
-   If the client wishes to progress the operation, it contacts one of
-   the supported services found in the referral.  If multiple URIs are
-   present, the client assumes that any supported URI may be used to
-   progress the operation.
-
-   Clients that follow referrals MUST ensure that they do not loop
-   between servers.  They MUST NOT repeatedly contact the same server
-   for the same request with the same parameters.  Some clients use a
-
-
-
-Sermersheim                 Standards Track                    [Page 12]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   counter that is incremented each time referral handling occurs for an
-   operation, and these kinds of clients MUST be able to handle at least
-   ten nested referrals while progressing the operation.
-
-   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
-   v6) [RFC793][RFC791] is written as an LDAP URL according to
-   [RFC4516].
-
-   Referral values that are LDAP URLs follow these rules:
-
-   - If an alias was dereferenced, the <dn> part of the LDAP URL MUST be
-     present, with the new target object name.
-
-   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.
-
-   - If the <dn> part is present, the client uses this name in its next
-     request to progress the operation, and if it is not present the
-     client uses the same name as in the original request.
-
-   - Some servers (e.g., participating in distributed indexing) may
-     provide a different filter in a URL of a referral for a Search
-     operation.
-
-   - If the <filter> part of the LDAP URL is present, the client uses
-     this filter in its next request to progress this Search, and if it
-     is not present the client uses the same filter as it used for that
-     Search.
-
-   - For Search, it is RECOMMENDED that the <scope> part be present to
-     avoid ambiguity.
-
-   - If the <scope> part is missing, the scope of the original Search is
-     used by the client to progress the operation.
-
-   - Other aspects of the new request may be the same as or different
-     from the request that generated the referral.
-
-   Other kinds of URIs may be returned.  The syntax and semantics of
-   such URIs is left to future specifications.  Clients may ignore URIs
-   that they do not support.
-
-   UTF-8 encoded characters appearing in the string representation of a
-   DN, search filter, or other fields of the referral value may not be
-   legal for URIs (e.g., spaces) and MUST be escaped using the % method
-   in [RFC3986].
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 13]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.1.11.  Controls
-
-   Controls provide a mechanism whereby the semantics and arguments of
-   existing LDAP operations may be extended.  One or more controls may
-   be attached to a single LDAP message.  A control only affects the
-   semantics of the message it is attached to.
-
-   Controls sent by clients are termed 'request controls', and those
-   sent by servers are termed 'response controls'.
-
-        Controls ::= SEQUENCE OF control Control
-
-        Control ::= SEQUENCE {
-             controlType             LDAPOID,
-             criticality             BOOLEAN DEFAULT FALSE,
-             controlValue            OCTET STRING OPTIONAL }
-
-   The controlType field is the dotted-decimal representation of an
-   OBJECT IDENTIFIER that uniquely identifies the control.  This
-   provides unambiguous naming of controls.  Often, response control(s)
-   solicited by a request control share controlType values with the
-   request control.
-
-   The criticality field only has meaning in controls attached to
-   request messages (except UnbindRequest).  For controls attached to
-   response messages and the UnbindRequest, the criticality field SHOULD
-   be FALSE, and MUST be ignored by the receiving protocol peer.  A
-   value of TRUE indicates that it is unacceptable to perform the
-   operation without applying the semantics of the control.
-   Specifically, the criticality field is applied as follows:
-
-   - If the server does not recognize the control type, determines that
-     it is not appropriate for the operation, or is otherwise unwilling
-     to perform the operation with the control, and if the criticality
-     field is TRUE, the server MUST NOT perform the operation, and for
-     operations that have a response message, it MUST return with the
-     resultCode set to unavailableCriticalExtension.
-
-   - If the server does not recognize the control type, determines that
-     it is not appropriate for the operation, or is otherwise unwilling
-     to perform the operation with the control, and if the criticality
-     field is FALSE, the server MUST ignore the control.
-
-   - Regardless of criticality, if a control is applied to an
-     operation, it is applied consistently and impartially to the
-     entire operation.
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 14]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The controlValue may contain information associated with the
-   controlType.  Its format is defined by the specification of the
-   control.  Implementations MUST be prepared to handle arbitrary
-   contents of the controlValue octet string, including zero bytes.  It
-   is absent only if there is no value information that is associated
-   with a control of its type.  When a controlValue is defined in terms
-   of ASN.1, and BER-encoded according to Section 5.1, it also follows
-   the extensibility rules in Section 4.
-
-   Servers list the controlType of request controls they recognize in
-   the 'supportedControl' attribute in the root DSE (Section 5.1 of
-   [RFC4512]).
-
-   Controls SHOULD NOT be combined unless the semantics of the
-   combination has been specified.  The semantics of control
-   combinations, if specified, are generally found in the control
-   specification most recently published.  When a combination of
-   controls is encountered whose semantics are invalid, not specified
-   (or not known), the message is considered not well-formed; thus, the
-   operation fails with protocolError.  Controls with a criticality of
-   FALSE may be ignored in order to arrive at a valid combination.
-   Additionally, unless order-dependent semantics are given in a
-   specification, the order of a combination of controls in the SEQUENCE
-   is ignored.  Where the order is to be ignored but cannot be ignored
-   by the server, the message is considered not well-formed, and the
-   operation fails with protocolError.  Again, controls with a
-   criticality of FALSE may be ignored in order to arrive at a valid
-   combination.
-
-   This document does not specify any controls.  Controls may be
-   specified in other documents.  Documents detailing control extensions
-   are to provide for each control:
-
-   - the OBJECT IDENTIFIER assigned to the control,
-
-   - direction as to what value the sender should provide for the
-     criticality field (note: the semantics of the criticality field are
-     defined above should not be altered by the control's
-     specification),
-
-   - whether the controlValue field is present, and if so, the format of
-     its contents,
-
-   - the semantics of the control, and
-
-   - optionally, semantics regarding the combination of the control with
-     other controls.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 15]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.2.  Bind Operation
-
-   The function of the Bind operation is to allow authentication
-   information to be exchanged between the client and server.  The Bind
-   operation should be thought of as the "authenticate" operation.
-   Operational, authentication, and security-related semantics of this
-   operation are given in [RFC4513].
-
-   The Bind request is defined as follows:
-
-        BindRequest ::= [APPLICATION 0] SEQUENCE {
-             version                 INTEGER (1 ..  127),
-             name                    LDAPDN,
-             authentication          AuthenticationChoice }
-
-        AuthenticationChoice ::= CHOICE {
-             simple                  [0] OCTET STRING,
-                                     -- 1 and 2 reserved
-             sasl                    [3] SaslCredentials,
-             ...  }
-
-        SaslCredentials ::= SEQUENCE {
-             mechanism               LDAPString,
-             credentials             OCTET STRING OPTIONAL }
-
-   Fields of the BindRequest are:
-
-   - version: A version number indicating the version of the protocol to
-     be used at the LDAP message layer.  This document describes version
-     3 of the protocol.  There is no version negotiation.  The client
-     sets this field to the version it desires.  If the server does not
-     support the specified version, it MUST respond with a BindResponse
-     where the resultCode is set to protocolError.
-
-   - name: If not empty, the name of the Directory object that the
-     client wishes to bind as.  This field may take on a null value (a
-     zero-length string) for the purposes of anonymous binds ([RFC4513],
-     Section 5.1) or when using SASL [RFC4422] authentication
-     ([RFC4513], Section 5.2).  Where the server attempts to locate the
-     named object, it SHALL NOT perform alias dereferencing.
-
-   - authentication: Information used in authentication.  This type is
-     extensible as defined in Section 3.7 of [RFC4520].  Servers that do
-     not support a choice supplied by a client return a BindResponse
-     with the resultCode set to authMethodNotSupported.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 16]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-     Textual passwords (consisting of a character sequence with a known
-     character set and encoding) transferred to the server using the
-     simple AuthenticationChoice SHALL be transferred as UTF-8 [RFC3629]
-     encoded [Unicode].  Prior to transfer, clients SHOULD prepare text
-     passwords as "query" strings by applying the SASLprep [RFC4013]
-     profile of the stringprep [RFC3454] algorithm.  Passwords
-     consisting of other data (such as random octets) MUST NOT be
-     altered.  The determination of whether a password is textual is a
-     local client matter.
-
-4.2.1.  Processing of the Bind Request
-
-   Before processing a BindRequest, all uncompleted operations MUST
-   either complete or be abandoned.  The server may either wait for the
-   uncompleted operations to complete, or abandon them.  The server then
-   proceeds to authenticate the client in either a single-step or
-   multi-step Bind process.  Each step requires the server to return a
-   BindResponse to indicate the status of authentication.
-
-   After sending a BindRequest, clients MUST NOT send further LDAP PDUs
-   until receiving the BindResponse.  Similarly, servers SHOULD NOT
-   process or respond to requests received while processing a
-   BindRequest.
-
-   If the client did not bind before sending a request and receives an
-   operationsError to that request, it may then send a BindRequest.  If
-   this also fails or the client chooses not to bind on the existing
-   LDAP session, it may terminate the LDAP session, re-establish it, and
-   begin again by first sending a BindRequest.  This will aid in
-   interoperating with servers implementing other versions of LDAP.
-
-   Clients may send multiple Bind requests to change the authentication
-   and/or security associations or to complete a multi-stage Bind
-   process.  Authentication from earlier binds is subsequently ignored.
-
-   For some SASL authentication mechanisms, it may be necessary for the
-   client to invoke the BindRequest multiple times ([RFC4513], Section
-   5.2).  Clients MUST NOT invoke operations between two Bind requests
-   made as part of a multi-stage Bind.
-
-   A client may abort a SASL bind negotiation by sending a BindRequest
-   with a different value in the mechanism field of SaslCredentials, or
-   an AuthenticationChoice other than sasl.
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 17]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   If the client sends a BindRequest with the sasl mechanism field as an
-   empty string, the server MUST return a BindResponse with the
-   resultCode set to authMethodNotSupported.  This will allow the client
-   to abort a negotiation if it wishes to try again with the same SASL
-   mechanism.
-
-4.2.2.  Bind Response
-
-   The Bind response is defined as follows.
-
-        BindResponse ::= [APPLICATION 1] SEQUENCE {
-             COMPONENTS OF LDAPResult,
-             serverSaslCreds    [7] OCTET STRING OPTIONAL }
-
-   BindResponse consists simply of an indication from the server of the
-   status of the client's request for authentication.
-
-   A successful Bind operation is indicated by a BindResponse with a
-   resultCode set to success.  Otherwise, an appropriate result code is
-   set in the BindResponse.  For BindResponse, the protocolError result
-   code may be used to indicate that the version number supplied by the
-   client is unsupported.
-
-   If the client receives a BindResponse where the resultCode is set to
-   protocolError, it is to assume that the server does not support this
-   version of LDAP.  While the client may be able proceed with another
-   version of this protocol (which may or may not require closing and
-   re-establishing the transport connection), how to proceed with
-   another version of this protocol is beyond the scope of this
-   document.  Clients that are unable or unwilling to proceed SHOULD
-   terminate the LDAP session.
-
-   The serverSaslCreds field is used as part of a SASL-defined bind
-   mechanism to allow the client to authenticate the server to which it
-   is communicating, or to perform "challenge-response" authentication.
-   If the client bound with the simple choice, or the SASL mechanism
-   does not require the server to return information to the client, then
-   this field SHALL NOT be included in the BindResponse.
-
-4.3.  Unbind Operation
-
-   The function of the Unbind operation is to terminate an LDAP session.
-   The Unbind operation is not the antithesis of the Bind operation as
-   the name implies.  The naming of these operations are historical.
-   The Unbind operation should be thought of as the "quit" operation.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 18]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The Unbind operation is defined as follows:
-
-        UnbindRequest ::= [APPLICATION 2] NULL
-
-   The client, upon transmission of the UnbindRequest, and the server,
-   upon receipt of the UnbindRequest, are to gracefully terminate the
-   LDAP session as described in Section 5.3.  Uncompleted operations are
-   handled as specified in Section 3.1.
-
-4.4.  Unsolicited Notification
-
-   An unsolicited notification is an LDAPMessage sent from the server to
-   the client that is not in response to any LDAPMessage received by the
-   server.  It is used to signal an extraordinary condition in the
-   server or in the LDAP session between the client and the server.  The
-   notification is of an advisory nature, and the server will not expect
-   any response to be returned from the client.
-
-   The unsolicited notification is structured as an LDAPMessage in which
-   the messageID is zero and protocolOp is set to the extendedResp
-   choice using the ExtendedResponse type (See Section 4.12).  The
-   responseName field of the ExtendedResponse always contains an LDAPOID
-   that is unique for this notification.
-
-   One unsolicited notification (Notice of Disconnection) is defined in
-   this document.  The specification of an unsolicited notification
-   consists of:
-
-   - the OBJECT IDENTIFIER assigned to the notification (to be specified
-     in the responseName,
-
-   - the format of the contents of the responseValue (if any),
-
-   - the circumstances which will cause the notification to be sent, and
-
-   - the semantics of the message.
-
-4.4.1.  Notice of Disconnection
-
-   This notification may be used by the server to advise the client that
-   the server is about to terminate the LDAP session on its own
-   initiative.  This notification is intended to assist clients in
-   distinguishing between an exceptional server condition and a
-   transient network failure.  Note that this notification is not a
-   response to an Unbind requested by the client.  Uncompleted
-   operations are handled as specified in Section 3.1.
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 19]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The responseName is 1.3.6.1.4.1.1466.20036, the responseValue field
-   is absent, and the resultCode is used to indicate the reason for the
-   disconnection.  When the strongerAuthRequired resultCode is returned
-   with this message, it indicates that the server has detected that an
-   established security association between the client and server has
-   unexpectedly failed or been compromised.
-
-   Upon transmission of the Notice of Disconnection, the server
-   gracefully terminates the LDAP session as described in Section 5.3.
-
-4.5.  Search Operation
-
-   The Search operation is used to request a server to return, subject
-   to access controls and other restrictions, a set of entries matching
-   a complex search criterion.  This can be used to read attributes from
-   a single entry, from entries immediately subordinate to a particular
-   entry, or from a whole subtree of entries.
-
-4.5.1.  Search Request
-
-   The Search request is defined as follows:
-
-        SearchRequest ::= [APPLICATION 3] SEQUENCE {
-             baseObject      LDAPDN,
-             scope           ENUMERATED {
-                  baseObject              (0),
-                  singleLevel             (1),
-                  wholeSubtree            (2),
-                  ...  },
-             derefAliases    ENUMERATED {
-                  neverDerefAliases       (0),
-                  derefInSearching        (1),
-                  derefFindingBaseObj     (2),
-                  derefAlways             (3) },
-             sizeLimit       INTEGER (0 ..  maxInt),
-             timeLimit       INTEGER (0 ..  maxInt),
-             typesOnly       BOOLEAN,
-             filter          Filter,
-             attributes      AttributeSelection }
-
-        AttributeSelection ::= SEQUENCE OF selector LDAPString
-                        -- The LDAPString is constrained to
-                        -- <attributeSelector> in Section 4.5.1.8
-
-        Filter ::= CHOICE {
-             and             [0] SET SIZE (1..MAX) OF filter Filter,
-             or              [1] SET SIZE (1..MAX) OF filter Filter,
-             not             [2] Filter,
-
-
-
-Sermersheim                 Standards Track                    [Page 20]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-             equalityMatch   [3] AttributeValueAssertion,
-             substrings      [4] SubstringFilter,
-             greaterOrEqual  [5] AttributeValueAssertion,
-             lessOrEqual     [6] AttributeValueAssertion,
-             present         [7] AttributeDescription,
-             approxMatch     [8] AttributeValueAssertion,
-             extensibleMatch [9] MatchingRuleAssertion,
-             ...  }
-
-        SubstringFilter ::= SEQUENCE {
-             type           AttributeDescription,
-             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
-                  initial [0] AssertionValue,  -- can occur at most once
-                  any     [1] AssertionValue,
-                  final   [2] AssertionValue } -- can occur at most once
-             }
-
-        MatchingRuleAssertion ::= SEQUENCE {
-             matchingRule    [1] MatchingRuleId OPTIONAL,
-             type            [2] AttributeDescription OPTIONAL,
-             matchValue      [3] AssertionValue,
-             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
-
-   Note that an X.500 "list"-like operation can be emulated by the
-   client requesting a singleLevel Search operation with a filter
-   checking for the presence of the 'objectClass' attribute, and that an
-   X.500 "read"-like operation can be emulated by a baseObject Search
-   operation with the same filter.  A server that provides a gateway to
-   X.500 is not required to use the Read or List operations, although it
-   may choose to do so, and if it does, it must provide the same
-   semantics as the X.500 Search operation.
-
-4.5.1.1.  SearchRequest.baseObject
-
-   The name of the base object entry (or possibly the root) relative to
-   which the Search is to be performed.
-
-4.5.1.2.  SearchRequest.scope
-
-   Specifies the scope of the Search to be performed.  The semantics (as
-   described in [X.511]) of the defined values of this field are:
-
-      baseObject: The scope is constrained to the entry named by
-      baseObject.
-
-      singleLevel: The scope is constrained to the immediate
-      subordinates of the entry named by baseObject.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 21]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      wholeSubtree: The scope is constrained to the entry named by
-      baseObject and to all its subordinates.
-
-4.5.1.3.  SearchRequest.derefAliases
-
-   An indicator as to whether or not alias entries (as defined in
-   [RFC4512]) are to be dereferenced during stages of the Search
-   operation.
-
-   The act of dereferencing an alias includes recursively dereferencing
-   aliases that refer to aliases.
-
-   Servers MUST detect looping while dereferencing aliases in order to
-   prevent denial-of-service attacks of this nature.
-
-   The semantics of the defined values of this field are:
-
-      neverDerefAliases: Do not dereference aliases in searching or in
-      locating the base object of the Search.
-
-      derefInSearching: While searching subordinates of the base object,
-      dereference any alias within the search scope.  Dereferenced
-      objects become the vertices of further search scopes where the
-      Search operation is also applied.  If the search scope is
-      wholeSubtree, the Search continues in the subtree(s) of any
-      dereferenced object.  If the search scope is singleLevel, the
-      search is applied to any dereferenced objects and is not applied
-      to their subordinates.  Servers SHOULD eliminate duplicate entries
-      that arise due to alias dereferencing while searching.
-
-      derefFindingBaseObj: Dereference aliases in locating the base
-      object of the Search, but not when searching subordinates of the
-      base object.
-
-      derefAlways: Dereference aliases both in searching and in locating
-      the base object of the Search.
-
-4.5.1.4.  SearchRequest.sizeLimit
-
-   A size limit that restricts the maximum number of entries to be
-   returned as a result of the Search.  A value of zero in this field
-   indicates that no client-requested size limit restrictions are in
-   effect for the Search.  Servers may also enforce a maximum number of
-   entries to return.
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 22]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.5.1.5.  SearchRequest.timeLimit
-
-   A time limit that restricts the maximum time (in seconds) allowed for
-   a Search.  A value of zero in this field indicates that no client-
-   requested time limit restrictions are in effect for the Search.
-   Servers may also enforce a maximum time limit for the Search.
-
-4.5.1.6.  SearchRequest.typesOnly
-
-   An indicator as to whether Search results are to contain both
-   attribute descriptions and values, or just attribute descriptions.
-   Setting this field to TRUE causes only attribute descriptions (and
-   not values) to be returned.  Setting this field to FALSE causes both
-   attribute descriptions and values to be returned.
-
-4.5.1.7.  SearchRequest.filter
-
-   A filter that defines the conditions that must be fulfilled in order
-   for the Search to match a given entry.
-
-   The 'and', 'or', and 'not' choices can be used to form combinations
-   of filters.  At least one filter element MUST be present in an 'and'
-   or 'or' choice.  The others match against individual attribute values
-   of entries in the scope of the Search.  (Implementor's note: the
-   'not' filter is an example of a tagged choice in an implicitly-tagged
-   module.  In BER this is treated as if the tag were explicit.)
-
-   A server MUST evaluate filters according to the three-valued logic of
-   [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
-   "TRUE", "FALSE", or "Undefined".  If the filter evaluates to TRUE for
-   a particular entry, then the attributes of that entry are returned as
-   part of the Search result (subject to any applicable access control
-   restrictions).  If the filter evaluates to FALSE or Undefined, then
-   the entry is ignored for the Search.
-
-   A filter of the "and" choice is TRUE if all the filters in the SET OF
-   evaluate to TRUE, FALSE if at least one filter is FALSE, and
-   Undefined otherwise.  A filter of the "or" choice is FALSE if all the
-   filters in the SET OF evaluate to FALSE, TRUE if at least one filter
-   is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
-   TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
-   Undefined if it is Undefined.
-
-   A filter item evaluates to Undefined when the server would not be
-   able to determine whether the assertion value matches an entry.
-   Examples include:
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 23]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - An attribute description in an equalityMatch, substrings,
-     greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
-     is not recognized by the server.
-
-   - The attribute type does not define the appropriate matching rule.
-
-   - A MatchingRuleId in the extensibleMatch is not recognized by the
-     server or is not valid for the attribute type.
-
-   - The type of filtering requested is not implemented.
-
-   - The assertion value is invalid.
-
-   For example, if a server did not recognize the attribute type
-   shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
-   and (shoeSize<=12) would each evaluate to Undefined.
-
-   Servers MUST NOT return errors if attribute descriptions or matching
-   rule ids are not recognized, assertion values are invalid, or the
-   assertion syntax is not supported.  More details of filter processing
-   are given in Clause 7.8 of [X.511].
-
-4.5.1.7.1.  SearchRequest.filter.equalityMatch
-
-   The matching rule for an equalityMatch filter is defined by the
-   EQUALITY matching rule for the attribute type or subtype.  The filter
-   is TRUE when the EQUALITY rule returns TRUE as applied to the
-   attribute or subtype and the asserted value.
-
-4.5.1.7.2.  SearchRequest.filter.substrings
-
-   There SHALL be at most one 'initial' and at most one 'final' in the
-   'substrings' of a SubstringFilter.  If 'initial' is present, it SHALL
-   be the first element of 'substrings'.  If 'final' is present, it
-   SHALL be the last element of 'substrings'.
-
-   The matching rule for an AssertionValue in a substrings filter item
-   is defined by the SUBSTR matching rule for the attribute type or
-   subtype.  The filter is TRUE when the SUBSTR rule returns TRUE as
-   applied to the attribute or subtype and the asserted value.
-
-   Note that the AssertionValue in a substrings filter item conforms to
-   the assertion syntax of the EQUALITY matching rule for the attribute
-   type rather than to the assertion syntax of the SUBSTR matching rule
-   for the attribute type.  Conceptually, the entire SubstringFilter is
-   converted into an assertion value of the substrings matching rule
-   prior to applying the rule.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 24]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.5.1.7.3.  SearchRequest.filter.greaterOrEqual
-
-   The matching rule for a greaterOrEqual filter is defined by the
-   ORDERING matching rule for the attribute type or subtype.  The filter
-   is TRUE when the ORDERING rule returns FALSE as applied to the
-   attribute or subtype and the asserted value.
-
-4.5.1.7.4.  SearchRequest.filter.lessOrEqual
-
-   The matching rules for a lessOrEqual filter are defined by the
-   ORDERING and EQUALITY matching rules for the attribute type or
-   subtype.  The filter is TRUE when either the ORDERING or EQUALITY
-   rule returns TRUE as applied to the attribute or subtype and the
-   asserted value.
-
-4.5.1.7.5.  SearchRequest.filter.present
-
-   A present filter is TRUE when there is an attribute or subtype of the
-   specified attribute description present in an entry, FALSE when no
-   attribute or subtype of the specified attribute description is
-   present in an entry, and Undefined otherwise.
-
-4.5.1.7.6.  SearchRequest.filter.approxMatch
-
-   An approxMatch filter is TRUE when there is a value of the attribute
-   type or subtype for which some locally-defined approximate matching
-   algorithm (e.g., spelling variations, phonetic match, etc.) returns
-   TRUE.  If a value matches for equality, it also satisfies an
-   approximate match.  If approximate matching is not supported for the
-   attribute, this filter item should be treated as an equalityMatch.
-
-4.5.1.7.7.  SearchRequest.filter.extensibleMatch
-
-   The fields of the extensibleMatch filter item are evaluated as
-   follows:
-
-   - If the matchingRule field is absent, the type field MUST be
-     present, and an equality match is performed for that type.
-
-   - If the type field is absent and the matchingRule is present, the
-     matchValue is compared against all attributes in an entry that
-     support that matchingRule.
-
-   - If the type field is present and the matchingRule is present, the
-     matchValue is compared against the specified attribute type and its
-     subtypes.
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 25]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - If the dnAttributes field is set to TRUE, the match is additionally
-     applied against all the AttributeValueAssertions in an entry's
-     distinguished name, and it evaluates to TRUE if there is at least
-     one attribute or subtype in the distinguished name for which the
-     filter item evaluates to TRUE.  The dnAttributes field is present
-     to alleviate the need for multiple versions of generic matching
-     rules (such as word matching), where one applies to entries and
-     another applies to entries and DN attributes as well.
-
-   The matchingRule used for evaluation determines the syntax for the
-   assertion value.  Once the matchingRule and attribute(s) have been
-   determined, the filter item evaluates to TRUE if it matches at least
-   one attribute type or subtype in the entry, FALSE if it does not
-   match any attribute type or subtype in the entry, and Undefined if
-   the matchingRule is not recognized, the matchingRule is unsuitable
-   for use with the specified type, or the assertionValue is invalid.
-
-4.5.1.8.  SearchRequest.attributes
-
-   A selection list of the attributes to be returned from each entry
-   that matches the search filter.  Attributes that are subtypes of
-   listed attributes are implicitly included.  LDAPString values of this
-   field are constrained to the following Augmented Backus-Naur Form
-   (ABNF) [RFC4234]:
-
-      attributeSelector = attributedescription / selectorspecial
-
-      selectorspecial = noattrs / alluserattrs
-
-      noattrs = %x31.2E.31 ; "1.1"
-
-      alluserattrs = %x2A ; asterisk ("*")
-
-      The <attributedescription> production is defined in Section 2.5 of
-      [RFC4512].
-
-      There are three special cases that may appear in the attributes
-      selection list:
-
-      1. An empty list with no attributes requests the return of all
-         user attributes.
-
-      2. A list containing "*" (with zero or more attribute
-         descriptions) requests the return of all user attributes in
-         addition to other listed (operational) attributes.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 26]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      3. A list containing only the OID "1.1" indicates that no
-         attributes are to be returned.  If "1.1" is provided with other
-         attributeSelector values, the "1.1" attributeSelector is
-         ignored.  This OID was chosen because it does not (and can not)
-         correspond to any attribute in use.
-
-   Client implementors should note that even if all user attributes are
-   requested, some attributes and/or attribute values of the entry may
-   not be included in Search results due to access controls or other
-   restrictions.  Furthermore, servers will not return operational
-   attributes, such as objectClasses or attributeTypes, unless they are
-   listed by name.  Operational attributes are described in [RFC4512].
-
-   Attributes are returned at most once in an entry.  If an attribute
-   description is named more than once in the list, the subsequent names
-   are ignored.  If an attribute description in the list is not
-   recognized, it is ignored by the server.
-
-4.5.2.  Search Result
-
-   The results of the Search operation are returned as zero or more
-   SearchResultEntry and/or SearchResultReference messages, followed by
-   a single SearchResultDone message.
-
-        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
-             objectName      LDAPDN,
-             attributes      PartialAttributeList }
-
-        PartialAttributeList ::= SEQUENCE OF
-                             partialAttribute PartialAttribute
-
-        SearchResultReference ::= [APPLICATION 19] SEQUENCE
-                                  SIZE (1..MAX) OF uri URI
-
-        SearchResultDone ::= [APPLICATION 5] LDAPResult
-
-   Each SearchResultEntry represents an entry found during the Search.
-   Each SearchResultReference represents an area not yet explored during
-   the Search.  The SearchResultEntry and SearchResultReference messages
-   may come in any order.  Following all the SearchResultReference and
-   SearchResultEntry responses, the server returns a SearchResultDone
-   response, which contains an indication of success or details any
-   errors that have occurred.
-
-   Each entry returned in a SearchResultEntry will contain all
-   appropriate attributes as specified in the attributes field of the
-   Search Request, subject to access control and other administrative
-   policy.  Note that the PartialAttributeList may hold zero elements.
-
-
-
-Sermersheim                 Standards Track                    [Page 27]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   This may happen when none of the attributes of an entry were
-   requested or could be returned.  Note also that the partialAttribute
-   vals set may hold zero elements.  This may happen when typesOnly is
-   requested, access controls prevent the return of values, or other
-   reasons.
-
-   Some attributes may be constructed by the server and appear in a
-   SearchResultEntry attribute list, although they are not stored
-   attributes of an entry.  Clients SHOULD NOT assume that all
-   attributes can be modified, even if this is permitted by access
-   control.
-
-   If the server's schema defines short names [RFC4512] for an attribute
-   type, then the server SHOULD use one of those names in attribute
-   descriptions for that attribute type (in preference to using the
-   <numericoid> [RFC4512] format of the attribute type's object
-   identifier).  The server SHOULD NOT use the short name if that name
-   is known by the server to be ambiguous, or if it is otherwise likely
-   to cause interoperability problems.
-
-4.5.3.  Continuation References in the Search Result
-
-   If the server was able to locate the entry referred to by the
-   baseObject but was unable or unwilling to search one or more non-
-   local entries, the server may return one or more
-   SearchResultReference messages, each containing a reference to
-   another set of servers for continuing the operation.  A server MUST
-   NOT return any SearchResultReference messages if it has not located
-   the baseObject and thus has not searched any entries.  In this case,
-   it would return a SearchResultDone containing either a referral or
-   noSuchObject result code (depending on the server's knowledge of the
-   entry named in the baseObject).
-
-   If a server holds a copy or partial copy of the subordinate naming
-   context (Section 5 of [RFC4512]), it may use the search filter to
-   determine whether or not to return a SearchResultReference response.
-   Otherwise, SearchResultReference responses are always returned when
-   in scope.
-
-   The SearchResultReference is of the same data type as the Referral.
-
-   If the client wishes to progress the Search, it issues a new Search
-   operation for each SearchResultReference that is returned.  If
-   multiple URIs are present, the client assumes that any supported URI
-   may be used to progress the operation.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 28]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Clients that follow search continuation references MUST ensure that
-   they do not loop between servers.  They MUST NOT repeatedly contact
-   the same server for the same request with the same parameters.  Some
-   clients use a counter that is incremented each time search result
-   reference handling occurs for an operation, and these kinds of
-   clients MUST be able to handle at least ten nested referrals while
-   progressing the operation.
-
-   Note that the Abandon operation described in Section 4.11 applies
-   only to a particular operation sent at the LDAP message layer between
-   a client and server.  The client must individually abandon subsequent
-   Search operations it wishes to.
-
-   A URI for a server implementing LDAP and accessible via TCP/IP (v4 or
-   v6) [RFC793][RFC791] is written as an LDAP URL according to
-   [RFC4516].
-
-   SearchResultReference values that are LDAP URLs follow these rules:
-
-   - The <dn> part of the LDAP URL MUST be present, with the new target
-     object name.  The client uses this name when following the
-     reference.
-
-   - Some servers (e.g., participating in distributed indexing) may
-     provide a different filter in the LDAP URL.
-
-   - If the <filter> part of the LDAP URL is present, the client uses
-     this filter in its next request to progress this Search, and if it
-     is not present the client uses the same filter as it used for that
-     Search.
-
-   - If the originating search scope was singleLevel, the <scope> part
-     of the LDAP URL will be "base".
-
-   - It is RECOMMENDED that the <scope> part be present to avoid
-     ambiguity.  In the absence of a <scope> part, the scope of the
-     original Search request is assumed.
-
-   - Other aspects of the new Search request may be the same as or
-     different from the Search request that generated the
-     SearchResultReference.
-
-   - The name of an unexplored subtree in a SearchResultReference need
-     not be subordinate to the base object.
-
-   Other kinds of URIs may be returned.  The syntax and semantics of
-   such URIs is left to future specifications.  Clients may ignore URIs
-   that they do not support.
-
-
-
-Sermersheim                 Standards Track                    [Page 29]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   UTF-8-encoded characters appearing in the string representation of a
-   DN, search filter, or other fields of the referral value may not be
-   legal for URIs (e.g., spaces) and MUST be escaped using the % method
-   in [RFC3986].
-
-4.5.3.1.  Examples
-
-   For example, suppose the contacted server (hosta) holds the entry
-   <DC=Example,DC=NET> and the entry <CN=Manager,DC=Example,DC=NET>.  It
-   knows that both LDAP servers (hostb) and (hostc) hold
-   <OU=People,DC=Example,DC=NET> (one is the master and the other server
-   a shadow), and that LDAP-capable server (hostd) holds the subtree
-   <OU=Roles,DC=Example,DC=NET>.  If a wholeSubtree Search of
-   <DC=Example,DC=NET> is requested to the contacted server, it may
-   return the following:
-
-     SearchResultEntry for DC=Example,DC=NET
-     SearchResultEntry for CN=Manager,DC=Example,DC=NET
-     SearchResultReference {
-       ldap://hostb/OU=People,DC=Example,DC=NET??sub
-       ldap://hostc/OU=People,DC=Example,DC=NET??sub }
-     SearchResultReference {
-       ldap://hostd/OU=Roles,DC=Example,DC=NET??sub }
-     SearchResultDone (success)
-
-   Client implementors should note that when following a
-   SearchResultReference, additional SearchResultReference may be
-   generated.  Continuing the example, if the client contacted the
-   server (hostb) and issued the Search request for the subtree
-   <OU=People,DC=Example,DC=NET>, the server might respond as follows:
-
-     SearchResultEntry for OU=People,DC=Example,DC=NET
-     SearchResultReference {
-       ldap://hoste/OU=Managers,OU=People,DC=Example,DC=NET??sub }
-     SearchResultReference {
-       ldap://hostf/OU=Consultants,OU=People,DC=Example,DC=NET??sub }
-     SearchResultDone (success)
-
-   Similarly, if a singleLevel Search of <DC=Example,DC=NET> is
-   requested to the contacted server, it may return the following:
-
-     SearchResultEntry for CN=Manager,DC=Example,DC=NET
-     SearchResultReference {
-       ldap://hostb/OU=People,DC=Example,DC=NET??base
-       ldap://hostc/OU=People,DC=Example,DC=NET??base }
-     SearchResultReference {
-       ldap://hostd/OU=Roles,DC=Example,DC=NET??base }
-     SearchResultDone (success)
-
-
-
-Sermersheim                 Standards Track                    [Page 30]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   If the contacted server does not hold the base object for the Search,
-   but has knowledge of its possible location, then it may return a
-   referral to the client.  In this case, if the client requests a
-   subtree Search of <DC=Example,DC=ORG> to hosta, the server returns a
-   SearchResultDone containing a referral.
-
-     SearchResultDone (referral) {
-       ldap://hostg/DC=Example,DC=ORG??sub }
-
-4.6.  Modify Operation
-
-   The Modify operation allows a client to request that a modification
-   of an entry be performed on its behalf by a server.  The Modify
-   Request is defined as follows:
-
-        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
-             object          LDAPDN,
-             changes         SEQUENCE OF change SEQUENCE {
-                  operation       ENUMERATED {
-                       add     (0),
-                       delete  (1),
-                       replace (2),
-                       ...  },
-                  modification    PartialAttribute } }
-
-   Fields of the Modify Request are:
-
-   - object: The value of this field contains the name of the entry to
-     be modified.  The server SHALL NOT perform any alias dereferencing
-     in determining the object to be modified.
-
-   - changes: A list of modifications to be performed on the entry.  The
-     entire list of modifications MUST be performed in the order they
-     are listed as a single atomic operation.  While individual
-     modifications may violate certain aspects of the directory schema
-     (such as the object class definition and Directory Information Tree
-     (DIT) content rule), the resulting entry after the entire list of
-     modifications is performed MUST conform to the requirements of the
-     directory model and controlling schema [RFC4512].
-
-     -  operation: Used to specify the type of modification being
-        performed.  Each operation type acts on the following
-        modification.  The values of this field have the following
-        semantics, respectively:
-
-           add: add values listed to the modification attribute,
-           creating the attribute if necessary.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 31]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-           delete: delete values listed from the modification attribute.
-           If no values are listed, or if all current values of the
-           attribute are listed, the entire attribute is removed.
-
-           replace: replace all existing values of the modification
-           attribute with the new values listed, creating the attribute
-           if it did not already exist.  A replace with no value will
-           delete the entire attribute if it exists, and it is ignored
-           if the attribute does not exist.
-
-     -  modification: A PartialAttribute (which may have an empty SET
-        of vals) used to hold the attribute type or attribute type and
-        values being modified.
-
-   Upon receipt of a Modify Request, the server attempts to perform the
-   necessary modifications to the DIT and returns the result in a Modify
-   Response, defined as follows:
-
-        ModifyResponse ::= [APPLICATION 7] LDAPResult
-
-   The server will return to the client a single Modify Response
-   indicating either the successful completion of the DIT modification,
-   or the reason that the modification failed.  Due to the requirement
-   for atomicity in applying the list of modifications in the Modify
-   Request, the client may expect that no modifications of the DIT have
-   been performed if the Modify Response received indicates any sort of
-   error, and that all requested modifications have been performed if
-   the Modify Response indicates successful completion of the Modify
-   operation.  Whether or not the modification was applied cannot be
-   determined by the client if the Modify Response was not received
-   (e.g., the LDAP session was terminated or the Modify operation was
-   abandoned).
-
-   Servers MUST ensure that entries conform to user and system schema
-   rules or other data model constraints.  The Modify operation cannot
-   be used to remove from an entry any of its distinguished values,
-   i.e., those values which form the entry's relative distinguished
-   name.  An attempt to do so will result in the server returning the
-   notAllowedOnRDN result code.  The Modify DN operation described in
-   Section 4.9 is used to rename an entry.
-
-   For attribute types that specify no equality matching, the rules in
-   Section 2.5.1 of [RFC4512] are followed.
-
-   Note that due to the simplifications made in LDAP, there is not a
-   direct mapping of the changes in an LDAP ModifyRequest onto the
-   changes of a DAP ModifyEntry operation, and different implementations
-
-
-
-
-Sermersheim                 Standards Track                    [Page 32]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   of LDAP-DAP gateways may use different means of representing the
-   change.  If successful, the final effect of the operations on the
-   entry MUST be identical.
-
-4.7.  Add Operation
-
-   The Add operation allows a client to request the addition of an entry
-   into the Directory.  The Add Request is defined as follows:
-
-        AddRequest ::= [APPLICATION 8] SEQUENCE {
-             entry           LDAPDN,
-             attributes      AttributeList }
-
-        AttributeList ::= SEQUENCE OF attribute Attribute
-
-   Fields of the Add Request are:
-
-   - entry: the name of the entry to be added.  The server SHALL NOT
-     dereference any aliases in locating the entry to be added.
-
-   - attributes: the list of attributes that, along with those from the
-     RDN, make up the content of the entry being added.  Clients MAY or
-     MAY NOT include the RDN attribute(s) in this list.  Clients MUST
-     NOT supply NO-USER-MODIFICATION attributes such as the
-     createTimestamp or creatorsName attributes, since the server
-     maintains these automatically.
-
-   Servers MUST ensure that entries conform to user and system schema
-   rules or other data model constraints.  For attribute types that
-   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
-   are followed (this applies to the naming attribute in addition to any
-   multi-valued attributes being added).
-
-   The entry named in the entry field of the AddRequest MUST NOT exist
-   for the AddRequest to succeed.  The immediate superior (parent) of an
-   object or alias entry to be added MUST exist.  For example, if the
-   client attempted to add <CN=JS,DC=Example,DC=NET>, the
-   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
-   exist, then the server would return the noSuchObject result code with
-   the matchedDN field containing <DC=NET>.
-
-   Upon receipt of an Add Request, a server will attempt to add the
-   requested entry.  The result of the Add attempt will be returned to
-   the client in the Add Response, defined as follows:
-
-        AddResponse ::= [APPLICATION 9] LDAPResult
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 33]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   A response of success indicates that the new entry has been added to
-   the Directory.
-
-4.8.  Delete Operation
-
-   The Delete operation allows a client to request the removal of an
-   entry from the Directory.  The Delete Request is defined as follows:
-
-        DelRequest ::= [APPLICATION 10] LDAPDN
-
-   The Delete Request consists of the name of the entry to be deleted.
-   The server SHALL NOT dereference aliases while resolving the name of
-   the target entry to be removed.
-
-   Only leaf entries (those with no subordinate entries) can be deleted
-   with this operation.
-
-   Upon receipt of a Delete Request, a server will attempt to perform
-   the entry removal requested and return the result in the Delete
-   Response defined as follows:
-
-        DelResponse ::= [APPLICATION 11] LDAPResult
-
-4.9.  Modify DN Operation
-
-   The Modify DN operation allows a client to change the Relative
-   Distinguished Name (RDN) of an entry in the Directory and/or to move
-   a subtree of entries to a new location in the Directory.  The Modify
-   DN Request is defined as follows:
-
-        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
-             entry           LDAPDN,
-             newrdn          RelativeLDAPDN,
-             deleteoldrdn    BOOLEAN,
-             newSuperior     [0] LDAPDN OPTIONAL }
-
-   Fields of the Modify DN Request are:
-
-   - entry: the name of the entry to be changed.  This entry may or may
-     not have subordinate entries.
-
-   - newrdn: the new RDN of the entry.  The value of the old RDN is
-     supplied when moving the entry to a new superior without changing
-     its RDN.  Attribute values of the new RDN not matching any
-     attribute value of the entry are added to the entry, and an
-     appropriate error is returned if this fails.
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 34]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - deleteoldrdn: a boolean field that controls whether the old RDN
-     attribute values are to be retained as attributes of the entry or
-     deleted from the entry.
-
-   - newSuperior: if present, this is the name of an existing object
-     entry that becomes the immediate superior (parent) of the
-     existing entry.
-
-   The server SHALL NOT dereference any aliases in locating the objects
-   named in entry or newSuperior.
-
-   Upon receipt of a ModifyDNRequest, a server will attempt to perform
-   the name change and return the result in the Modify DN Response,
-   defined as follows:
-
-        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
-   For example, if the entry named in the entry field was <cn=John
-   Smith,c=US>, the newrdn field was <cn=John Cougar Smith>, and the
-   newSuperior field was absent, then this operation would attempt to
-   rename the entry as <cn=John Cougar Smith,c=US>.  If there was
-   already an entry with that name, the operation would fail with the
-   entryAlreadyExists result code.
-
-   Servers MUST ensure that entries conform to user and system schema
-   rules or other data model constraints.  For attribute types that
-   specify no equality matching, the rules in Section 2.5.1 of [RFC4512]
-   are followed (this pertains to newrdn and deleteoldrdn).
-
-   The object named in newSuperior MUST exist.  For example, if the
-   client attempted to add <CN=JS,DC=Example,DC=NET>, the
-   <DC=Example,DC=NET> entry did not exist, and the <DC=NET> entry did
-   exist, then the server would return the noSuchObject result code with
-   the matchedDN field containing <DC=NET>.
-
-   If the deleteoldrdn field is TRUE, the attribute values forming the
-   old RDN (but not the new RDN) are deleted from the entry.  If the
-   deleteoldrdn field is FALSE, the attribute values forming the old RDN
-   will be retained as non-distinguished attribute values of the entry.
-
-   Note that X.500 restricts the ModifyDN operation to affect only
-   entries that are contained within a single server.  If the LDAP
-   server is mapped onto DAP, then this restriction will apply, and the
-   affectsMultipleDSAs result code will be returned if this error
-   occurred.  In general, clients MUST NOT expect to be able to perform
-   arbitrary movements of entries and subtrees between servers or
-   between naming contexts.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 35]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-4.10.  Compare Operation
-
-   The Compare operation allows a client to compare an assertion value
-   with the values of a particular attribute in a particular entry in
-   the Directory.  The Compare Request is defined as follows:
-
-        CompareRequest ::= [APPLICATION 14] SEQUENCE {
-             entry           LDAPDN,
-             ava             AttributeValueAssertion }
-
-   Fields of the Compare Request are:
-
-   - entry: the name of the entry to be compared.  The server SHALL NOT
-     dereference any aliases in locating the entry to be compared.
-
-   - ava: holds the attribute value assertion to be compared.
-
-   Upon receipt of a Compare Request, a server will attempt to perform
-   the requested comparison and return the result in the Compare
-   Response, defined as follows:
-
-        CompareResponse ::= [APPLICATION 15] LDAPResult
-
-   The resultCode is set to compareTrue, compareFalse, or an appropriate
-   error.  compareTrue indicates that the assertion value in the ava
-   field matches a value of the attribute or subtype according to the
-   attribute's EQUALITY matching rule.  compareFalse indicates that the
-   assertion value in the ava field and the values of the attribute or
-   subtype did not match.  Other result codes indicate either that the
-   result of the comparison was Undefined (Section 4.5.1.7), or that
-   some error occurred.
-
-   Note that some directory systems may establish access controls that
-   permit the values of certain attributes (such as userPassword) to be
-   compared but not interrogated by other means.
-
-4.11.  Abandon Operation
-
-   The function of the Abandon operation is to allow a client to request
-   that the server abandon an uncompleted operation.  The Abandon
-   Request is defined as follows:
-
-        AbandonRequest ::= [APPLICATION 16] MessageID
-
-   The MessageID is that of an operation that was requested earlier at
-   this LDAP message layer.  The Abandon request itself has its own
-   MessageID.  This is distinct from the MessageID of the earlier
-   operation being abandoned.
-
-
-
-Sermersheim                 Standards Track                    [Page 36]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   There is no response defined in the Abandon operation.  Upon receipt
-   of an AbandonRequest, the server MAY abandon the operation identified
-   by the MessageID.  Since the client cannot tell the difference
-   between a successfully abandoned operation and an uncompleted
-   operation, the application of the Abandon operation is limited to
-   uses where the client does not require an indication of its outcome.
-
-   Abandon, Bind, Unbind, and StartTLS operations cannot be abandoned.
-
-   In the event that a server receives an Abandon Request on a Search
-   operation in the midst of transmitting responses to the Search, that
-   server MUST cease transmitting entry responses to the abandoned
-   request immediately, and it MUST NOT send the SearchResultDone.  Of
-   course, the server MUST ensure that only properly encoded LDAPMessage
-   PDUs are transmitted.
-
-   The ability to abandon other (particularly update) operations is at
-   the discretion of the server.
-
-   Clients should not send Abandon requests for the same operation
-   multiple times, and they MUST also be prepared to receive results
-   from operations they have abandoned (since these might have been in
-   transit when the Abandon was requested or might not be able to be
-   abandoned).
-
-   Servers MUST discard Abandon requests for messageIDs they do not
-   recognize, for operations that cannot be abandoned, and for
-   operations that have already been abandoned.
-
-4.12.  Extended Operation
-
-   The Extended operation allows additional operations to be defined for
-   services not already available in the protocol; for example, to Add
-   operations to install transport layer security (see Section 4.14).
-
-   The Extended operation allows clients to make requests and receive
-   responses with predefined syntaxes and semantics.  These may be
-   defined in RFCs or be private to particular implementations.
-
-   Each Extended operation consists of an Extended request and an
-   Extended response.
-
-        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
-             requestName      [0] LDAPOID,
-             requestValue     [1] OCTET STRING OPTIONAL }
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 37]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The requestName is a dotted-decimal representation of the unique
-   OBJECT IDENTIFIER corresponding to the request.  The requestValue is
-   information in a form defined by that request, encapsulated inside an
-   OCTET STRING.
-
-   The server will respond to this with an LDAPMessage containing an
-   ExtendedResponse.
-
-        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
-             COMPONENTS OF LDAPResult,
-             responseName     [10] LDAPOID OPTIONAL,
-             responseValue    [11] OCTET STRING OPTIONAL }
-
-   The responseName field, when present, contains an LDAPOID that is
-   unique for this extended operation or response.  This field is
-   optional (even when the extension specification defines an LDAPOID
-   for use in this field).  The field will be absent whenever the server
-   is unable or unwilling to determine the appropriate LDAPOID to
-   return, for instance, when the requestName cannot be parsed or its
-   value is not recognized.
-
-   Where the requestName is not recognized, the server returns
-   protocolError.  (The server may return protocolError in other cases.)
-
-   The requestValue and responseValue fields contain information
-   associated with the operation.  The format of these fields is defined
-   by the specification of the Extended operation.  Implementations MUST
-   be prepared to handle arbitrary contents of these fields, including
-   zero bytes.  Values that are defined in terms of ASN.1 and BER-
-   encoded according to Section 5.1 also follow the extensibility rules
-   in Section 4.
-
-   Servers list the requestName of Extended Requests they recognize in
-   the 'supportedExtension' attribute in the root DSE (Section 5.1 of
-   [RFC4512]).
-
-   Extended operations may be specified in other documents.  The
-   specification of an Extended operation consists of:
-
-   - the OBJECT IDENTIFIER assigned to the requestName,
-
-   - the OBJECT IDENTIFIER (if any) assigned to the responseName (note
-     that the same OBJECT IDENTIFIER may be used for both the
-     requestName and responseName),
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 38]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - the format of the contents of the requestValue and responseValue
-     (if any), and
-
-   - the semantics of the operation.
-
-4.13.  IntermediateResponse Message
-
-   While the Search operation provides a mechanism to return multiple
-   response messages for a single Search request, other operations, by
-   nature, do not provide for multiple response messages.
-
-   The IntermediateResponse message provides a general mechanism for
-   defining single-request/multiple-response operations in LDAP.  This
-   message is intended to be used in conjunction with the Extended
-   operation to define new single-request/multiple-response operations
-   or in conjunction with a control when extending existing LDAP
-   operations in a way that requires them to return Intermediate
-   response information.
-
-   It is intended that the definitions and descriptions of Extended
-   operations and controls that make use of the IntermediateResponse
-   message will define the circumstances when an IntermediateResponse
-   message can be sent by a server and the associated meaning of an
-   IntermediateResponse message sent in a particular circumstance.
-
-        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
-                responseName     [0] LDAPOID OPTIONAL,
-                responseValue    [1] OCTET STRING OPTIONAL }
-
-   IntermediateResponse messages SHALL NOT be returned to the client
-   unless the client issues a request that specifically solicits their
-   return.  This document defines two forms of solicitation: Extended
-   operation and request control.  IntermediateResponse messages are
-   specified in documents describing the manner in which they are
-   solicited (i.e., in the Extended operation or request control
-   specification that uses them).  These specifications include:
-
-   - the OBJECT IDENTIFIER (if any) assigned to the responseName,
-
-   - the format of the contents of the responseValue (if any), and
-
-   - the semantics associated with the IntermediateResponse message.
-
-   Extensions that allow the return of multiple types of
-   IntermediateResponse messages SHALL identify those types using unique
-   responseName values (note that one of these may specify no value).
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 39]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Sections 4.13.1 and 4.13.2 describe additional requirements on the
-   inclusion of responseName and responseValue in IntermediateResponse
-   messages.
-
-4.13.1.  Usage with LDAP ExtendedRequest and ExtendedResponse
-
-   A single-request/multiple-response operation may be defined using a
-   single ExtendedRequest message to solicit zero or more
-   IntermediateResponse messages of one or more kinds, followed by an
-   ExtendedResponse message.
-
-4.13.2.  Usage with LDAP Request Controls
-
-   A control's semantics may include the return of zero or more
-   IntermediateResponse messages prior to returning the final result
-   code for the operation.  One or more kinds of IntermediateResponse
-   messages may be sent in response to a request control.
-
-   All IntermediateResponse messages associated with request controls
-   SHALL include a responseName.  This requirement ensures that the
-   client can correctly identify the source of IntermediateResponse
-   messages when:
-
-   - two or more controls using IntermediateResponse messages are
-     included in a request for any LDAP operation or
-
-   - one or more controls using IntermediateResponse messages are
-     included in a request with an LDAP Extended operation that uses
-     IntermediateResponse messages.
-
-4.14.  StartTLS Operation
-
-   The Start Transport Layer Security (StartTLS) operation's purpose is
-   to initiate installation of a TLS layer.  The StartTLS operation is
-   defined using the Extended operation mechanism described in Section
-   4.12.
-
-4.14.1.  StartTLS Request
-
-   A client requests TLS establishment by transmitting a StartTLS
-   request message to the server.  The StartTLS request is defined in
-   terms of an ExtendedRequest.  The requestName is
-   "1.3.6.1.4.1.1466.20037", and the requestValue field is always
-   absent.
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 40]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   The client MUST NOT send any LDAP PDUs at this LDAP message layer
-   following this request until it receives a StartTLS Extended response
-   and, in the case of a successful response, completes TLS
-   negotiations.
-
-   Detected sequencing problems (particularly those detailed in Section
-   3.1.1 of [RFC4513]) result in the resultCode being set to
-   operationsError.
-
-   If the server does not support TLS (whether by design or by current
-   configuration), it returns with the resultCode set to protocolError
-   as described in Section 4.12.
-
-4.14.2.  StartTLS Response
-
-   When a StartTLS request is received, servers supporting the operation
-   MUST return a StartTLS response message to the requestor.  The
-   responseName is "1.3.6.1.4.1.1466.20037" when provided (see Section
-   4.12).  The responseValue is always absent.
-
-   If the server is willing and able to negotiate TLS, it returns the
-   StartTLS response with the resultCode set to success.  Upon client
-   receipt of a successful StartTLS response, protocol peers may
-   commence with TLS negotiation as discussed in Section 3 of [RFC4513].
-
-   If the server is otherwise unwilling or unable to perform this
-   operation, the server is to return an appropriate result code
-   indicating the nature of the problem.  For example, if the TLS
-   subsystem is not presently available, the server may indicate this by
-   returning with the resultCode set to unavailable.  In cases where a
-   non-success result code is returned, the LDAP session is left without
-   a TLS layer.
-
-4.14.3.  Removal of the TLS Layer
-
-   Either the client or server MAY remove the TLS layer and leave the
-   LDAP message layer intact by sending and receiving a TLS closure
-   alert.
-
-   The initiating protocol peer sends the TLS closure alert and MUST
-   wait until it receives a TLS closure alert from the other peer before
-   sending further LDAP PDUs.
-
-   When a protocol peer receives the initial TLS closure alert, it may
-   choose to allow the LDAP message layer to remain intact.  In this
-   case, it MUST immediately transmit a TLS closure alert.  Following
-   this, it MAY send and receive LDAP PDUs.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 41]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Protocol peers MAY terminate the LDAP session after sending or
-   receiving a TLS closure alert.
-
-5.  Protocol Encoding, Connection, and Transfer
-
-   This protocol is designed to run over connection-oriented, reliable
-   transports, where the data stream is divided into octets (8-bit
-   units), with each octet and each bit being significant.
-
-   One underlying service, LDAP over TCP, is defined in Section 5.2.
-   This service is generally applicable to applications providing or
-   consuming X.500-based directory services on the Internet.  This
-   specification was generally written with the TCP mapping in mind.
-   Specifications detailing other mappings may encounter various
-   obstacles.
-
-   Implementations of LDAP over TCP MUST implement the mapping as
-   described in Section 5.2.
-
-   This table illustrates the relationship among the different layers
-   involved in an exchange between two protocol peers:
-
-               +----------------------+
-               |  LDAP message layer  |
-               +----------------------+ > LDAP PDUs
-               +----------------------+ < data
-               |      SASL layer      |
-               +----------------------+ > SASL-protected data
-               +----------------------+ < data
-               |       TLS layer      |
-   Application +----------------------+ > TLS-protected data
-   ------------+----------------------+ < data
-     Transport | transport connection |
-               +----------------------+
-
-5.1.  Protocol Encoding
-
-   The protocol elements of LDAP SHALL be encoded for exchange using the
-   Basic Encoding Rules [BER] of [ASN.1] with the following
-   restrictions:
-
-   - Only the definite form of length encoding is used.
-
-   - OCTET STRING values are encoded in the primitive form only.
-
-   - If the value of a BOOLEAN type is true, the encoding of the value
-     octet is set to hex "FF".
-
-
-
-
-Sermersheim                 Standards Track                    [Page 42]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - If a value of a type is its default value, it is absent.  Only some
-     BOOLEAN and INTEGER types have default values in this protocol
-     definition.
-
-   These restrictions are meant to ease the overhead of encoding and
-   decoding certain elements in BER.
-
-   These restrictions do not apply to ASN.1 types encapsulated inside of
-   OCTET STRING values, such as attribute values, unless otherwise
-   stated.
-
-5.2.  Transmission Control Protocol (TCP)
-
-   The encoded LDAPMessage PDUs are mapped directly onto the TCP
-   [RFC793] bytestream using the BER-based encoding described in Section
-   5.1.  It is recommended that server implementations running over the
-   TCP provide a protocol listener on the Internet Assigned Numbers
-   Authority (IANA)-assigned LDAP port, 389 [PortReg].  Servers may
-   instead provide a listener on a different port number.  Clients MUST
-   support contacting servers on any valid TCP port.
-
-5.3.  Termination of the LDAP session
-
-   Termination of the LDAP session is typically initiated by the client
-   sending an UnbindRequest (Section 4.3), or by the server sending a
-   Notice of Disconnection (Section 4.4.1).  In these cases, each
-   protocol peer gracefully terminates the LDAP session by ceasing
-   exchanges at the LDAP message layer, tearing down any SASL layer,
-   tearing down any TLS layer, and closing the transport connection.
-
-   A protocol peer may determine that the continuation of any
-   communication would be pernicious, and in this case, it may abruptly
-   terminate the session by ceasing communication and closing the
-   transport connection.
-
-   In either case, when the LDAP session is terminated, uncompleted
-   operations are handled as specified in Section 3.1.
-
-6.  Security Considerations
-
-   This version of the protocol provides facilities for simple
-   authentication using a cleartext password, as well as any SASL
-   [RFC4422] mechanism.  Installing SASL and/or TLS layers can provide
-   integrity and other data security services.
-
-   It is also permitted that the server can return its credentials to
-   the client, if it chooses to do so.
-
-
-
-
-Sermersheim                 Standards Track                    [Page 43]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Use of cleartext password is strongly discouraged where the
-   underlying transport service cannot guarantee confidentiality and may
-   result in disclosure of the password to unauthorized parties.
-
-   Servers are encouraged to prevent directory modifications by clients
-   that have authenticated anonymously [RFC4513].
-
-   Security considerations for authentication methods, SASL mechanisms,
-   and TLS are described in [RFC4513].
-
-   Note that SASL authentication exchanges do not provide data
-   confidentiality or integrity protection for the version or name
-   fields of the BindRequest or the resultCode, diagnosticMessage, or
-   referral fields of the BindResponse, nor for any information
-   contained in controls attached to Bind requests or responses.  Thus,
-   information contained in these fields SHOULD NOT be relied on unless
-   it is otherwise protected (such as by establishing protections at the
-   transport layer).
-
-   Implementors should note that various security factors (including
-   authentication and authorization information and data security
-   services) may change during the course of the LDAP session or even
-   during the performance of a particular operation.  For instance,
-   credentials could expire, authorization identities or access controls
-   could change, or the underlying security layer(s) could be replaced
-   or terminated.  Implementations should be robust in the handling of
-   changing security factors.
-
-   In some cases, it may be appropriate to continue the operation even
-   in light of security factor changes.  For instance, it may be
-   appropriate to continue an Abandon operation regardless of the
-   change, or to continue an operation when the change upgraded (or
-   maintained) the security factor.  In other cases, it may be
-   appropriate to fail or alter the processing of the operation.  For
-   instance, if confidential protections were removed, it would be
-   appropriate either to fail a request to return sensitive data or,
-   minimally, to exclude the return of sensitive data.
-
-   Implementations that cache attributes and entries obtained via LDAP
-   MUST ensure that access controls are maintained if that information
-   is to be provided to multiple clients, since servers may have access
-   control policies that prevent the return of entries or attributes in
-   Search results except to particular authenticated clients.  For
-   example, caches could serve result information only to the client
-   whose request caused it to be in the cache.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 44]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   Servers may return referrals or Search result references that
-   redirect clients to peer servers.  It is possible for a rogue
-   application to inject such referrals into the data stream in an
-   attempt to redirect a client to a rogue server.  Clients are advised
-   to be aware of this and possibly reject referrals when
-   confidentiality measures are not in place.  Clients are advised to
-   reject referrals from the StartTLS operation.
-
-   The matchedDN and diagnosticMessage fields, as well as some
-   resultCode values (e.g., attributeOrValueExists and
-   entryAlreadyExists), could disclose the presence or absence of
-   specific data in the directory that is subject to access and other
-   administrative controls.  Server implementations should restrict
-   access to protected information equally under both normal and error
-   conditions.
-
-   Protocol peers MUST be prepared to handle invalid and arbitrary-
-   length protocol encodings.  Invalid protocol encodings include: BER
-   encoding exceptions, format string and UTF-8 encoding exceptions,
-   overflow exceptions, integer value exceptions, and binary mode on/off
-   flag exceptions.  The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
-   excellent examples of these exceptions and test cases used to
-   discover flaws.
-
-   In the event that a protocol peer senses an attack that in its nature
-   could cause damage due to further communication at any layer in the
-   LDAP session, the protocol peer should abruptly terminate the LDAP
-   session as described in Section 5.3.
-
-7.  Acknowledgements
-
-   This document is based on RFC 2251 by Mark Wahl, Tim Howes, and Steve
-   Kille.  RFC 2251 was a product of the IETF ASID Working Group.
-
-   It is also based on RFC 2830 by Jeff Hodges, RL "Bob" Morgan, and
-   Mark Wahl.  RFC 2830 was a product of the IETF LDAPEXT Working Group.
-
-   It is also based on RFC 3771 by Roger Harrison and Kurt Zeilenga.
-   RFC 3771 was an individual submission to the IETF.
-
-   This document is a product of the IETF LDAPBIS Working Group.
-   Significant contributors of technical review and content include Kurt
-   Zeilenga, Steven Legg, and Hallvard Furuseth.
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 45]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-8.  Normative References
-
-   [ASN.1]       ITU-T Recommendation X.680 (07/2002) | ISO/IEC 8824-
-                 1:2002 "Information Technology - Abstract Syntax
-                 Notation One (ASN.1): Specification of basic notation".
-
-   [BER]         ITU-T Rec. X.690 (07/2002) | ISO/IEC 8825-1:2002,
-                 "Information technology - ASN.1 encoding rules:
-                 Specification of Basic Encoding Rules (BER), Canonical
-                 Encoding Rules (CER) and Distinguished Encoding Rules
-                 (DER)", 2002.
-
-   [ISO10646]    Universal Multiple-Octet Coded Character Set (UCS) -
-                 Architecture and Basic Multilingual Plane, ISO/IEC
-                 10646-1 : 1993.
-
-   [RFC791]      Postel, J., "Internet Protocol", STD 5, RFC 791,
-                 September 1981.
-
-   [RFC793]      Postel, J., "Transmission Control Protocol", STD 7, RFC
-                 793, September 1981.
-
-   [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.
-
-   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
-                 10646", STD 63, RFC 3629, November 2003.
-
-   [RFC3986]     Berners-Lee, T., Fielding, R., and L. Masinter,
-                 "Uniform Resource Identifier (URI): Generic Syntax",
-                 STD 66, RFC 3986, January 2005.
-
-   [RFC4013]     Zeilenga, K., "SASLprep: Stringprep Profile for User
-                 Names and Passwords", RFC 4013, February 2005.
-
-   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                 Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4346]     Dierks, T. and E. Rescorla, "The TLS Protocol Version
-                 1.1", RFC 4346, March 2006.
-
-   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
-                 Authentication and Security Layer (SASL)", RFC 4422,
-                 June 2006.
-
-
-
-Sermersheim                 Standards Track                    [Page 46]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Technical Specification Road Map", RFC
-                 4510, June 2006.
-
-   [RFC4512]     Zeilenga, K., Lightweight Directory Access Protocol
-                 (LDAP): Directory Information Models", RFC 4512, June
-                 2006.
-
-   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Authentication Methods and Security
-                 Mechanisms", RFC 4513, June 2006.
-
-   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): String Representation of Distinguished
-                 Names", RFC 4514, June 2006.
-
-   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): Uniform Resource Locator", RFC
-                 4516, June 2006.
-
-   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
-                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                 2006.
-
-   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
-                 (IANA) Considerations for the Lightweight Directory
-                 Access Protocol (LDAP)", BCP 64, RFC 4520, 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/).
-
-   [X.500]       ITU-T Rec. X.500, "The Directory: Overview of Concepts,
-                 Models and Service", 1993.
-
-   [X.511]       ITU-T Rec. X.511, "The Directory: Abstract Service
-                 Definition", 1993.
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 47]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-9.  Informative References
-
-   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
-                 #17, Character Encoding Model", UTR17,
-                 <http://www.unicode.org/unicode/reports/tr17/>, August
-                 2000.
-
-   [Glossary]    The Unicode Consortium, "Unicode Glossary",
-                 <http://www.unicode.org/glossary/>.
-
-   [PortReg]     IANA, "Port Numbers",
-                 <http://www.iana.org/assignments/port-numbers>.
-
-   [PROTOS-LDAP] University of Oulu, "PROTOS Test-Suite: c06-ldapv3"
-                 <http://www.ee.oulu.fi/research/ouspg/protos/testing/
-                 c06/ldapv3/>.
-
-10.  IANA Considerations
-
-   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
-   result code registry to indicate that this document provides the
-   definitive technical specification for result codes 0-36, 48-54, 64-
-   70, 80-90.  It is also noted that one resultCode value
-   (strongAuthRequired) has been renamed (to strongerAuthRequired).
-
-   The IANA has also updated the LDAP Protocol Mechanism registry to
-   indicate that this document and [RFC4513] provides the definitive
-   technical specification for the StartTLS (1.3.6.1.4.1.1466.20037)
-   Extended operation.
-
-   IANA has assigned LDAP Object Identifier 18 [RFC4520] to identify the
-   ASN.1 module defined in this document.
-
-        Subject: Request for LDAP Object Identifier Registration
-        Person & email address to contact for further information:
-             Jim Sermersheim <jimse at novell.com>
-        Specification: RFC 4511
-        Author/Change Controller: IESG
-        Comments:
-             Identifies the LDAP ASN.1 module
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 48]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-Appendix A.  LDAP Result Codes
-
-   This normative appendix details additional considerations regarding
-   LDAP result codes and provides a brief, general description of each
-   LDAP result code enumerated in Section 4.1.9.
-
-   Additional result codes MAY be defined for use with extensions
-   [RFC4520].  Client implementations SHALL treat any result code that
-   they do not recognize as an unknown error condition.
-
-   The descriptions provided here do not fully account for result code
-   substitutions used to prevent unauthorized disclosures (such as
-   substitution of noSuchObject for insufficientAccessRights, or
-   invalidCredentials for insufficientAccessRights).
-
-A.1.  Non-Error Result Codes
-
-   These result codes (called "non-error" result codes) do not indicate
-   an error condition:
-
-        success (0),
-        compareFalse (5),
-        compareTrue (6),
-        referral (10), and
-        saslBindInProgress (14).
-
-   The success, compareTrue, and compareFalse result codes indicate
-   successful completion (and, hence, are referred to as "successful"
-   result codes).
-
-   The referral and saslBindInProgress result codes indicate the client
-   needs to take additional action to complete the operation.
-
-A.2.  Result Codes
-
-   Existing LDAP result codes are described as follows:
-
-      success (0)
-         Indicates the successful completion of an operation.  Note:
-         this code is not used with the Compare operation.  See
-         compareFalse (5) and compareTrue (6).
-
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 49]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      operationsError (1)
-         Indicates that the operation is not properly sequenced with
-         relation to other operations (of same or different type).
-
-         For example, this code is returned if the client attempts to
-         StartTLS [RFC4346] while there are other uncompleted operations
-         or if a TLS layer was already installed.
-
-      protocolError (2)
-         Indicates the server received data that is not well-formed.
-
-         For Bind operation only, this code is also used to indicate
-         that the server does not support the requested protocol
-         version.
-
-         For Extended operations only, this code is also used to
-         indicate that the server does not support (by design or
-         configuration) the Extended operation associated with the
-         requestName.
-
-         For request operations specifying multiple controls, this may
-         be used to indicate that the server cannot ignore the order
-         of the controls as specified, or that the combination of the
-         specified controls is invalid or unspecified.
-
-      timeLimitExceeded (3)
-         Indicates that the time limit specified by the client was
-         exceeded before the operation could be completed.
-
-      sizeLimitExceeded (4)
-         Indicates that the size limit specified by the client was
-         exceeded before the operation could be completed.
-
-      compareFalse (5)
-         Indicates that the Compare operation has successfully
-         completed and the assertion has evaluated to FALSE or
-         Undefined.
-
-      compareTrue (6)
-         Indicates that the Compare operation has successfully
-         completed and the assertion has evaluated to TRUE.
-
-      authMethodNotSupported (7)
-         Indicates that the authentication method or mechanism is not
-         supported.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 50]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      strongerAuthRequired (8)
-         Indicates the server requires strong(er) authentication in
-         order to complete the operation.
-
-         When used with the Notice of Disconnection operation, this
-         code indicates that the server has detected that an
-         established security association between the client and
-         server has unexpectedly failed or been compromised.
-
-      referral (10)
-         Indicates that a referral needs to be chased to complete the
-         operation (see Section 4.1.10).
-
-      adminLimitExceeded (11)
-         Indicates that an administrative limit has been exceeded.
-
-      unavailableCriticalExtension (12)
-         Indicates a critical control is unrecognized (see Section
-         4.1.11).
-
-      confidentialityRequired (13)
-         Indicates that data confidentiality protections are required.
-
-      saslBindInProgress (14)
-         Indicates the server requires the client to send a new bind
-         request, with the same SASL mechanism, to continue the
-         authentication process (see Section 4.2).
-
-      noSuchAttribute (16)
-         Indicates that the named entry does not contain the specified
-         attribute or attribute value.
-
-      undefinedAttributeType (17)
-         Indicates that a request field contains an unrecognized
-         attribute description.
-
-      inappropriateMatching (18)
-         Indicates that an attempt was made (e.g., in an assertion) to
-         use a matching rule not defined for the attribute type
-         concerned.
-
-      constraintViolation (19)
-         Indicates that the client supplied an attribute value that
-         does not conform to the constraints placed upon it by the
-         data model.
-
-         For example, this code is returned when multiple values are
-         supplied to an attribute that has a SINGLE-VALUE constraint.
-
-
-
-Sermersheim                 Standards Track                    [Page 51]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      attributeOrValueExists (20)
-         Indicates that the client supplied an attribute or value to
-         be added to an entry, but the attribute or value already
-         exists.
-
-      invalidAttributeSyntax (21)
-         Indicates that a purported attribute value does not conform
-         to the syntax of the attribute.
-
-      noSuchObject (32)
-         Indicates that the object does not exist in the DIT.
-
-      aliasProblem (33)
-         Indicates that an alias problem has occurred.  For example,
-         the code may used to indicate an alias has been dereferenced
-         that names no object.
-
-      invalidDNSyntax (34)
-         Indicates that an LDAPDN or RelativeLDAPDN field (e.g., search
-         base, target entry, ModifyDN newrdn, etc.) of a request does
-         not conform to the required syntax or contains attribute
-         values that do not conform to the syntax of the attribute's
-         type.
-
-      aliasDereferencingProblem (36)
-         Indicates that a problem occurred while dereferencing an
-         alias.  Typically, an alias was encountered in a situation
-         where it was not allowed or where access was denied.
-
-      inappropriateAuthentication (48)
-         Indicates the server requires the client that had attempted
-         to bind anonymously or without supplying credentials to
-         provide some form of credentials.
-
-      invalidCredentials (49)
-         Indicates that the provided credentials (e.g., the user's name
-         and password) are invalid.
-
-      insufficientAccessRights (50)
-         Indicates that the client does not have sufficient access
-         rights to perform the operation.
-
-      busy (51)
-         Indicates that the server is too busy to service the
-         operation.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 52]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-      unavailable (52)
-         Indicates that the server is shutting down or a subsystem
-         necessary to complete the operation is offline.
-
-      unwillingToPerform (53)
-         Indicates that the server is unwilling to perform the
-         operation.
-
-      loopDetect (54)
-         Indicates that the server has detected an internal loop (e.g.,
-         while dereferencing aliases or chaining an operation).
-
-      namingViolation (64)
-         Indicates that the entry's name violates naming restrictions.
-
-      objectClassViolation (65)
-         Indicates that the entry violates object class restrictions.
-
-      notAllowedOnNonLeaf (66)
-         Indicates that the operation is inappropriately acting upon a
-         non-leaf entry.
-
-      notAllowedOnRDN (67)
-         Indicates that the operation is inappropriately attempting to
-         remove a value that forms the entry's relative distinguished
-         name.
-
-      entryAlreadyExists (68)
-         Indicates that the request cannot be fulfilled (added, moved,
-         or renamed) as the target entry already exists.
-
-      objectClassModsProhibited (69)
-         Indicates that an attempt to modify the object class(es) of
-         an entry's 'objectClass' attribute is prohibited.
-
-         For example, this code is returned when a client attempts to
-         modify the structural object class of an entry.
-
-      affectsMultipleDSAs (71)
-         Indicates that the operation cannot be performed as it would
-         affect multiple servers (DSAs).
-
-      other (80)
-         Indicates the server has encountered an internal error.
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 53]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-Appendix B.  Complete ASN.1 Definition
-
-   This appendix is normative.
-
-        Lightweight-Directory-Access-Protocol-V3 {1 3 6 1 1 18}
-        -- Copyright (C) The Internet Society (2006).  This version of
-        -- this ASN.1 module is part of RFC 4511; see the RFC itself
-        -- for full legal notices.
-        DEFINITIONS
-        IMPLICIT TAGS
-        EXTENSIBILITY IMPLIED ::=
-
-        BEGIN
-
-        LDAPMessage ::= SEQUENCE {
-             messageID       MessageID,
-             protocolOp      CHOICE {
-                  bindRequest           BindRequest,
-                  bindResponse          BindResponse,
-                  unbindRequest         UnbindRequest,
-                  searchRequest         SearchRequest,
-                  searchResEntry        SearchResultEntry,
-                  searchResDone         SearchResultDone,
-                  searchResRef          SearchResultReference,
-                  modifyRequest         ModifyRequest,
-                  modifyResponse        ModifyResponse,
-                  addRequest            AddRequest,
-                  addResponse           AddResponse,
-                  delRequest            DelRequest,
-                  delResponse           DelResponse,
-                  modDNRequest          ModifyDNRequest,
-                  modDNResponse         ModifyDNResponse,
-                  compareRequest        CompareRequest,
-                  compareResponse       CompareResponse,
-                  abandonRequest        AbandonRequest,
-                  extendedReq           ExtendedRequest,
-                  extendedResp          ExtendedResponse,
-                  ...,
-                  intermediateResponse  IntermediateResponse },
-             controls       [0] Controls OPTIONAL }
-
-        MessageID ::= INTEGER (0 ..  maxInt)
-
-        maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --
-
-        LDAPString ::= OCTET STRING -- UTF-8 encoded,
-                                    -- [ISO10646] characters
-
-
-
-
-Sermersheim                 Standards Track                    [Page 54]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-        LDAPOID ::= OCTET STRING -- Constrained to <numericoid>
-                                 -- [RFC4512]
-
-        LDAPDN ::= LDAPString -- Constrained to <distinguishedName>
-                              -- [RFC4514]
-
-        RelativeLDAPDN ::= LDAPString -- Constrained to <name-component>
-                                      -- [RFC4514]
-
-        AttributeDescription ::= LDAPString
-                                -- Constrained to <attributedescription>
-                                -- [RFC4512]
-
-        AttributeValue ::= OCTET STRING
-
-        AttributeValueAssertion ::= SEQUENCE {
-             attributeDesc   AttributeDescription,
-             assertionValue  AssertionValue }
-
-        AssertionValue ::= OCTET STRING
-
-        PartialAttribute ::= SEQUENCE {
-             type       AttributeDescription,
-             vals       SET OF value AttributeValue }
-
-        Attribute ::= PartialAttribute(WITH COMPONENTS {
-             ...,
-             vals (SIZE(1..MAX))})
-
-        MatchingRuleId ::= LDAPString
-
-        LDAPResult ::= SEQUENCE {
-             resultCode         ENUMERATED {
-                  success                      (0),
-                  operationsError              (1),
-                  protocolError                (2),
-                  timeLimitExceeded            (3),
-                  sizeLimitExceeded            (4),
-                  compareFalse                 (5),
-                  compareTrue                  (6),
-                  authMethodNotSupported       (7),
-                  strongerAuthRequired         (8),
-                       -- 9 reserved --
-                  referral                     (10),
-                  adminLimitExceeded           (11),
-                  unavailableCriticalExtension (12),
-                  confidentialityRequired      (13),
-                  saslBindInProgress           (14),
-
-
-
-Sermersheim                 Standards Track                    [Page 55]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-                  noSuchAttribute              (16),
-                  undefinedAttributeType       (17),
-                  inappropriateMatching        (18),
-                  constraintViolation          (19),
-                  attributeOrValueExists       (20),
-                  invalidAttributeSyntax       (21),
-                       -- 22-31 unused --
-                  noSuchObject                 (32),
-                  aliasProblem                 (33),
-                  invalidDNSyntax              (34),
-                       -- 35 reserved for undefined isLeaf --
-                  aliasDereferencingProblem    (36),
-                       -- 37-47 unused --
-                  inappropriateAuthentication  (48),
-                  invalidCredentials           (49),
-                  insufficientAccessRights     (50),
-                  busy                         (51),
-                  unavailable                  (52),
-                  unwillingToPerform           (53),
-                  loopDetect                   (54),
-                       -- 55-63 unused --
-                  namingViolation              (64),
-                  objectClassViolation         (65),
-                  notAllowedOnNonLeaf          (66),
-                  notAllowedOnRDN              (67),
-                  entryAlreadyExists           (68),
-                  objectClassModsProhibited    (69),
-                       -- 70 reserved for CLDAP --
-                  affectsMultipleDSAs          (71),
-                       -- 72-79 unused --
-                  other                        (80),
-                  ...  },
-             matchedDN          LDAPDN,
-             diagnosticMessage  LDAPString,
-             referral           [3] Referral OPTIONAL }
-
-        Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI
-
-        URI ::= LDAPString     -- limited to characters permitted in
-                               -- URIs
-
-        Controls ::= SEQUENCE OF control Control
-
-        Control ::= SEQUENCE {
-             controlType             LDAPOID,
-             criticality             BOOLEAN DEFAULT FALSE,
-             controlValue            OCTET STRING OPTIONAL }
-
-
-
-
-Sermersheim                 Standards Track                    [Page 56]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-        BindRequest ::= [APPLICATION 0] SEQUENCE {
-             version                 INTEGER (1 ..  127),
-             name                    LDAPDN,
-             authentication          AuthenticationChoice }
-
-        AuthenticationChoice ::= CHOICE {
-             simple                  [0] OCTET STRING,
-                                     -- 1 and 2 reserved
-             sasl                    [3] SaslCredentials,
-             ...  }
-
-        SaslCredentials ::= SEQUENCE {
-             mechanism               LDAPString,
-             credentials             OCTET STRING OPTIONAL }
-
-        BindResponse ::= [APPLICATION 1] SEQUENCE {
-             COMPONENTS OF LDAPResult,
-             serverSaslCreds    [7] OCTET STRING OPTIONAL }
-
-        UnbindRequest ::= [APPLICATION 2] NULL
-
-        SearchRequest ::= [APPLICATION 3] SEQUENCE {
-             baseObject      LDAPDN,
-             scope           ENUMERATED {
-                  baseObject              (0),
-                  singleLevel             (1),
-                  wholeSubtree            (2),
-                  ...  },
-             derefAliases    ENUMERATED {
-                  neverDerefAliases       (0),
-                  derefInSearching        (1),
-                  derefFindingBaseObj     (2),
-                  derefAlways             (3) },
-             sizeLimit       INTEGER (0 ..  maxInt),
-             timeLimit       INTEGER (0 ..  maxInt),
-             typesOnly       BOOLEAN,
-             filter          Filter,
-             attributes      AttributeSelection }
-
-        AttributeSelection ::= SEQUENCE OF selector LDAPString
-                       -- The LDAPString is constrained to
-                       -- <attributeSelector> in Section 4.5.1.8
-
-        Filter ::= CHOICE {
-             and             [0] SET SIZE (1..MAX) OF filter Filter,
-             or              [1] SET SIZE (1..MAX) OF filter Filter,
-             not             [2] Filter,
-             equalityMatch   [3] AttributeValueAssertion,
-
-
-
-Sermersheim                 Standards Track                    [Page 57]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-             substrings      [4] SubstringFilter,
-             greaterOrEqual  [5] AttributeValueAssertion,
-             lessOrEqual     [6] AttributeValueAssertion,
-             present         [7] AttributeDescription,
-             approxMatch     [8] AttributeValueAssertion,
-             extensibleMatch [9] MatchingRuleAssertion,
-             ...  }
-
-        SubstringFilter ::= SEQUENCE {
-             type           AttributeDescription,
-             substrings     SEQUENCE SIZE (1..MAX) OF substring CHOICE {
-                  initial [0] AssertionValue,  -- can occur at most once
-                  any     [1] AssertionValue,
-                  final   [2] AssertionValue } -- can occur at most once
-             }
-
-        MatchingRuleAssertion ::= SEQUENCE {
-             matchingRule    [1] MatchingRuleId OPTIONAL,
-             type            [2] AttributeDescription OPTIONAL,
-             matchValue      [3] AssertionValue,
-             dnAttributes    [4] BOOLEAN DEFAULT FALSE }
-
-        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
-             objectName      LDAPDN,
-             attributes      PartialAttributeList }
-
-        PartialAttributeList ::= SEQUENCE OF
-                             partialAttribute PartialAttribute
-
-        SearchResultReference ::= [APPLICATION 19] SEQUENCE
-                                  SIZE (1..MAX) OF uri URI
-
-        SearchResultDone ::= [APPLICATION 5] LDAPResult
-
-        ModifyRequest ::= [APPLICATION 6] SEQUENCE {
-             object          LDAPDN,
-             changes         SEQUENCE OF change SEQUENCE {
-                  operation       ENUMERATED {
-                       add     (0),
-                       delete  (1),
-                       replace (2),
-                       ...  },
-                  modification    PartialAttribute } }
-
-        ModifyResponse ::= [APPLICATION 7] LDAPResult
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 58]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-        AddRequest ::= [APPLICATION 8] SEQUENCE {
-             entry           LDAPDN,
-             attributes      AttributeList }
-
-        AttributeList ::= SEQUENCE OF attribute Attribute
-
-        AddResponse ::= [APPLICATION 9] LDAPResult
-
-        DelRequest ::= [APPLICATION 10] LDAPDN
-
-        DelResponse ::= [APPLICATION 11] LDAPResult
-
-        ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
-             entry           LDAPDN,
-             newrdn          RelativeLDAPDN,
-             deleteoldrdn    BOOLEAN,
-             newSuperior     [0] LDAPDN OPTIONAL }
-
-        ModifyDNResponse ::= [APPLICATION 13] LDAPResult
-
-        CompareRequest ::= [APPLICATION 14] SEQUENCE {
-             entry           LDAPDN,
-             ava             AttributeValueAssertion }
-
-        CompareResponse ::= [APPLICATION 15] LDAPResult
-
-        AbandonRequest ::= [APPLICATION 16] MessageID
-
-        ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
-             requestName      [0] LDAPOID,
-             requestValue     [1] OCTET STRING OPTIONAL }
-
-        ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
-             COMPONENTS OF LDAPResult,
-             responseName     [10] LDAPOID OPTIONAL,
-             responseValue    [11] OCTET STRING OPTIONAL }
-
-        IntermediateResponse ::= [APPLICATION 25] SEQUENCE {
-             responseName     [0] LDAPOID OPTIONAL,
-             responseValue    [1] OCTET STRING OPTIONAL }
-
-        END
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 59]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-Appendix C.  Changes
-
-   This appendix is non-normative.
-
-   This appendix summarizes substantive changes made to RFC 2251, RFC
-   2830, and RFC 3771.
-
-C.1.  Changes Made to RFC 2251
-
-   This section summarizes the substantive changes made to Sections 1,
-   2, 3.1, and 4, and the remainder of RFC 2251.  Readers should
-   consult [RFC4512] and [RFC4513] for summaries of changes to other
-   sections.
-
-C.1.1.  Section 1 (Status of this Memo)
-
-   - Removed IESG note.  Post publication of RFC 2251, mandatory LDAP
-     authentication mechanisms have been standardized which are
-     sufficient to remove this note.  See [RFC4513] for authentication
-     mechanisms.
-
-C.1.2.  Section 3.1 (Protocol Model) and others
-
-   - Removed notes giving history between LDAP v1, v2, and v3.  Instead,
-     added sufficient language so that this document can stand on its
-     own.
-
-C.1.3.  Section 4 (Elements of Protocol)
-
-   - Clarified where the extensibility features of ASN.1 apply to the
-     protocol.  This change affected various ASN.1 types by the
-     inclusion of ellipses (...) to certain elements.
-   - Removed the requirement that servers that implement version 3 or
-     later MUST provide the 'supportedLDAPVersion' attribute.  This
-     statement provided no interoperability advantages.
-
-C.1.4.  Section 4.1.1 (Message Envelope)
-
-   - There was a mandatory requirement for the server to return a
-     Notice of Disconnection and drop the transport connection when a
-     PDU is malformed in a certain way.  This has been updated such that
-     the server SHOULD return the Notice of Disconnection, and it MUST
-     terminate the LDAP Session.
-
-C.1.5.  Section 4.1.1.1 (Message ID)
-
-   - Required that the messageID of requests MUST be non-zero as the
-     zero is reserved for Notice of Disconnection.
-
-
-
-Sermersheim                 Standards Track                    [Page 60]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - Specified when it is and isn't appropriate to return an already
-     used messageID.  RFC 2251 accidentally imposed synchronous server
-     behavior in its wording of this.
-
-C.1.6.  Section 4.1.2 (String Types)
-
-   - Stated that LDAPOID is constrained to <numericoid> from [RFC4512].
-
-C.1.7.  Section 4.1.5.1 (Binary Option) and others
-
-   - Removed the Binary Option from the specification.  There are
-     numerous interoperability problems associated with this method of
-     alternate attribute type encoding.  Work to specify a suitable
-     replacement is ongoing.
-
-C.1.8.  Section 4.1.8 (Attribute)
-
-   - Combined the definitions of PartialAttribute and Attribute here,
-     and defined Attribute in terms of PartialAttribute.
-
-C.1.9.  Section 4.1.10 (Result Message)
-
-   - Renamed "errorMessage" to "diagnosticMessage" as it is allowed to
-     be sent for non-error results.
-   - Moved some language into Appendix A, and referred the reader there.
-   - Allowed matchedDN to be present for other result codes than those
-     listed in RFC 2251.
-   - Renamed the code "strongAuthRequired" to "strongerAuthRequired" to
-     clarify that this code may often be returned to indicate that a
-     stronger authentication is needed to perform a given operation.
-
-C.1.10.  Section 4.1.11 (Referral)
-
-   - Defined referrals in terms of URIs rather than URLs.
-   - Removed the requirement that all referral URIs MUST be equally
-     capable of progressing the operation.  The statement was ambiguous
-     and provided no instructions on how to carry it out.
-   - Added the requirement that clients MUST NOT loop between servers.
-   - Clarified the instructions for using LDAPURLs in referrals, and in
-     doing so added a recommendation that the scope part be present.
-   - Removed imperatives which required clients to use URLs in specific
-     ways to progress an operation.  These did nothing for
-     interoperability.
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 61]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-C.1.11.  Section 4.1.12 (Controls)
-
-   - Specified how control values defined in terms of ASN.1 are to be
-     encoded.
-   - Noted that the criticality field is only applied to request
-     messages (except UnbindRequest), and must be ignored when present
-     on response messages and UnbindRequest.
-   - Specified that non-critical controls may be ignored at the
-     server's discretion.  There was confusion in the original wording
-     which led some to believe that recognized controls may not be
-     ignored as long as they were associated with a proper request.
-   - Added language regarding combinations of controls and the ordering
-     of controls on a message.
-   - Specified that when the semantics of the combination of controls
-     is undefined or unknown, it results in a protocolError.
-   - Changed "The server MUST be prepared" to "Implementations MUST be
-     prepared" in paragraph 8 to reflect that both client and server
-     implementations must be able to handle this (as both parse
-     controls).
-
-C.1.12.  Section 4.2 (Bind Operation)
-
-   - Mandated that servers return protocolError when the version is not
-     supported.
-   - Disambiguated behavior when the simple authentication is used, the
-     name is empty, and the password is non-empty.
-   - Required servers to not dereference aliases for Bind.  This was
-     added for consistency with other operations and to help ensure
-     data consistency.
-   - Required that textual passwords be transferred as UTF-8 encoded
-     Unicode, and added recommendations on string preparation.  This was
-     to help ensure interoperability of passwords being sent from
-     different clients.
-
-C.1.13.  Section 4.2.1 (Sequencing of the Bind Request)
-
-   - This section was largely reorganized for readability, and language
-     was added to clarify the authentication state of failed and
-     abandoned Bind operations.
-   - Removed: "If a SASL transfer encryption or integrity mechanism has
-     been negotiated, that mechanism does not support the changing of
-     credentials from one identity to another, then the client MUST
-     instead establish a new connection."
-     If there are dependencies between multiple negotiations of a
-     particular SASL mechanism, the technical specification for that
-     SASL mechanism details how applications are to deal with them.
-     LDAP should not require any special handling.
-   - Dropped MUST imperative in paragraph 3 to align with [RFC2119].
-
-
-
-Sermersheim                 Standards Track                    [Page 62]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-   - Mandated that clients not send non-Bind operations while a Bind is
-     in progress, and suggested that servers not process them if they
-     are received.  This is needed to ensure proper sequencing of the
-     Bind in relationship to other operations.
-
-C.1.14.  Section 4.2.3 (Bind Response)
-
-   - Moved most error-related text to Appendix A, and added text
-     regarding certain errors used in conjunction with the Bind
-     operation.
-   - Prohibited the server from specifying serverSaslCreds when not
-     appropriate.
-
-C.1.15.  Section 4.3 (Unbind Operation)
-
-   - Specified that both peers are to cease transmission and terminate
-     the LDAP session for the Unbind operation.
-
-C.1.16.  Section 4.4 (Unsolicited Notification)
-
-   - Added instructions for future specifications of Unsolicited
-     Notifications.
-
-C.1.17.  Section 4.5.1 (Search Request)
-
-   - SearchRequest attributes is now defined as an AttributeSelection
-     type rather than AttributeDescriptionList, and an ABNF is
-     provided.
-   - SearchRequest attributes may contain duplicate attribute
-     descriptions.  This was previously prohibited.  Now servers are
-     instructed to ignore subsequent names when they are duplicated.
-     This was relaxed in order to allow different short names and also
-     OIDs to be requested for an attribute.
-   - The present search filter now evaluates to Undefined when the
-     specified attribute is not known to the server.  It used to
-     evaluate to FALSE, which caused behavior inconsistent with what
-     most would expect, especially when the 'not' operator was used.
-   - The Filter choice SubstringFilter substrings type is now defined
-     with a lower bound of 1.
-   - The SubstringFilter substrings 'initial, 'any', and 'final' types
-     are now AssertionValue rather than LDAPString.  Also, added
-     imperatives stating that 'initial' (if present) must be listed
-     first, and 'final' (if present) must be listed last.
-   - Disambiguated the semantics of the derefAliases choices.  There was
-     question as to whether derefInSearching applied to the base object
-     in a wholeSubtree Search.
-   - Added instructions for equalityMatch, substrings, greaterOrEqual,
-     lessOrEqual, and approxMatch.
-
-
-
-Sermersheim                 Standards Track                    [Page 63]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-
-C.1.18.  Section 4.5.2 (Search Result)
-
-   - Recommended that servers not use attribute short names when it
-     knows they are ambiguous or may cause interoperability problems.
-   - Removed all mention of ExtendedResponse due to lack of
-     implementation.
-
-C.1.19.  Section 4.5.3 (Continuation References in the Search Result)
-
-   - Made changes similar to those made to Section 4.1.11.
-
-C.1.20.  Section 4.5.3.1 (Example)
-
-   - Fixed examples to adhere to changes made to Section 4.5.3.
-
-C.1.21.  Section 4.6 (Modify Operation)
-
-   - Replaced AttributeTypeAndValues with Attribute as they are
-     equivalent.
-   - Specified the types of modification changes that might
-     temporarily violate schema.  Some readers were under the impression
-     that any temporary schema violation was allowed.
-
-C.1.22.  Section 4.7 (Add Operation)
-
-   - Aligned Add operation with X.511 in that the attributes of the RDN
-     are used in conjunction with the listed attributes to create the
-     entry.  Previously, Add required that the distinguished values be
-     present in the listed attributes.
-   - Removed requirement that the objectClass attribute MUST be
-     specified as some DSE types do not require this attribute.
-     Instead, generic wording was added, requiring the added entry to
-     adhere to the data model.
-   - Removed recommendation regarding placement of objects.  This is
-     covered in the data model document.
-
-C.1.23.  Section 4.9 (Modify DN Operation)
-
-   - Required servers to not dereference aliases for Modify DN.  This
-     was added for consistency with other operations and to help ensure
-     data consistency.
-   - Allow Modify DN to fail when moving between naming contexts.
-   - Specified what happens when the attributes of the newrdn are not
-     present on the entry.
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 64]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-C.1.24.  Section 4.10 (Compare Operation)
-
-   - Specified that compareFalse means that the Compare took place and
-     the result is false.  There was confusion that led people to
-     believe that an Undefined match resulted in compareFalse.
-   - Required servers to not dereference aliases for Compare.  This was
-     added for consistency with other operations and to help ensure
-     data consistency.
-
-C.1.25.  Section 4.11 (Abandon Operation)
-
-   - Explained that since Abandon returns no response, clients should
-     not use it if they need to know the outcome.
-   - Specified that Abandon and Unbind cannot be abandoned.
-
-C.1.26.  Section 4.12 (Extended Operation)
-
-   - Specified how values of Extended operations defined in terms of
-     ASN.1 are to be encoded.
-   - Added instructions on what Extended operation specifications
-     consist of.
-   - Added a recommendation that servers advertise supported Extended
-     operations.
-
-C.1.27.  Section 5.2 (Transfer Protocols)
-
-   - Moved referral-specific instructions into referral-related
-     sections.
-
-C.1.28.  Section 7 (Security Considerations)
-
-   - Reworded notes regarding SASL not protecting certain aspects of
-     the LDAP Bind messages.
-   - Noted that Servers are encouraged to prevent directory
-     modifications by clients that have authenticated anonymously
-     [RFC4513].
-   - Added a note regarding the possibility of changes to security
-     factors (authentication, authorization, and data confidentiality).
-   - Warned against following referrals that may have been injected in
-     the data stream.
-   - Noted that servers should protect information equally, whether in
-     an error condition or not, and mentioned matchedDN,
-     diagnosticMessage, and resultCodes specifically.
-   - Added a note regarding malformed and long encodings.
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 65]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-C.1.29.  Appendix A (Complete ASN.1 Definition)
-
-   - Added "EXTENSIBILITY IMPLIED" to ASN.1 definition.
-   - Removed AttributeType.  It is not used.
-
-C.2.  Changes Made to RFC 2830
-
-   This section summarizes the substantive changes made to Sections of
-   RFC 2830.  Readers should consult [RFC4513] for summaries of changes
-   to other sections.
-
-C.2.1.  Section 2.3 (Response other than "success")
-
-   - Removed wording indicating that referrals can be returned from
-     StartTLS.
-   - Removed requirement that only a narrow set of result codes can be
-     returned.  Some result codes are required in certain scenarios, but
-     any other may be returned if appropriate.
-   - Removed requirement that the ExtendedResponse.responseName MUST be
-     present.  There are circumstances where this is impossible, and
-     requiring this is at odds with language in Section 4.12.
-
-C.2.1.  Section 4 (Closing a TLS Connection)
-
-   - Reworded most of this section to align with definitions of the
-     LDAP protocol layers.
-   - Removed instructions on abrupt closure as this is covered in other
-     areas of the document (specifically, Section 5.3)
-
-C.3.  Changes Made to RFC 3771
-
-   - Rewrote to fit into this document.  In general, semantics were
-     preserved.  Supporting and background language seen as redundant
-     due to its presence in this document was omitted.
-
-   - Specified that Intermediate responses to a request may be of
-     different types, and one of the response types may be specified to
-     have no response value.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 66]
-
-RFC 4511                         LDAPv3                        June 2006
-
-
-Editor's Address
-
-   Jim Sermersheim
-   Novell, Inc.
-   1800 South Novell Place
-   Provo, Utah 84606, USA
-
-   Phone: +1 801 861-3088
-   EMail: jimse at novell.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 67]
-
-RFC 4511                         LDAPv3                        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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Sermersheim                 Standards Track                    [Page 68]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4512.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4512.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4512.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,2915 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                        K. Zeilenga
-Request for Comments: 4512                           OpenLDAP Foundation
-Obsoletes: 2251, 2252, 2256, 3674                              June 2006
-Category: Standards Track
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                      Directory Information Models
-
-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 Lightweight Directory Access Protocol (LDAP) is an Internet
-   protocol for accessing distributed directory services that act in
-   accordance with X.500 data and service models.  This document
-   describes the X.500 Directory Information Models, as used in LDAP.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-      1.1. Relationship to Other LDAP Specifications ..................3
-      1.2. Relationship to X.501 ......................................4
-      1.3. Conventions ................................................4
-      1.4. Common ABNF Productions ....................................4
-   2. Model of Directory User Information .............................6
-      2.1. The Directory Information Tree .............................7
-      2.2. Structure of an Entry ......................................7
-      2.3. Naming of Entries ..........................................8
-      2.4. Object Classes .............................................9
-      2.5. Attribute Descriptions ....................................12
-      2.6. Alias Entries .............................................16
-   3. Directory Administrative and Operational Information ...........17
-      3.1. Subtrees ..................................................17
-      3.2. Subentries ................................................18
-      3.3. The 'objectClass' attribute ...............................18
-      3.4. Operational Attributes ....................................19
-   4. Directory Schema ...............................................22
-      4.1. Schema Definitions ........................................23
-      4.2. Subschema Subentries ......................................32
-      4.3. 'extensibleObject' object class ...........................35
-      4.4. Subschema Discovery .......................................35
-   5. DSA (Server) Informational Model ...............................36
-      5.1. Server-Specific Data Requirements .........................36
-   6. Other Considerations ...........................................40
-      6.1. Preservation of User Information ..........................40
-      6.2. Short Names ...............................................41
-      6.3. Cache and Shadowing .......................................41
-   7. Implementation Guidelines ......................................42
-      7.1. Server Guidelines .........................................42
-      7.2. Client Guidelines .........................................42
-   8. Security Considerations ........................................43
-   9. IANA Considerations ............................................43
-   10. Acknowledgements ..............................................44
-   11. Normative References ..........................................45
-   Appendix A. Changes ...............................................47
-      A.1. Changes to RFC 2251 .......................................47
-      A.2. Changes to RFC 2252 .......................................49
-      A.3. Changes to RFC 2256 .......................................50
-      A.4. Changes to RFC 3674 .......................................51
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-1.  Introduction
-
-   This document discusses the X.500 Directory Information Models
-   [X.501], as used by the Lightweight Directory Access Protocol (LDAP)
-   [RFC4510].
-
-   The Directory is "a collection of open systems cooperating to provide
-   directory services" [X.500].  The information held in the Directory
-   is collectively known as the Directory Information Base (DIB).  A
-   Directory user, which may be a human or other entity, accesses the
-   Directory through a client (or Directory User Agent (DUA)).  The
-   client, on behalf of the directory user, interacts with one or more
-   servers (or Directory System Agents (DSA)).  A server holds a
-   fragment of the DIB.
-
-   The DIB contains two classes of information:
-
-      1) user information (e.g., information provided and administrated
-         by users).  Section 2 describes the Model of User Information.
-
-      2) administrative and operational information (e.g., information
-         used to administer and/or operate the directory).  Section 3
-         describes the model of Directory Administrative and Operational
-         Information.
-
-   These two models, referred to as the generic Directory Information
-   Models, describe how information is represented in the Directory.
-   These generic models provide a framework for other information
-   models.  Section 4 discusses the subschema information model and
-   subschema discovery.  Section 5 discusses the DSA (Server)
-   Informational Model.
-
-   Other X.500 information models (such as access control distribution
-   knowledge and replication knowledge information models) may be
-   adapted for use in LDAP.  Specification of how these models apply to
-   LDAP is left to future documents.
-
-1.1.  Relationship to Other LDAP Specifications
-
-   This document is a integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.
-
-   This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as
-   portions of Sections 4 and 6.  Appendix A.1 summarizes changes to
-   these sections.  The remainder of RFC 2251 is obsoleted by the
-   [RFC4511], [RFC4513], and [RFC4510] documents.
-
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   This document obsoletes RFC 2252, Sections 4, 5, and 7.  Appendix A.2
-   summarizes changes to these sections.  The remainder of RFC 2252 is
-   obsoleted by [RFC4517].
-
-   This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2.
-   Appendix A.3 summarizes changes to these sections.  The remainder of
-   RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
-
-   This document obsoletes RFC 3674 in its entirety.  Appendix A.4
-   summarizes changes since RFC 3674.
-
-1.2.  Relationship to X.501
-
-   This document includes material, with and without adaptation, from
-   [X.501] as necessary to describe this protocol.  These adaptations
-   (and any other differences herein) apply to this protocol, and only
-   this protocol.
-
-1.3.  Conventions
-
-   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].
-
-   Schema definitions are provided using LDAP description formats (as
-   defined in Section 4.1).  Definitions provided here are formatted
-   (line wrapped) for readability.  Matching rules and LDAP syntaxes
-   referenced in these definitions are specified in [RFC4517].
-
-1.4.  Common ABNF Productions
-
-   A number of syntaxes in this document are described using Augmented
-   Backus-Naur Form (ABNF) [RFC4234].  These syntaxes (as well as a
-   number of syntaxes defined in other documents) rely on the following
-   common productions:
-
-      keystring = leadkeychar *keychar
-      leadkeychar = ALPHA
-      keychar = ALPHA / DIGIT / HYPHEN
-      number  = DIGIT / ( LDIGIT 1*DIGIT )
-
-      ALPHA   = %x41-5A / %x61-7A   ; "A"-"Z" / "a"-"z"
-      DIGIT   = %x30 / LDIGIT       ; "0"-"9"
-      LDIGIT  = %x31-39             ; "1"-"9"
-      HEX     = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
-
-      SP      = 1*SPACE  ; one or more " "
-      WSP     = 0*SPACE  ; zero or more " "
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-      NULL    = %x00 ; null (0)
-      SPACE   = %x20 ; space (" ")
-      DQUOTE  = %x22 ; quote (""")
-      SHARP   = %x23 ; octothorpe (or sharp sign) ("#")
-      DOLLAR  = %x24 ; dollar sign ("$")
-      SQUOTE  = %x27 ; single quote ("'")
-      LPAREN  = %x28 ; left paren ("(")
-      RPAREN  = %x29 ; right paren (")")
-      PLUS    = %x2B ; plus sign ("+")
-      COMMA   = %x2C ; comma (",")
-      HYPHEN  = %x2D ; hyphen ("-")
-      DOT     = %x2E ; period (".")
-      SEMI    = %x3B ; semicolon (";")
-      LANGLE  = %x3C ; left angle bracket ("<")
-      EQUALS  = %x3D ; equals sign ("=")
-      RANGLE  = %x3E ; right angle bracket (">")
-      ESC     = %x5C ; backslash ("\")
-      USCORE  = %x5F ; underscore ("_")
-      LCURLY  = %x7B ; left curly brace "{"
-      RCURLY  = %x7D ; right curly brace "}"
-
-      ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
-      UTF8    = UTF1 / UTFMB
-      UTFMB   = UTF2 / UTF3 / UTF4
-      UTF0    = %x80-BF
-      UTF1    = %x00-7F
-      UTF2    = %xC2-DF UTF0
-      UTF3    = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
-                %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
-      UTF4    = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
-                %xF4 %x80-8F 2(UTF0)
-
-      OCTET   = %x00-FF ; Any octet (8-bit data unit)
-
-   Object identifiers (OIDs) [X.680] are represented in LDAP using a
-   dot-decimal format conforming to the ABNF:
-
-      numericoid = number 1*( DOT number )
-
-   Short names, also known as descriptors, are used as more readable
-   aliases for object identifiers.  Short names are case insensitive and
-   conform to the ABNF:
-
-      descr = keystring
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Where either an object identifier or a short name may be specified,
-   the following production is used:
-
-      oid = descr / numericoid
-
-   While the <descr> form is generally preferred when the usage is
-   restricted to short names referring to object identifiers that
-   identify like kinds of objects (e.g., attribute type descriptions,
-   matching rule descriptions, object class descriptions), the
-   <numericoid> form should be used when the object identifiers may
-   identify multiple kinds of objects or when an unambiguous short name
-   (descriptor) is not available.
-
-   Implementations SHOULD treat short names (descriptors) used in an
-   ambiguous manner (as discussed above) as unrecognized.
-
-   Short Names (descriptors) are discussed further in Section 6.2.
-
-2.  Model of Directory User Information
-
-   As [X.501] states:
-
-      The purpose of the Directory is to hold, and provide access to,
-      information about objects of interest (objects) in some 'world'.
-      An object can be anything which is identifiable (can be named).
-
-      An object class is an identified family of objects, or conceivable
-      objects, which share certain characteristics.  Every object
-      belongs to at least one class.  An object class may be a subclass
-      of other object classes, in which case the members of the former
-      class, the subclass, are also considered to be members of the
-      latter classes, the superclasses.  There may be subclasses of
-      subclasses, etc., to an arbitrary depth.
-
-   A directory entry, a named collection of information, is the basic
-   unit of information held in the Directory.  There are multiple kinds
-   of directory entries.
-
-   An object entry represents a particular object.  An alias entry
-   provides alternative naming.  A subentry holds administrative and/or
-   operational information.
-
-   The set of entries representing the DIB are organized hierarchically
-   in a tree structure known as the Directory Information Tree (DIT).
-
-   Section 2.1 describes the Directory Information Tree.
-   Section 2.2 discusses the structure of entries.
-   Section 2.3 discusses naming of entries.
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Section 2.4 discusses object classes.
-   Section 2.5 discusses attribute descriptions.
-   Section 2.6 discusses alias entries.
-
-2.1.  The Directory Information Tree
-
-   As noted above, the DIB is composed of a set of entries organized
-   hierarchically in a tree structure known as the Directory Information
-   Tree (DIT); specifically, a tree where vertices are the entries.
-
-   The arcs between vertices define relations between entries.  If an
-   arc exists from X to Y, then the entry at X is the immediate superior
-   of Y, and Y is the immediate subordinate of X.  An entry's superiors
-   are the entry's immediate superior and its superiors.  An entry's
-   subordinates are all of its immediate subordinates and their
-   subordinates.
-
-   Similarly, the superior/subordinate relationship between object
-   entries can be used to derive a relation between the objects they
-   represent.  DIT structure rules can be used to govern relationships
-   between objects.
-
-   Note: An entry's immediate superior is also known as the entry's
-         parent, and an entry's immediate subordinate is also known as
-         the entry's child.  Entries that have the same parent are known
-         as siblings.
-
-2.2.  Structure of an Entry
-
-   An entry consists of a set of attributes that hold information about
-   the object that the entry represents.  Some attributes represent user
-   information and are called user attributes.  Other attributes
-   represent operational and/or administrative information and are
-   called operational attributes.
-
-   An attribute is an attribute description (a type and zero or more
-   options) with one or more associated values.  An attribute is often
-   referred to by its attribute description.  For example, the
-   'givenName' attribute is the attribute that consists of the attribute
-   description 'givenName' (the 'givenName' attribute type [RFC4519] and
-   zero options) and one or more associated values.
-
-   The attribute type governs whether the attribute can have multiple
-   values, the syntax and matching rules used to construct and compare
-   values of that attribute, and other functions.  Options indicate
-   subtypes and other functions.
-
-   Attribute values conform to the defined syntax of the attribute type.
-
-
-
-Zeilenga                    Standards Track                     [Page 7]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   No two values of an attribute may be equivalent.  Two values are
-   considered equivalent if and only if they would match according to
-   the equality matching rule of the attribute type.  Or, if the
-   attribute type is defined with no equality matching rule, two values
-   are equivalent if and only if they are identical.  (See 2.5.1 for
-   other restrictions.)
-
-   For example, a 'givenName' attribute can have more than one value,
-   they must be Directory Strings, and they are case insensitive.  A
-   'givenName' attribute cannot hold both "John" and "JOHN", as these
-   are equivalent values per the equality matching rule of the attribute
-   type.
-
-   Additionally, no attribute is to have a value that is not equivalent
-   to itself.  For example, the 'givenName' attribute cannot have as a
-   value a directory string that includes the REPLACEMENT CHARACTER
-   (U+FFFD) code point, as matching involving that directory string is
-   Undefined per this attribute's equality matching rule.
-
-   When an attribute is used for naming of the entry, one and only one
-   value of the attribute is used in forming the Relative Distinguished
-   Name.  This value is known as a distinguished value.
-
-2.3.  Naming of Entries
-
-2.3.1.  Relative Distinguished Names
-
-   Each entry is named relative to its immediate superior.  This
-   relative name, known as its Relative Distinguished Name (RDN)
-   [X.501], is composed of an unordered set of one or more attribute
-   value assertions (AVA) consisting of an attribute description with
-   zero options and an attribute value.  These AVAs are chosen to match
-   attribute values (each a distinguished value) of the entry.
-
-   An entry's relative distinguished name must be unique among all
-   immediate subordinates of the entry's immediate superior (i.e., all
-   siblings).
-
-   The following are examples of string representations of RDNs
-   [RFC4514]:
-
-      UID=12345
-      OU=Engineering
-      CN=Kurt Zeilenga+L=Redwood Shores
-
-   The last is an example of a multi-valued RDN; that is, an RDN
-   composed of multiple AVAs.
-
-
-
-
-Zeilenga                    Standards Track                     [Page 8]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-2.3.2.  Distinguished Names
-
-   An entry's fully qualified name, known as its Distinguished Name (DN)
-   [X.501], is the concatenation of its RDN and its immediate superior's
-   DN.  A Distinguished Name unambiguously refers to an entry in the
-   tree.  The following are examples of string representations of DNs
-   [RFC4514]:
-
-      UID=nobody at example.com,DC=example,DC=com
-      CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
-
-2.3.3.  Alias Names
-
-   An alias, or alias name, is "an name for an object, provided by the
-   use of alias entries" [X.501].  Alias entries are described in
-   Section 2.6.
-
-2.4.  Object Classes
-
-   An object class is "an identified family of objects (or conceivable
-   objects) that share certain characteristics" [X.501].
-
-   As defined in [X.501]:
-
-      Object classes are used in the Directory for a number of purposes:
-
-        - describing and categorizing objects and the entries that
-          correspond to these objects;
-
-        - where appropriate, controlling the operation of the Directory;
-
-        - regulating, in conjunction with DIT structure rule
-          specifications, the position of entries in the DIT;
-
-        - regulating, in conjunction with DIT content rule
-          specifications, the attributes that are contained in entries;
-
-        - identifying classes of entry that are to be associated with a
-          particular policy by the appropriate administrative authority.
-
-      An object class (a subclass) may be derived from an object class
-      (its direct superclass) which is itself derived from an even more
-      generic object class.  For structural object classes, this process
-      stops at the most generic object class, 'top' (defined in Section
-      2.4.1).  An ordered set of superclasses up to the most superior
-      object class of an object class is its superclass chain.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 9]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-      An object class may be derived from two or more direct
-      superclasses (superclasses not part of the same superclass chain).
-      This feature of subclassing is termed multiple inheritance.
-
-   Each object class identifies the set of attributes required to be
-   present in entries belonging to the class and the set of attributes
-   allowed to be present in entries belonging to the class.  As an entry
-   of a class must meet the requirements of each class it belongs to, it
-   can be said that an object class inherits the sets of allowed and
-   required attributes from its superclasses.  A subclass can identify
-   an attribute allowed by its superclass as being required.  If an
-   attribute is a member of both sets, it is required to be present.
-
-   Each object class is defined to be one of three kinds of object
-   classes: Abstract, Structural, or Auxiliary.
-
-   Each object class is identified by an object identifier (OID) and,
-   optionally, one or more short names (descriptors).
-
-2.4.1.  Abstract Object Classes
-
-   An abstract object class, as the name implies, provides a base of
-   characteristics from which other object classes can be defined to
-   inherit from.  An entry cannot belong to an abstract object class
-   unless it belongs to a structural or auxiliary class that inherits
-   from that abstract class.
-
-   Abstract object classes cannot derive from structural or auxiliary
-   object classes.
-
-   All structural object classes derive (directly or indirectly) from
-   the 'top' abstract object class.  Auxiliary object classes do not
-   necessarily derive from 'top'.
-
-   The following is the object class definition (see Section 4.1.1) for
-   the 'top' object class:
-
-      ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
-
-   All entries belong to the 'top' abstract object class.
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 10]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-2.4.2.  Structural Object Classes
-
-   As stated in [X.501]:
-
-      An object class defined for use in the structural specification of
-      the DIT is termed a structural object class.  Structural object
-      classes are used in the definition of the structure of the names
-      of the objects for compliant entries.
-
-      An object or alias entry is characterized by precisely one
-      structural object class superclass chain which has a single
-      structural object class as the most subordinate object class.
-      This structural object class is referred to as the structural
-      object class of the entry.
-
-      Structural object classes are related to associated entries:
-
-        - an entry conforming to a structural object class shall
-          represent the real-world object constrained by the object
-          class;
-
-        - DIT structure rules only refer to structural object classes;
-          the structural object class of an entry is used to specify the
-          position of the entry in the DIT;
-
-        - the structural object class of an entry is used, along with an
-          associated DIT content rule, to control the content of an
-          entry.
-
-      The structural object class of an entry shall not be changed.
-
-   Each structural object class is a (direct or indirect) subclass of
-   the 'top' abstract object class.
-
-   Structural object classes cannot subclass auxiliary object classes.
-
-   Each entry is said to belong to its structural object class as well
-   as all classes in its structural object class's superclass chain.
-
-2.4.3.  Auxiliary Object Classes
-
-   Auxiliary object classes are used to augment the characteristics of
-   entries.  They are commonly used to augment the sets of attributes
-   required and allowed to be present in an entry.  They can be used to
-   describe entries or classes of entries.
-
-   Auxiliary object classes cannot subclass structural object classes.
-
-
-
-
-Zeilenga                    Standards Track                    [Page 11]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   An entry can belong to any subset of the set of auxiliary object
-   classes allowed by the DIT content rule associated with the
-   structural object class of the entry.  If no DIT content rule is
-   associated with the structural object class of the entry, the entry
-   cannot belong to any auxiliary object class.
-
-   The set of auxiliary object classes that an entry belongs to can
-   change over time.
-
-2.5.  Attribute Descriptions
-
-   An attribute description is composed of an attribute type (see
-   Section 2.5.1) and a set of zero or more attribute options (see
-   Section 2.5.2).
-
-   An attribute description is represented by the ABNF:
-
-      attributedescription = attributetype options
-      attributetype = oid
-      options = *( SEMI option )
-      option = 1*keychar
-
-   where <attributetype> identifies the attribute type and each <option>
-   identifies an attribute option.  Both <attributetype> and <option>
-   productions are case insensitive.  The order in which <option>s
-   appear is irrelevant.  That is, any two <attributedescription>s that
-   consist of the same <attributetype> and same set of <option>s are
-   equivalent.
-
-   Examples of valid attribute descriptions:
-
-      2.5.4.0
-      cn;lang-de;lang-en
-      owner
-
-   An attribute description with an unrecognized attribute type is to be
-   treated as unrecognized.  Servers SHALL treat an attribute
-   description with an unrecognized attribute option as unrecognized.
-   Clients MAY treat an unrecognized attribute option as a tagging
-   option (see Section 2.5.2.1).
-
-   All attributes of an entry must have distinct attribute descriptions.
-
-2.5.1.  Attribute Types
-
-   An attribute type governs whether the attribute can have multiple
-   values, the syntax and matching rules used to construct and compare
-   values of that attribute, and other functions.
-
-
-
-Zeilenga                    Standards Track                    [Page 12]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   If no equality matching is specified for the attribute type:
-
-      - the attribute (of the type) cannot be used for naming;
-      - when adding the attribute (or replacing all values), no two
-        values may be equivalent (see 2.2);
-      - individual values of a multi-valued attribute are not to be
-        independently added or deleted;
-      - attribute value assertions (such as matching in search filters
-        and comparisons) using values of such a type cannot be
-        performed.
-
-   Otherwise, the specified equality matching rule is to be used to
-   evaluate attribute value assertions concerning the attribute type.
-   The specified equality rule is to be transitive and commutative.
-
-   The attribute type indicates whether the attribute is a user
-   attribute or an operational attribute.  If operational, the attribute
-   type indicates the operational usage and whether or not the attribute
-   is modifiable by users.  Operational attributes are discussed in
-   Section 3.4.
-
-   An attribute type (a subtype) may derive from a more generic
-   attribute type (a direct supertype).  The following restrictions
-   apply to subtyping:
-
-      - a subtype must have the same usage as its direct supertype,
-      - a subtype's syntax must be the same, or a refinement of, its
-        supertype's syntax, and
-      - a subtype must be collective [RFC3671] if its supertype is
-        collective.
-
-   An attribute description consisting of a subtype and no options is
-   said to be the direct description subtype of the attribute
-   description consisting of the subtype's direct supertype and no
-   options.
-
-   Each attribute type is identified by an object identifier (OID) and,
-   optionally, one or more short names (descriptors).
-
-2.5.2.  Attribute Options
-
-   There are multiple kinds of attribute description options.  The LDAP
-   technical specification details one kind: tagging options.
-
-   Not all options can be associated with attributes held in the
-   directory.  Tagging options can be.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 13]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Not all options can be used in conjunction with all attribute types.
-   In such cases, the attribute description is to be treated as
-   unrecognized.
-
-   An attribute description that contains mutually exclusive options
-   shall be treated as unrecognized.  That is, "cn;x-bar;x-foo", where
-   "x-foo" and "x-bar" are mutually exclusive, is to be treated as
-   unrecognized.
-
-   Other kinds of options may be specified in future documents.  These
-   documents must detail how new kinds of options they define relate to
-   tagging options.  In particular, these documents must detail whether
-   or not new kinds of options can be associated with attributes held in
-   the directory, how new kinds of options affect transfer of attribute
-   values, and how new kinds of options are treated in attribute
-   description hierarchies.
-
-   Options are represented as short, case-insensitive textual strings
-   conforming to the <option> production defined in Section 2.5 of this
-   document.
-
-   Procedures for registering options are detailed in BCP 64, RFC 4520
-   [RFC4520].
-
-2.5.2.1.  Tagging Options
-
-   Attributes held in the directory can have attribute descriptions with
-   any number of tagging options.  Tagging options are never mutually
-   exclusive.
-
-   An attribute description with N tagging options is a direct
-   (description) subtype of all attribute descriptions of the same
-   attribute type and all but one of the N options.  If the attribute
-   type has a supertype, then the attribute description is also a direct
-   (description) subtype of the attribute description of the supertype
-   and the N tagging options.  That is, 'cn;lang-de;lang-en' is a direct
-   (description) subtype of 'cn;lang-de', 'cn;lang-en', and
-   'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
-   in [RFC4519]).
-
-2.5.3.  Attribute Description Hierarchies
-
-   An attribute description can be the direct subtype of zero or more
-   other attribute descriptions as indicated by attribute type subtyping
-   (as described in Section 2.5.1) or attribute tagging option subtyping
-   (as described in Section 2.5.2.1).  These subtyping relationships are
-   used to form hierarchies of attribute descriptions and attributes.
-
-
-
-
-Zeilenga                    Standards Track                    [Page 14]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   As adapted from [X.501]:
-
-      Attribute hierarchies allow access to the DIB with varying degrees
-      of granularity.  This is achieved by allowing the value components
-      of attributes to be accessed by using either their specific
-      attribute description (a direct reference to the attribute) or a
-      more generic attribute description (an indirect reference).
-
-      Semantically related attributes may be placed in a hierarchical
-      relationship, the more specialized being placed subordinate to the
-      more generalized.  Searching for or retrieving attributes and
-      their values is made easier by quoting the more generalized
-      attribute description; a filter item so specified is evaluated for
-      the more specialized descriptions as well as for the quoted
-      description.
-
-      Where subordinate specialized descriptions are selected to be
-      returned as part of a search result these descriptions shall be
-      returned if available.  Where the more general descriptions are
-      selected to be returned as part of a search result both the
-      general and the specialized descriptions shall be returned, if
-      available.  An attribute value shall always be returned as a value
-      of its own attribute description.
-
-      All of the attribute descriptions in an attribute hierarchy are
-      treated as distinct and unrelated descriptions for user
-      modification of entry content.
-
-      An attribute value stored in an object or alias entry is of
-      precisely one attribute description.  The description is indicated
-      when the value is originally added to the entry.
-
-   For the purpose of subschema administration of the entry, a
-   specification that an attribute is required is fulfilled if the entry
-   contains a value of an attribute description belonging to an
-   attribute hierarchy where the attribute type of that description is
-   the same as the required attribute's type.  That is, a "MUST name"
-   specification is fulfilled by 'name' or 'name;x-tag-option', but is
-   not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a
-   subtype of 'name').  Likewise, an entry may contain a value of an
-   attribute description belonging to an attribute hierarchy where the
-   attribute type of that description is either explicitly included in
-   the definition of an object class to which the entry belongs or
-   allowed by the DIT content rule applicable to that entry.  That is,
-   'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST
-   name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name"
-   (or by "MUST name").
-
-
-
-
-Zeilenga                    Standards Track                    [Page 15]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   For the purposes of other policy administration, unless stated
-   otherwise in the specification of the particular administrative
-   model, all of the attribute descriptions in an attribute hierarchy
-   are treated as distinct and unrelated descriptions.
-
-2.6.  Alias Entries
-
-   As adapted from [X.501]:
-
-      An alias, or an alias name, for an object is an alternative name
-      for an object or object entry which is provided by the use of
-      alias entries.
-
-      Each alias entry contains, within the 'aliasedObjectName'
-      attribute (known as the 'aliasedEntryName' attribute in X.500), a
-      name of some object.  The distinguished name of the alias entry is
-      thus also a name for this object.
-
-          NOTE - The name within the 'aliasedObjectName' is said to be
-                 pointed to by the alias.  It does not have to be the
-                 distinguished name of any entry.
-
-      The conversion of an alias name to an object name is termed
-      (alias) dereferencing and comprises the systematic replacement of
-      alias names, where found within a purported name, by the value of
-      the corresponding 'aliasedObjectName' attribute.  The process may
-      require the examination of more than one alias entry.
-
-      Any particular entry in the DIT may have zero or more alias names.
-      It therefore follows that several alias entries may point to the
-      same entry.  An alias entry may point to an entry that is not a
-      leaf entry and may point to another alias entry.
-
-      An alias entry shall have no subordinates, so that an alias entry
-      is always a leaf entry.
-
-      Every alias entry shall belong to the 'alias' object class.
-
-   An entry with the 'alias' object class must also belong to an object
-   class (or classes), or be governed by a DIT content rule, which
-   allows suitable naming attributes to be present.
-
-   Example:
-
-      dn: cn=bar,dc=example,dc=com
-      objectClass: top
-      objectClass: alias
-      objectClass: extensibleObject
-
-
-
-Zeilenga                    Standards Track                    [Page 16]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-      cn: bar
-      aliasedObjectName: cn=foo,dc=example,dc=com
-
-2.6.1.  'alias' Object Class
-
-   Alias entries belong to the 'alias' object class.
-
-      ( 2.5.6.1 NAME 'alias'
-        SUP top STRUCTURAL
-        MUST aliasedObjectName )
-
-2.6.2.  'aliasedObjectName' Attribute Type
-
-   The 'aliasedObjectName' attribute holds the name of the entry an
-   alias points to.  The 'aliasedObjectName' attribute is known as the
-   'aliasedEntryName' attribute in X.500.
-
-      ( 2.5.4.1 NAME 'aliasedObjectName'
-        EQUALITY distinguishedNameMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
-        SINGLE-VALUE )
-
-   The 'distinguishedNameMatch' matching rule and the DistinguishedName
-   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
-
-3.  Directory Administrative and Operational Information
-
-   This section discusses select aspects of the X.500 Directory
-   Administrative and Operational Information model [X.501].  LDAP
-   implementations MAY support other aspects of this model.
-
-3.1.  Subtrees
-
-   As defined in [X.501]:
-
-      A subtree is a collection of object and alias entries situated at
-      the vertices of a tree.  Subtrees do not contain subentries.  The
-      prefix sub, in subtree, emphasizes that the base (or root) vertex
-      of this tree is usually subordinate to the root of the DIT.
-
-      A subtree begins at some vertex and extends to some identifiable
-      lower boundary, possibly extending to leaves.  A subtree is always
-      defined within a context which implicitly bounds the subtree.  For
-      example, the vertex and lower boundaries of a subtree defining a
-      replicated area are bounded by a naming context.
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 17]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-3.2.  Subentries
-
-   A subentry is a "special sort of entry, known by the Directory, used
-   to hold information associated with a subtree or subtree refinement"
-   [X.501].  Subentries are used in Directory to hold for administrative
-   and operational purposes as defined in [X.501].  Their use in LDAP is
-   detailed in [RFC3672].
-
-   The term "(sub)entry" in this specification indicates that servers
-   implementing X.500(93) models are, in accordance with X.500(93) as
-   described in [RFC3672], to use a subentry and that other servers are
-   to use an object entry belonging to the appropriate auxiliary class
-   normally used with the subentry (e.g., 'subschema' for subschema
-   subentries) to mimic the subentry.  This object entry's RDN SHALL be
-   formed from a value of the 'cn' (commonName) attribute [RFC4519] (as
-   all subentries are named with 'cn').
-
-3.3.  The 'objectClass' attribute
-
-   Each entry in the DIT has an 'objectClass' attribute.
-
-      ( 2.5.4.0 NAME 'objectClass'
-        EQUALITY objectIdentifierMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-   The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER
-   (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
-
-   The 'objectClass' attribute specifies the object classes of an entry,
-   which (among other things) are used in conjunction with the
-   controlling schema to determine the permitted attributes of an entry.
-   Values of this attribute can be modified by clients, but the
-   'objectClass' attribute cannot be removed.
-
-   Servers that follow X.500(93) models SHALL restrict modifications of
-   this attribute to prevent the basic structural class of the entry
-   from being changed.  That is, one cannot change a 'person' into a
-   'country'.
-
-   When creating an entry or adding an 'objectClass' value to an entry,
-   all superclasses of the named classes SHALL be implicitly added as
-   well if not already present.  That is, if the auxiliary class 'x-a'
-   is a subclass of the class 'x-b', adding 'x-a' to 'objectClass'
-   causes 'x-b' to be implicitly added (if is not already present).
-
-   Servers SHALL restrict modifications of this attribute to prevent
-   superclasses of remaining 'objectClass' values from being deleted.
-   That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
-
-
-
-Zeilenga                    Standards Track                    [Page 18]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b',
-   an attempt to delete only 'x-b' from the 'objectClass' attribute is
-   an error.
-
-3.4.  Operational Attributes
-
-   Some attributes, termed operational attributes, are used or
-   maintained by servers for administrative and operational purposes.
-   As stated in [X.501]: "There are three varieties of operational
-   attributes:  Directory operational attributes, DSA-shared operational
-   attributes, and DSA-specific operational attributes".
-
-   A directory operational attribute is used to represent operational
-   and/or administrative information in the Directory Information Model.
-   This includes operational attributes maintained by the server (e.g.,
-   'createTimestamp') as well as operational attributes that hold values
-   administrated by the user (e.g., 'ditContentRules').
-
-   A DSA-shared operational attribute is used to represent information
-   of the DSA Information Model that is shared between DSAs.
-
-   A DSA-specific operational attribute is used to represent information
-   of the DSA Information Model that is specific to the DSA (though, in
-   some cases, may be derived from information shared between DSAs;
-   e.g., 'namingContexts').
-
-   The DSA Information Model operational attributes are detailed in
-   [X.501].
-
-   Operational attributes are not normally visible.  They are not
-   returned in search results unless explicitly requested by name.
-
-   Not all operational attributes are user modifiable.
-
-   Entries may contain, among others, the following operational
-   attributes:
-
-      - creatorsName: the Distinguished Name of the user who added this
-          entry to the directory,
-
-      - createTimestamp: the time this entry was added to the directory,
-
-      - modifiersName: the Distinguished Name of the user who last
-          modified this entry, and
-
-      - modifyTimestamp: the time this entry was last modified.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 19]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Servers SHOULD maintain the 'creatorsName', 'createTimestamp',
-   'modifiersName', and 'modifyTimestamp' attributes for all entries of
-   the DIT.
-
-3.4.1.  'creatorsName'
-
-   This attribute appears in entries that were added using the protocol
-   (e.g., using the Add operation).  The value is the distinguished name
-   of the creator.
-
-      ( 2.5.18.3 NAME 'creatorsName'
-        EQUALITY distinguishedNameMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'distinguishedNameMatch' matching rule and the DistinguishedName
-   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
-
-3.4.2.  'createTimestamp'
-
-   This attribute appears in entries that were added using the protocol
-   (e.g., using the Add operation).  The value is the time the entry was
-   added.
-
-      ( 2.5.18.1 NAME 'createTimestamp'
-        EQUALITY generalizedTimeMatch
-        ORDERING generalizedTimeOrderingMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
-   matching rules and the GeneralizedTime
-   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
-
-3.4.3.  'modifiersName'
-
-   This attribute appears in entries that have been modified using the
-   protocol (e.g., using the Modify operation).  The value is the
-   distinguished name of the last modifier.
-
-      ( 2.5.18.4 NAME 'modifiersName'
-        EQUALITY distinguishedNameMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-
-
-
-Zeilenga                    Standards Track                    [Page 20]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   The 'distinguishedNameMatch' matching rule and the DistinguishedName
-   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
-
-3.4.4.  'modifyTimestamp'
-
-   This attribute appears in entries that have been modified using the
-   protocol (e.g., using the Modify operation).  The value is the time
-   the entry was last modified.
-
-      ( 2.5.18.2 NAME 'modifyTimestamp'
-        EQUALITY generalizedTimeMatch
-        ORDERING generalizedTimeOrderingMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch'
-   matching rules and the GeneralizedTime
-   (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
-
-3.4.5.  'structuralObjectClass'
-
-   This attribute indicates the structural object class of the entry.
-
-      ( 2.5.21.9 NAME 'structuralObjectClass'
-        EQUALITY objectIdentifierMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER
-   (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
-
-3.4.6.  'governingStructureRule'
-
-   This attribute indicates the structure rule governing the entry.
-
-      ( 2.5.21.10 NAME 'governingStructureRule'
-        EQUALITY integerMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'integerMatch' matching rule and INTEGER
-   (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 21]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.  Directory Schema
-
-   As defined in [X.501]:
-
-      The Directory Schema is a set of definitions and constraints
-      concerning the structure of the DIT, the possible ways entries are
-      named, the information that can be held in an entry, the
-      attributes used to represent that information and their
-      organization into hierarchies to facilitate search and retrieval
-      of the information and the ways in which values of attributes may
-      be matched in attribute value and matching rule assertions.
-
-      NOTE 1 - The schema enables the Directory system to, for example:
-
-      - prevent the creation of subordinate entries of the wrong
-        object-class (e.g., a country as a subordinate of a person);
-
-      - prevent the addition of attribute-types to an entry
-        inappropriate to the object-class (e.g., a serial number to a
-        person's entry);
-
-      - prevent the addition of an attribute value of a syntax not
-        matching that defined for the attribute-type (e.g., a printable
-        string to a bit string).
-
-      Formally, the Directory Schema comprises a set of:
-
-      a) Name Form definitions that define primitive naming relations
-         for structural object classes;
-
-      b) DIT Structure Rule definitions that define the names that
-         entries may have and the ways in which the entries may be
-         related to one another in the DIT;
-
-      c) DIT Content Rule definitions that extend the specification of
-         allowable attributes for entries beyond those indicated by the
-         structural object classes of the entries;
-
-      d) Object Class definitions that define the basic set of mandatory
-         and optional attributes that shall be present, and may be
-         present, respectively, in an entry of a given class, and which
-         indicate the kind of object class that is being defined;
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 22]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-      e) Attribute Type definitions that identify the object identifier
-         by which an attribute is known, its syntax, associated matching
-         rules, whether it is an operational attribute and if so its
-         type, whether it is a collective attribute, whether it is
-         permitted to have multiple values and whether or not it is
-         derived from another attribute type;
-
-      f) Matching Rule definitions that define matching rules.
-
-      And in LDAP:
-
-      g) LDAP Syntax definitions that define encodings used in LDAP.
-
-4.1.  Schema Definitions
-
-   Schema definitions in this section are described using ABNF and rely
-   on the common productions specified in Section 1.2 as well as these:
-
-      noidlen = numericoid [ LCURLY len RCURLY ]
-      len = number
-
-      oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
-      oidlist = oid *( WSP DOLLAR WSP oid )
-
-      extensions = *( SP xstring SP qdstrings )
-      xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
-
-      qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
-      qdescrlist = [ qdescr *( SP qdescr ) ]
-      qdescr = SQUOTE descr SQUOTE
-
-      qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
-      qdstringlist = [ qdstring *( SP qdstring ) ]
-      qdstring = SQUOTE dstring SQUOTE
-      dstring = 1*( QS / QQ / QUTF8 )   ; escaped UTF-8 string
-
-      QQ =  ESC %x32 %x37 ; "\27"
-      QS =  ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
-
-      ; Any UTF-8 encoded Unicode character
-      ; except %x27 ("\'") and %x5C ("\")
-      QUTF8    = QUTF1 / UTFMB
-
-      ; Any ASCII character except %x27 ("\'") and %x5C ("\")
-      QUTF1    = %x00-26 / %x28-5B / %x5D-7F
-
-   Schema definitions in this section also share a number of common
-   terms.
-
-
-
-Zeilenga                    Standards Track                    [Page 23]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   The NAME field provides a set of short names (descriptors) that are
-   to be used as aliases for the OID.
-
-   The DESC field optionally allows a descriptive string to be provided
-   by the directory administrator and/or implementor.  While
-   specifications may suggest a descriptive string, there is no
-   requirement that the suggested (or any) descriptive string be used.
-
-   The OBSOLETE field, if present, indicates the element is not active.
-
-   Implementors should note that future versions of this document may
-   expand these definitions to include additional terms.  Terms whose
-   identifier begins with "X-" are reserved for private experiments and
-   are followed by <SP> and <qdstrings> tokens.
-
-4.1.1.  Object Class Definitions
-
-   Object Class definitions are written according to the ABNF:
-
-     ObjectClassDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         [ SP "SUP" SP oids ]       ; superior object classes
-         [ SP kind ]                ; kind of class
-         [ SP "MUST" SP oids ]      ; attribute types
-         [ SP "MAY" SP oids ]       ; attribute types
-         extensions WSP RPAREN
-
-     kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
-
-   where:
-     <numericoid> is object identifier assigned to this object class;
-     NAME <qdescrs> are short names (descriptors) identifying this
-         object class;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this object class is not active;
-     SUP <oids> specifies the direct superclasses of this object class;
-     the kind of object class is indicated by one of ABSTRACT,
-         STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
-     MUST and MAY specify the sets of required and allowed attribute
-         types, respectively; and
-     <extensions> describe extensions.
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 24]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.1.2.  Attribute Types
-
-   Attribute Type definitions are written according to the ABNF:
-
-     AttributeTypeDescription = LPAREN WSP
-         numericoid                    ; object identifier
-         [ SP "NAME" SP qdescrs ]      ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]     ; description
-         [ SP "OBSOLETE" ]             ; not active
-         [ SP "SUP" SP oid ]           ; supertype
-         [ SP "EQUALITY" SP oid ]      ; equality matching rule
-         [ SP "ORDERING" SP oid ]      ; ordering matching rule
-         [ SP "SUBSTR" SP oid ]        ; substrings matching rule
-         [ SP "SYNTAX" SP noidlen ]    ; value syntax
-         [ SP "SINGLE-VALUE" ]         ; single-value
-         [ SP "COLLECTIVE" ]           ; collective
-         [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
-         [ SP "USAGE" SP usage ]       ; usage
-         extensions WSP RPAREN         ; extensions
-
-     usage = "userApplications"     /  ; user
-             "directoryOperation"   /  ; directory operational
-             "distributedOperation" /  ; DSA-shared operational
-             "dSAOperation"            ; DSA-specific operational
-
-   where:
-     <numericoid> is object identifier assigned to this attribute type;
-     NAME <qdescrs> are short names (descriptors) identifying this
-         attribute type;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this attribute type is not active;
-     SUP oid specifies the direct supertype of this type;
-     EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
-         ordering, and substrings matching rules, respectively;
-     SYNTAX identifies value syntax by object identifier and may suggest
-         a minimum upper bound;
-     SINGLE-VALUE indicates attributes of this type are restricted to a
-         single value;
-     COLLECTIVE indicates this attribute type is collective
-         [X.501][RFC3671];
-     NO-USER-MODIFICATION indicates this attribute type is not user
-         modifiable;
-     USAGE indicates the application of this attribute type; and
-     <extensions> describe extensions.
-
-   Each attribute type description must contain at least one of the SUP
-   or SYNTAX fields.  If no SYNTAX field is provided, the attribute type
-   description takes its value from the supertype.
-
-
-
-Zeilenga                    Standards Track                    [Page 25]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
-   fields, if not specified, take their value from the supertype.
-
-   Usage of userApplications, the default, indicates that attributes of
-   this type represent user information.  That is, they are user
-   attributes.
-
-   A usage of directoryOperation, distributedOperation, or dSAOperation
-   indicates that attributes of this type represent operational and/or
-   administrative information.  That is, they are operational
-   attributes.
-
-   directoryOperation usage indicates that the attribute of this type is
-   a directory operational attribute.  distributedOperation usage
-   indicates that the attribute of this type is a DSA-shared usage
-   operational attribute.  dSAOperation usage indicates that the
-   attribute of this type is a DSA-specific operational attribute.
-
-   COLLECTIVE requires usage userApplications.  Use of collective
-   attribute types in LDAP is discussed in [RFC3671].
-
-   NO-USER-MODIFICATION requires an operational usage.
-
-   Note that the <AttributeTypeDescription> does not list the matching
-   rules that can be used with that attribute type in an extensibleMatch
-   search filter [RFC4511].  This is done using the 'matchingRuleUse'
-   attribute described in Section 4.1.4.
-
-   This document refines the schema description of X.501 by requiring
-   that the SYNTAX field in an <AttributeTypeDescription> be a string
-   representation of an object identifier for the LDAP string syntax
-   definition, with an optional indication of the suggested minimum
-   bound of a value of this attribute.
-
-   A suggested minimum upper bound on the number of characters in a
-   value with a string-based syntax, or the number of bytes in a value
-   for all other syntaxes, may be indicated by appending this bound
-   count inside of curly braces following the syntax's OBJECT IDENTIFIER
-   in an Attribute Type Description.  This bound is not part of the
-   syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
-   that server implementations should allow a string to be 64 characters
-   long, although they may allow longer strings.  Note that a single
-   character of the Directory String syntax may be encoded in more than
-   one octet since UTF-8 [RFC3629] is a variable-length encoding.
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 26]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.1.3.  Matching Rules
-
-   Matching rules are used in performance of attribute value assertions,
-   such as in performance of a Compare operation.  They are also used in
-   evaluating search filters, determining which individual values are to
-   be added or deleted during performance of a Modify operation, and in
-   comparing distinguished names.
-
-   Each matching rule is identified by an object identifier (OID) and,
-   optionally, one or more short names (descriptors).
-
-   Matching rule definitions are written according to the ABNF:
-
-     MatchingRuleDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         SP "SYNTAX" SP numericoid  ; assertion syntax
-         extensions WSP RPAREN      ; extensions
-
-   where:
-     <numericoid> is object identifier assigned to this matching rule;
-     NAME <qdescrs> are short names (descriptors) identifying this
-         matching rule;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this matching rule is not active;
-     SYNTAX identifies the assertion syntax (the syntax of the assertion
-         value) by object identifier; and
-     <extensions> describe extensions.
-
-4.1.4.  Matching Rule Uses
-
-   A matching rule use lists the attribute types that are suitable for
-   use with an extensibleMatch search filter.
-
-   Matching rule use descriptions are written according to the following
-   ABNF:
-
-     MatchingRuleUseDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         SP "APPLIES" SP oids       ; attribute types
-         extensions WSP RPAREN      ; extensions
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 27]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   where:
-     <numericoid> is the object identifier of the matching rule
-         associated with this matching rule use description;
-     NAME <qdescrs> are short names (descriptors) identifying this
-         matching rule use;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this matching rule use is not active;
-     APPLIES provides a list of attribute types the matching rule
-         applies to; and
-     <extensions> describe extensions.
-
-4.1.5.  LDAP Syntaxes
-
-   LDAP Syntaxes of (attribute and assertion) values are described in
-   terms of ASN.1 [X.680] and, optionally, have an octet string encoding
-   known as the LDAP-specific encoding.  Commonly, the LDAP-specific
-   encoding is constrained to a string of Unicode [Unicode] characters
-   in UTF-8 [RFC3629] form.
-
-   Each LDAP syntax is identified by an object identifier (OID).
-
-   LDAP syntax definitions are written according to the ABNF:
-
-     SyntaxDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "DESC" SP qdstring ]  ; description
-         extensions WSP RPAREN      ; extensions
-
-   where:
-     <numericoid> is the object identifier assigned to this LDAP syntax;
-     DESC <qdstring> is a short descriptive string; and
-     <extensions> describe extensions.
-
-4.1.6.  DIT Content Rules
-
-   A DIT content rule is a "rule governing the content of entries of a
-   particular structural object class" [X.501].
-
-   For DIT entries of a particular structural object class, a DIT
-   content rule specifies which auxiliary object classes the entries are
-   allowed to belong to and which additional attributes (by type) are
-   required, allowed, or not allowed to appear in the entries.
-
-   The list of precluded attributes cannot include any attribute listed
-   as mandatory in the rule, the structural object class, or any of the
-   allowed auxiliary object classes.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 28]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Each content rule is identified by the object identifier, as well as
-   any short names (descriptors), of the structural object class it
-   applies to.
-
-   An entry may only belong to auxiliary object classes listed in the
-   governing content rule.
-
-   An entry must contain all attributes required by the object classes
-   the entry belongs to as well as all attributes required by the
-   governing content rule.
-
-   An entry may contain any non-precluded attributes allowed by the
-   object classes the entry belongs to as well as all attributes allowed
-   by the governing content rule.
-
-   An entry cannot include any attribute precluded by the governing
-   content rule.
-
-   An entry is governed by (if present and active in the subschema) the
-   DIT content rule that applies to the structural object class of the
-   entry (see Section 2.4.2).  If no active rule is present for the
-   entry's structural object class, the entry's content is governed by
-   the structural object class (and possibly other aspects of user and
-   system schema).  DIT content rules for superclasses of the structural
-   object class of an entry are not applicable to that entry.
-
-   DIT content rule descriptions are written according to the ABNF:
-
-     DITContentRuleDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         [ SP "AUX" SP oids ]       ; auxiliary object classes
-         [ SP "MUST" SP oids ]      ; attribute types
-         [ SP "MAY" SP oids ]       ; attribute types
-         [ SP "NOT" SP oids ]       ; attribute types
-         extensions WSP RPAREN      ; extensions
-
-   where:
-     <numericoid> is the object identifier of the structural object
-         class associated with this DIT content rule;
-     NAME <qdescrs> are short names (descriptors) identifying this DIT
-         content rule;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this DIT content rule use is not active;
-     AUX specifies a list of auxiliary object classes that entries
-         subject to this DIT content rule may belong to;
-
-
-
-Zeilenga                    Standards Track                    [Page 29]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-     MUST, MAY, and NOT specify lists of attribute types that are
-         required, allowed, or precluded, respectively, from appearing
-         in entries subject to this DIT content rule; and
-     <extensions> describe extensions.
-
-4.1.7.  DIT Structure Rules and Name Forms
-
-   It is sometimes desirable to regulate where object and alias entries
-   can be placed in the DIT and how they can be named based upon their
-   structural object class.
-
-4.1.7.1.  DIT Structure Rules
-
-   A DIT structure rule is a "rule governing the structure of the DIT by
-   specifying a permitted superior to subordinate entry relationship.  A
-   structure rule relates a name form, and therefore a structural object
-   class, to superior structure rules.  This permits entries of the
-   structural object class identified by the name form to exist in the
-   DIT as subordinates to entries governed by the indicated superior
-   structure rules" [X.501].
-
-   DIT structure rule descriptions are written according to the ABNF:
-
-     DITStructureRuleDescription = LPAREN WSP
-         ruleid                     ; rule identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         SP "FORM" SP oid           ; NameForm
-         [ SP "SUP" ruleids ]       ; superior rules
-         extensions WSP RPAREN      ; extensions
-
-     ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
-     ruleidlist = ruleid *( SP ruleid )
-     ruleid = number
-
-   where:
-     <ruleid> is the rule identifier of this DIT structure rule;
-     NAME <qdescrs> are short names (descriptors) identifying this DIT
-         structure rule;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this DIT structure rule use is not active;
-     FORM is specifies the name form associated with this DIT structure
-         rule;
-     SUP identifies superior rules (by rule id); and
-     <extensions> describe extensions.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 30]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   If no superior rules are identified, the DIT structure rule applies
-   to an autonomous administrative point (e.g., the root vertex of the
-   subtree controlled by the subschema) [X.501].
-
-4.1.7.2.  Name Forms
-
-   A name form "specifies a permissible RDN for entries of a particular
-   structural object class.  A name form identifies a named object class
-   and one or more attribute types to be used for naming (i.e., for the
-   RDN).  Name forms are primitive pieces of specification used in the
-   definition of DIT structure rules" [X.501].
-
-   Each name form indicates the structural object class to be named, a
-   set of required attribute types, and a set of allowed attribute
-   types.  A particular attribute type cannot be in both sets.
-
-   Entries governed by the form must be named using a value from each
-   required attribute type and zero or more values from the allowed
-   attribute types.
-
-   Each name form is identified by an object identifier (OID) and,
-   optionally, one or more short names (descriptors).
-
-   Name form descriptions are written according to the ABNF:
-
-     NameFormDescription = LPAREN WSP
-         numericoid                 ; object identifier
-         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
-         [ SP "DESC" SP qdstring ]  ; description
-         [ SP "OBSOLETE" ]          ; not active
-         SP "OC" SP oid             ; structural object class
-         SP "MUST" SP oids          ; attribute types
-         [ SP "MAY" SP oids ]       ; attribute types
-         extensions WSP RPAREN      ; extensions
-
-   where:
-     <numericoid> is object identifier that identifies this name form;
-     NAME <qdescrs> are short names (descriptors) identifying this name
-         form;
-     DESC <qdstring> is a short descriptive string;
-     OBSOLETE indicates this name form is not active;
-     OC identifies the structural object class this rule applies to,
-     MUST and MAY specify the sets of required and allowed,
-         respectively, naming attributes for this name form; and
-     <extensions> describe extensions.
-
-   All attribute types in the required ("MUST") and allowed ("MAY")
-   lists shall be different.
-
-
-
-Zeilenga                    Standards Track                    [Page 31]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.2.  Subschema Subentries
-
-   Subschema (sub)entries are used for administering information about
-   the directory schema.  A single subschema (sub)entry contains all
-   schema definitions (see Section 4.1) used by entries in a particular
-   part of the directory tree.
-
-   Servers that follow X.500(93) models SHOULD implement subschema using
-   the X.500 subschema mechanisms (as detailed in Section 12 of
-   [X.501]), so these are not ordinary object entries but subentries
-   (see Section 3.2).  LDAP clients SHOULD NOT assume that servers
-   implement any of the other aspects of X.500 subschema.
-
-   Servers MAY allow subschema modification.  Procedures for subschema
-   modification are discussed in Section 14.5 of [X.501].
-
-   A server that masters entries and permits clients to modify these
-   entries SHALL implement and provide access to these subschema
-   (sub)entries including providing a 'subschemaSubentry' attribute in
-   each modifiable entry.  This is so clients may discover the
-   attributes and object classes that are permitted to be present.  It
-   is strongly RECOMMENDED that all other servers implement this as
-   well.
-
-   The value of the 'subschemaSubentry' attribute is the name of the
-   subschema (sub)entry holding the subschema controlling the entry.
-
-      ( 2.5.18.10 NAME 'subschemaSubentry'
-        EQUALITY distinguishedNameMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
-        SINGLE-VALUE NO-USER-MODIFICATION
-        USAGE directoryOperation )
-
-   The 'distinguishedNameMatch' matching rule and the DistinguishedName
-   (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
-
-   Subschema is held in (sub)entries belonging to the subschema
-   auxiliary object class.
-
-      ( 2.5.20.1 NAME 'subschema' AUXILIARY
-        MAY ( dITStructureRules $ nameForms $ ditContentRules $
-          objectClasses $ attributeTypes $ matchingRules $
-          matchingRuleUse ) )
-
-   The 'ldapSyntaxes' operational attribute may also be present in
-   subschema entries.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 32]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Servers MAY provide additional attributes (described in other
-   documents) in subschema (sub)entries.
-
-   Servers SHOULD provide the attributes 'createTimestamp' and
-   'modifyTimestamp' in subschema (sub)entries, in order to allow
-   clients to maintain their caches of schema information.
-
-   The following subsections provide attribute type definitions for each
-   of schema definition attribute types.
-
-4.2.1.  'objectClasses'
-
-   This attribute holds definitions of object classes.
-
-      ( 2.5.21.6 NAME 'objectClasses'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are
-   defined in [RFC4517].
-
-4.2.2.  'attributeTypes'
-
-   This attribute holds definitions of attribute types.
-
-      ( 2.5.21.5 NAME 'attributeTypes'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are
-   defined in [RFC4517].
-
-4.2.3.  'matchingRules'
-
-   This attribute holds definitions of matching rules.
-
-      ( 2.5.21.4 NAME 'matchingRules'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are
-   defined in [RFC4517].
-
-
-
-Zeilenga                    Standards Track                    [Page 33]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.2.4 'matchingRuleUse'
-
-   This attribute holds definitions of matching rule uses.
-
-      ( 2.5.21.8 NAME 'matchingRuleUse'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are
-   defined in [RFC4517].
-
-4.2.5.  'ldapSyntaxes'
-
-   This attribute holds definitions of LDAP syntaxes.
-
-      ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined
-   in [RFC4517].
-
-4.2.6.  'dITContentRules'
-
-   This attribute lists DIT Content Rules that are present in the
-   subschema.
-
-      ( 2.5.21.2 NAME 'dITContentRules'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are
-   defined in [RFC4517].
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 34]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-4.2.7.  'dITStructureRules'
-
-   This attribute lists DIT Structure Rules that are present in the
-   subschema.
-
-      ( 2.5.21.1 NAME 'dITStructureRules'
-        EQUALITY integerFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
-        USAGE directoryOperation )
-
-   The 'integerFirstComponentMatch' matching rule and the
-   DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax
-   are defined in [RFC4517].
-
-4.2.8 'nameForms'
-
-   This attribute lists Name Forms that are in force.
-
-      ( 2.5.21.7 NAME 'nameForms'
-        EQUALITY objectIdentifierFirstComponentMatch
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
-        USAGE directoryOperation )
-
-   The 'objectIdentifierFirstComponentMatch' matching rule and the
-   NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are
-   defined in [RFC4517].
-
-4.3.  'extensibleObject' object class
-
-   The 'extensibleObject' auxiliary object class allows entries that
-   belong to it to hold any user attribute.  The set of allowed
-   attribute types of this object class is implicitly the set of all
-   attribute types of userApplications usage.
-
-      ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
-        SUP top AUXILIARY )
-
-   The mandatory attributes of the other object classes of this entry
-   are still required to be present, and any precluded attributes are
-   still not allowed to be present.
-
-4.4.  Subschema Discovery
-
-   To discover the DN of the subschema (sub)entry holding the subschema
-   controlling a particular entry, a client reads that entry's
-   'subschemaSubentry' operational attribute.  To read schema attributes
-   from the subschema (sub)entry, clients MUST issue a Search operation
-   [RFC4511] where baseObject is the DN of the subschema (sub)entry,
-
-
-
-Zeilenga                    Standards Track                    [Page 35]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   scope is baseObject, filter is "(objectClass=subschema)" [RFC4515],
-   and the attributes field lists the names of the desired schema
-   attributes (as they are operational).  Note: the
-   "(objectClass=subschema)" filter allows LDAP servers that gateway to
-   X.500 to detect that subentry information is being requested.
-
-   Clients SHOULD NOT assume that a published subschema is complete,
-   that the server supports all of the schema elements it publishes, or
-   that the server does not support an unpublished element.
-
-5.  DSA (Server) Informational Model
-
-   The LDAP protocol assumes there are one or more servers that jointly
-   provide access to a Directory Information Tree (DIT).  The server
-   holding the original information is called the "master" (for that
-   information).  Servers that hold copies of the original information
-   are referred to as "shadowing" or "caching" servers.
-
-
-   As defined in [X.501]:
-
-      context prefix: The sequence of RDNs leading from the Root of the
-          DIT to the initial vertex of a naming context; corresponds to
-          the distinguished name of that vertex.
-
-      naming context: A subtree of entries held in a single master DSA.
-
-   That is, a naming context is the largest collection of entries,
-   starting at an entry that is mastered by a particular server, and
-   including all its subordinates and their subordinates, down to the
-   entries that are mastered by different servers.  The context prefix
-   is the name of the initial entry.
-
-   The root of the DIT is a DSA-specific Entry (DSE) and not part of any
-   naming context (or any subtree); each server has different attribute
-   values in the root DSE.
-
-5.1.  Server-Specific Data Requirements
-
-   An LDAP server SHALL provide information about itself and other
-   information that is specific to each server.  This is represented as
-   a group of attributes located in the root DSE, which is named with
-   the DN with zero RDNs (whose [RFC4514] representation is as the
-   zero-length string).
-
-   These attributes are retrievable, subject to access control and other
-   restrictions, if a client performs a Search operation [RFC4511] with
-   an empty baseObject, scope of baseObject, the filter
-
-
-
-Zeilenga                    Standards Track                    [Page 36]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   "(objectClass=*)" [RFC4515], and the attributes field listing the
-   names of the desired attributes.  It is noted that root DSE
-   attributes are operational and, like other operational attributes,
-   are not returned in search requests unless requested by name.
-
-   The root DSE SHALL NOT be included if the client performs a subtree
-   search starting from the root.
-
-   Servers may allow clients to modify attributes of the root DSE, where
-   appropriate.
-
-   The following attributes of the root DSE are defined below.
-   Additional attributes may be defined in other documents.
-
-      - altServer: alternative servers;
-
-      - namingContexts: naming contexts;
-
-      - supportedControl: recognized LDAP controls;
-
-      - supportedExtension: recognized LDAP extended operations;
-
-      - supportedFeatures: recognized LDAP features;
-
-      - supportedLDAPVersion: LDAP versions supported; and
-
-      - supportedSASLMechanisms: recognized Simple Authentication and
-        Security Layers (SASL) [RFC4422] mechanisms.
-
-   The values provided for these attributes may depend on session-
-   specific and other factors.  For example, a server supporting the
-   SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's
-   identity has been established by a lower level.  See [RFC4513].
-
-   The root DSE may also include a 'subschemaSubentry' attribute.  If it
-   does, the attribute refers to the subschema (sub)entry holding the
-   schema controlling the root DSE.  Clients SHOULD NOT assume that this
-   subschema (sub)entry controls other entries held by the server.
-   General subschema discovery procedures are provided in Section 4.4.
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 37]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-5.1.1.  'altServer'
-
-   The 'altServer' attribute lists URIs referring to alternative servers
-   that may be contacted when this server becomes unavailable.  URIs for
-   servers implementing the LDAP are written according to [RFC4516].
-   Other kinds of URIs may be provided.  If the server does not know of
-   any other servers that could be used, this attribute will be absent.
-   Clients may cache this information in case their preferred server
-   later becomes unavailable.
-
-      ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
-        USAGE dSAOperation )
-
-   The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in
-   [RFC4517].
-
-5.1.2.  'namingContexts'
-
-   The 'namingContexts' attribute lists the context prefixes of the
-   naming contexts the server masters or shadows (in part or in whole).
-   If the server is a first-level DSA [X.501], it should list (in
-   addition) an empty string (indicating the root of the DIT).  If the
-   server does not master or shadow any information (e.g., it is an LDAP
-   gateway to a public X.500 directory) this attribute will be absent.
-   If the server believes it masters or shadows the entire directory,
-   the attribute will have a single value, and that value will be the
-   empty string (indicating the root of the DIT).
-
-   This attribute may be used, for example, to select a suitable entry
-   name for subsequent operations with this server.
-
-      ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
-        USAGE dSAOperation )
-
-   The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is
-   defined in [RFC4517].
-
-5.1.3.  'supportedControl'
-
-   The 'supportedControl' attribute lists object identifiers identifying
-   the request controls [RFC4511] the server supports.  If the server
-   does not support any request controls, this attribute will be absent.
-   Object identifiers identifying response controls need not be listed.
-
-   Procedures for registering object identifiers used to discovery of
-   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
-
-
-
-Zeilenga                    Standards Track                    [Page 38]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-      ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
-        USAGE dSAOperation )
-
-   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
-   defined in [RFC4517].
-
-5.1.4.  'supportedExtension'
-
-   The 'supportedExtension' attribute lists object identifiers
-   identifying the extended operations [RFC4511] that the server
-   supports.  If the server does not support any extended operations,
-   this attribute will be absent.
-
-   An extended operation generally consists of an extended request and
-   an extended response but may also include other protocol data units
-   (such as intermediate responses).  The object identifier assigned to
-   the extended request is used to identify the extended operation.
-   Other object identifiers used in the extended operation need not be
-   listed as values of this attribute.
-
-   Procedures for registering object identifiers used to discovery of
-   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
-
-      ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
-        USAGE dSAOperation )
-
-   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is
-   defined in [RFC4517].
-
-5.1.5.  'supportedFeatures'
-
-   The 'supportedFeatures' attribute lists object identifiers
-   identifying elective features that the server supports.  If the
-   server does not support any discoverable elective features, this
-   attribute will be absent.
-
-      ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
-          EQUALITY objectIdentifierMatch
-          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
-          USAGE dSAOperation )
-
-   Procedures for registering object identifiers used to discovery of
-   protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
-
-   The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and
-   objectIdentifierMatch matching rule are defined in [RFC4517].
-
-
-
-Zeilenga                    Standards Track                    [Page 39]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-5.1.6.  'supportedLDAPVersion'
-
-   The 'supportedLDAPVersion' attribute lists the versions of LDAP that
-   the server supports.
-
-      ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
-        USAGE dSAOperation )
-
-   The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in
-   [RFC4517].
-
-5.1.7.  'supportedSASLMechanisms'
-
-   The 'supportedSASLMechanisms' attribute lists the SASL mechanisms
-   [RFC4422] that the server recognizes and/or supports [RFC4513].  The
-   contents of this attribute may depend on the current session state.
-   If the server does not support any SASL mechanisms, this attribute
-   will not be present.
-
-      ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
-        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
-        USAGE dSAOperation )
-
-   The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is
-   defined in [RFC4517].
-
-6.  Other Considerations
-
-6.1.  Preservation of User Information
-
-   Syntaxes may be defined that have specific value and/or value form
-   (representation) preservation requirements.  For example, a syntax
-   containing digitally signed data can mandate that the server preserve
-   both the value and form of value presented to ensure that the
-   signature is not invalidated.
-
-   Where such requirements have not been explicitly stated, servers
-   SHOULD preserve the value of user information but MAY return the
-   value in a different form.  And where a server is unable (or
-   unwilling) to preserve the value of user information, the server
-   SHALL ensure that an equivalent value (per Section 2.3) is returned.
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 40]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-6.2.  Short Names
-
-   Short names, also known as descriptors, are used as more readable
-   aliases for object identifiers and are used to identify various
-   schema elements.  However, it is not expected that LDAP
-   implementations with human user interface would display these short
-   names (or the object identifiers they refer to) to the user.
-   Instead, they would most likely be performing translations (such as
-   expressing the short name in one of the local national languages).
-   For example, the short name "st" (stateOrProvinceName) might be
-   displayed to a German-speaking user as "Land".
-
-   The same short name might have different meaning in different
-   subschemas, and, within a particular subschema, the same short name
-   might refer to different object identifiers each identifying a
-   different kind of schema element.
-
-   Implementations MUST be prepared that the same short name might be
-   used in a subschema to refer to the different kinds of schema
-   elements.  That is, there might be an object class 'x-fubar' and an
-   attribute type 'x-fubar' in a subschema.
-
-   Implementations MUST be prepared that the same short name might be
-   used in the different subschemas to refer to the different schema
-   elements.  That is, there might be two matching rules 'x-fubar', each
-   in different subschemas.
-
-   Procedures for registering short names (descriptors) are detailed in
-   BCP 64, RFC 4520 [RFC4520].
-
-6.3.  Cache and Shadowing
-
-   Some servers may hold cache or shadow copies of entries, which can be
-   used to answer search and comparison queries, but will return
-   referrals or contact other servers if modification operations are
-   requested.  Servers that perform shadowing or caching MUST ensure
-   that they do not violate any access control constraints placed on the
-   data by the originating server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 41]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-7.  Implementation Guidelines
-
-7.1.  Server Guidelines
-
-   Servers MUST recognize all names of attribute types and object
-   classes defined in this document but, unless stated otherwise, need
-   not support the associated functionality.  Servers SHOULD recognize
-   all the names of attribute types and object classes defined in
-   Section 3 and 4, respectively, of [RFC4519].
-
-   Servers MUST ensure that entries conform to user and system schema
-   rules or other data model constraints.
-
-   Servers MAY support DIT Content Rules.  Servers MAY support DIT
-   Structure Rules and Name Forms.
-
-   Servers MAY support alias entries.
-
-   Servers MAY support the 'extensibleObject' object class.
-
-   Servers MAY support subentries.  If so, they MUST do so in accordance
-   with [RFC3672].  Servers that do not support subentries SHOULD use
-   object entries to mimic subentries as detailed in Section 3.2.
-
-   Servers MAY implement additional schema elements.  Servers SHOULD
-   provide definitions of all schema elements they support in subschema
-   (sub)entries.
-
-7.2.  Client Guidelines
-
-   In the absence of prior agreements with servers, clients SHOULD NOT
-   assume that servers support any particular schema elements beyond
-   those referenced in Section 7.1.  The client can retrieve subschema
-   information as described in Section 4.4.
-
-   Clients MUST NOT display or attempt to decode a value as ASN.1 if the
-   value's syntax is not known.  Clients MUST NOT assume the LDAP-
-   specific string encoding is restricted to a UTF-8 encoded string of
-   Unicode characters or any particular subset of Unicode (such as a
-   printable subset) unless such restriction is explicitly stated.
-   Clients SHOULD NOT send attribute values in a request that are not
-   valid according to the syntax defined for the attributes.
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 42]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-8.  Security Considerations
-
-   Attributes of directory entries are used to provide descriptive
-   information about the real-world objects they represent, which can be
-   people, organizations, or devices.  Most countries have privacy laws
-   regarding the publication of information about people.
-
-   General security considerations for accessing directory information
-   with LDAP are discussed in [RFC4511] and [RFC4513].
-
-9.  IANA Considerations
-
-   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
-   descriptors registry as indicated in the following template:
-
-      Subject: Request for LDAP Descriptor Registration Update
-      Descriptor (short name): see comment
-      Object Identifier: see comment
-      Person & email address to contact for further information:
-          Kurt Zeilenga <kurt at OpenLDAP.org>
-      Usage: see comment
-      Specification: RFC 4512
-      Author/Change Controller: IESG
-      Comments:
-
-      The following descriptors (short names) has been added to
-      the registry.
-
-        NAME                         Type OID
-        ------------------------     ---- -----------------
-        governingStructureRule          A 2.5.21.10
-        structuralObjectClass           A 2.5.21.9
-
-      The following descriptors (short names) have been updated to
-      refer to this RFC.
-
-        NAME                         Type OID
-        ------------------------     ---- -----------------
-        alias                           O 2.5.6.1
-        aliasedObjectName               A 2.5.4.1
-        altServer                       A 1.3.6.1.4.1.1466.101.120.6
-        attributeTypes                  A 2.5.21.5
-        createTimestamp                 A 2.5.18.1
-        creatorsName                    A 2.5.18.3
-        dITContentRules                 A 2.5.21.2
-        dITStructureRules               A 2.5.21.1
-        extensibleObject                O 1.3.6.1.4.1.1466.101.120.111
-        ldapSyntaxes                    A 1.3.6.1.4.1.1466.101.120.16
-
-
-
-Zeilenga                    Standards Track                    [Page 43]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-        matchingRuleUse                 A 2.5.21.8
-        matchingRules                   A 2.5.21.4
-        modifiersName                   A 2.5.18.4
-        modifyTimestamp                 A 2.5.18.2
-        nameForms                       A 2.5.21.7
-        namingContexts                  A 1.3.6.1.4.1.1466.101.120.5
-        objectClass                     A 2.5.4.0
-        objectClasses                   A 2.5.21.6
-        subschema                       O 2.5.20.1
-        subschemaSubentry               A 2.5.18.10
-        supportedControl                A 1.3.6.1.4.1.1466.101.120.13
-        supportedExtension              A 1.3.6.1.4.1.1466.101.120.7
-        supportedFeatures               A 1.3.6.1.4.1.4203.1.3.5
-        supportedLDAPVersion            A 1.3.6.1.4.1.1466.101.120.15
-        supportedSASLMechanisms         A 1.3.6.1.4.1.1466.101.120.14
-        top                             O 2.5.6.0
-
-10.  Acknowledgements
-
-   This document is based in part on RFC 2251 by M. Wahl, T. Howes, and
-   S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and
-   RFC 2556 by M. Wahl, all products of the IETF Access, Searching and
-   Indexing of Directories (ASID) Working Group.  This document is also
-   based in part on "The Directory: Models" [X.501], a product of the
-   International Telephone Union (ITU).  Additional text was borrowed
-   from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
-
-   This document is a product of the IETF LDAP Revision (LDAPBIS)
-   Working Group.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 44]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-11.  Normative References
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
-                 10646", STD 63, RFC 3629, November 2003.
-
-   [RFC3671]     Zeilenga, K., "Collective Attributes in the Lightweight
-                 Directory Access Protocol (LDAP)", RFC 3671, December
-                 2003.
-
-   [RFC3672]     Zeilenga, K., "Subentries in the Lightweight Directory
-                 Access Protocol (LDAP)", RFC 3672, December 2003.
-
-   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                 Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4422]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
-                 Authentication and Security Layer (SASL)", RFC 4422,
-                 June 2006.
-
-   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Technical Specification Road Map", RFC
-                 4510, June 2006.
-
-   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Authentication Methods and Security
-                 Mechanisms", RFC 4513, June 2006.
-
-   [RFC4514]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): String Representation of Distinguished
-                 Names", RFC 4514, June 2006.
-
-   [RFC4515]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): String Representation of Search
-                 Filters", RFC 4515, June 2006.
-
-   [RFC4516]     Smith, M., Ed. and T. Howes, "Lightweight Directory
-                 Access Protocol (LDAP): Uniform Resource Locator", RFC
-                 4516, June 2006.
-
-   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
-                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                 2006.
-
-
-
-Zeilenga                    Standards Track                    [Page 45]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Schema for User Applications", RFC
-                 4519, June 2006.
-
-   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
-                 (IANA) Considerations for the Lightweight Directory
-                 Access Protocol (LDAP)", BCP 64, RFC 4520, 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/).
-
-   [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.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).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 46]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-Appendix A.  Changes
-
-   This appendix is non-normative.
-
-   This document amounts to nearly a complete rewrite of portions of RFC
-   2251, RFC 2252, and RFC 2256.  This rewrite was undertaken to improve
-   overall clarity of technical specification.  This appendix provides a
-   summary of substantive changes made to the portions of these
-   documents incorporated into this document.  Readers should consult
-   [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of
-   remaining portions of these documents.
-
-A.1.  Changes to RFC 2251
-
-   This document incorporates from RFC 2251, Sections 3.2 and 3.4, and
-   portions of Sections 4 and 6 as summarized below.
-
-A.1.1.  Section 3.2 of RFC 2251
-
-   Section 3.2 of RFC 2251 provided a brief introduction to the X.500
-   data model, as used by LDAP.  The previous specification relied on
-   [X.501] but lacked clarity in how X.500 models are adapted for use by
-   LDAP.  This document describes the X.500 data models, as used by
-   LDAP, in greater detail, especially in areas where adaptation is
-   needed.
-
-   Section 3.2.1 of RFC 2251 described an attribute as "a type with one
-   or more associated values".  In LDAP, an attribute is better
-   described as an attribute description, a type with zero or more
-   options, and one or more associated values.
-
-   Section 3.2.2 of RFC 2251 mandated that subschema subentries contain
-   objectClasses and attributeTypes attributes, yet X.500(93) treats
-   these attributes as optional.  While generally all implementations
-   that support X.500(93) subschema mechanisms will provide both of
-   these attributes, it is not absolutely required for interoperability
-   that all servers do.  The mandate was removed for consistency with
-   X.500(93).   The subschema discovery mechanism was also clarified to
-   indicate that subschema controlling an entry is obtained by reading
-   the (sub)entry referred to by that entry's 'subschemaSubentry'
-   attribute.
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 47]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-A.1.2.  Section 3.4 of RFC 2251
-
-   Section 3.4 of RFC 2251 provided "Server-specific Data Requirements".
-   This material, with changes, was incorporated in Section 5.1 of this
-   document.
-
-   Changes:
-
-   - Clarify that attributes of the root DSE are subject to "other
-     restrictions" in addition to access controls.
-
-   - Clarify that only recognized extended requests need to be
-     enumerated 'supportedExtension'.
-
-   - Clarify that only recognized request controls need to be enumerated
-     'supportedControl'.
-
-   - Clarify that root DSE attributes are operational and, like other
-     operational attributes, will not be returned in search requests
-     unless requested by name.
-
-   - Clarify that not all root DSE attributes are user modifiable.
-
-   - Remove inconsistent text regarding handling of the
-     'subschemaSubentry' attribute within the root DSE.  The previous
-     specification stated that the 'subschemaSubentry' attribute held in
-     the root DSE referred to "subschema entries (or subentries) known
-     by this server".  This is inconsistent with the attribute's
-     intended use as well as its formal definition as a single valued
-     attribute [X.501].  It is also noted that a simple (possibly
-     incomplete) list of subschema (sub)entries is not terribly useful.
-     This document (in Section 5.1) specifies that the
-     'subschemaSubentry' attribute of the root DSE refers to the
-     subschema controlling the root DSE.  It is noted that the general
-     subschema discovery mechanism remains available (see Section 4.4 of
-     this document).
-
-A.1.3.  Section 4 of RFC 2251
-
-   Portions of Section 4 of RFC 2251 detailing aspects of the
-   information model used by LDAP were incorporated in this document,
-   including:
-
-   - Restriction of distinguished values to attributes whose
-     descriptions have no options (from Section 4.1.3);
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 48]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   - Data model aspects of Attribute Types (from Section 4.1.4),
-     Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
-     Matching Rule Identifier (from 4.1.9); and
-
-   - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
-
-   Clarifications to these portions include:
-
-   - Subtyping and AttributeDescriptions with options.
-
-A.1.4.  Section 6 of RFC 2251
-
-   The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251
-   where incorporated into this document.
-
-A.2.  Changes to RFC 2252
-
-   This document incorporates Sections 4, 5, and 7 from RFC 2252.
-
-A.2.1.  Section 4 of RFC 2252
-
-   The specification was updated to use Augmented BNF [RFC4234].  The
-   string representation of an OBJECT IDENTIFIER was tightened to
-   disallow leading zeros as described in RFC 2252.
-
-   The <descr> syntax was changed to disallow semicolon (U+003B)
-   characters in order to appear to be consistent its natural language
-   specification "descr is the syntactic representation of an object
-   descriptor, which consists of letters and digits, starting with a
-   letter".  In a related change, the statement "an AttributeDescription
-   can be used as the value in a NAME part of an
-   AttributeTypeDescription" was deleted.  RFC 2252 provided no
-   specification of the semantics of attribute options appearing in NAME
-   fields.
-
-   RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
-   over the <numericoid> form.  However, <descr> form can be ambiguous.
-   To address this issue, the imperative was replaced with a statement
-   (in Section 1.4) that while the <descr> form is generally preferred,
-   <numericoid> should be used where an unambiguous <descr> is not
-   available.  Additionally, an expanded discussion of descriptor issues
-   is in Section 6.2 ("Short Names").
-
-   The ABNF for a quoted string (qdstring) was updated to reflect
-   support for the escaping mechanism described in Section 4.3 of RFC
-   2252.
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 49]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-A.2.2.  Section 5 of RFC 2252
-
-   Definitions of operational attributes provided in Section 5 of RFC
-   2252 where incorporated into this document.
-
-   The 'namingContexts' description was clarified.  A first-level DSA
-   should publish, in addition to other values, "" indicating the root
-   of the DIT.
-
-   The 'altServer' description was clarified.  It may hold any URI.
-
-   The 'supportedExtension' description was clarified.  A server need
-   only list the OBJECT IDENTIFIERs associated with the extended
-   requests of the extended operations it recognizes.
-
-   The 'supportedControl' description was clarified.  A server need only
-   list the OBJECT IDENTIFIERs associated with the request controls it
-   recognizes.
-
-   Descriptions for the 'structuralObjectClass' and
-   'governingStructureRule' operational attribute types were added.
-
-   The attribute definition of 'subschemaSubentry' was corrected to list
-   the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
-
-A.2.3.  Section 7 of RFC 2252
-
-   Section 7 of RFC 2252 provides definitions of the 'subschema' and
-   'extensibleObject' object classes.  These definitions where
-   integrated into Section 4.2 and Section 4.3 of this document,
-   respectively.  Section 7 of RFC 2252 also contained the object class
-   implementation requirement.  This was incorporated into Section 7 of
-   this document.
-
-   The specification of 'extensibleObject' was clarified regarding how
-   it interacts with precluded attributes.
-
-A.3.  Changes to RFC 2256
-
-   This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC
-   2256.
-
-   Section 5.1 of RFC 2256 provided the definition of the 'objectClass'
-   attribute type.  This was integrated into Section 2.4.1 of this
-   document.  The statement "One of the values is either 'top' or
-   'alias'" was replaced with statement that one of the values is 'top'
-   as entries belonging to 'alias' also belong to 'top'.
-
-
-
-
-Zeilenga                    Standards Track                    [Page 50]
-
-RFC 4512                      LDAP Models                      June 2006
-
-
-   Section 5.2 of RFC 2256 provided the definition of the
-   'aliasedObjectName' attribute type.  This was integrated into Section
-   2.6.2 of this document.
-
-   Section 7.1 of RFC 2256 provided the definition of the 'top' object
-   class.  This was integrated into Section 2.4.1 of this document.
-
-   Section 7.2 of RFC 2256 provided the definition of the 'alias' object
-   class.  This was integrated into Section 2.6.1 of this document.
-
-A.4.  Changes to RFC 3674
-
-   This document made no substantive change to the 'supportedFeatures'
-   technical specification provided in RFC 3674.
-
-Editor's Address
-
-   Kurt D.  Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 51]
-
-RFC 4512                      LDAP Models                      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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 52]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4513.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4513.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4513.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1907 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   R. Harrison, Ed.
-Request for Comments: 4513                                  Novell, Inc.
-Obsoletes: 2251, 2829, 2830                                    June 2006
-Category: Standards Track
-
-
-             Lightweight Directory Access Protocol (LDAP):
-             Authentication Methods and Security Mechanisms
-
-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
-
-   This document describes authentication methods and security
-   mechanisms of the Lightweight Directory Access Protocol (LDAP).  This
-   document details establishment of Transport Layer Security (TLS)
-   using the StartTLS operation.
-
-   This document details the simple Bind authentication method including
-   anonymous, unauthenticated, and name/password mechanisms and the
-   Simple Authentication and Security Layer (SASL) Bind authentication
-   method including the EXTERNAL mechanism.
-
-   This document discusses various authentication and authorization
-   states through which a session to an LDAP server may pass and the
-   actions that trigger these state changes.
-
-   This document, together with other documents in the LDAP Technical
-   Specification (see Section 1 of the specification's road map),
-   obsoletes RFC 2251, RFC 2829, and RFC 2830.
-
-
-
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                     [Page 1]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................4
-      1.1. Relationship to Other Documents ............................6
-      1.2. Conventions ................................................6
-   2. Implementation Requirements .....................................7
-   3. StartTLS Operation ..............................................8
-      3.1.  TLS Establishment Procedures ..............................8
-           3.1.1. StartTLS Request Sequencing .........................8
-           3.1.2. Client Certificate ..................................9
-           3.1.3. Server Identity Check ...............................9
-                  3.1.3.1. Comparison of DNS Names ...................10
-                  3.1.3.2. Comparison of IP Addresses ................11
-                  3.1.3.3. Comparison of Other subjectName Types .....11
-           3.1.4. Discovery of Resultant Security Level ..............11
-           3.1.5. Refresh of Server Capabilities Information .........11
-      3.2.  Effect of TLS on Authorization State .....................12
-      3.3. TLS Ciphersuites ..........................................12
-   4. Authorization State ............................................13
-   5. Bind Operation .................................................14
-      5.1. Simple Authentication Method ..............................14
-           5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
-           5.1.2. Unauthenticated Authentication Mechanism of
-                  Simple Bind ........................................14
-           5.1.3. Name/Password Authentication Mechanism of
-                  Simple Bind ........................................15
-      5.2. SASL Authentication Method ................................16
-           5.2.1. SASL Protocol Profile ..............................16
-                  5.2.1.1. SASL Service Name for LDAP ................16
-                  5.2.1.2. SASL Authentication Initiation and
-                           Protocol Exchange .........................16
-                  5.2.1.3. Optional Fields ...........................17
-                  5.2.1.4. Octet Where Negotiated Security
-                           Layers Take Effect ........................18
-                  5.2.1.5. Determination of Supported SASL
-                           Mechanisms ................................18
-                  5.2.1.6. Rules for Using SASL Layers ...............19
-                  5.2.1.7. Support for Multiple Authentications ......19
-                  5.2.1.8. SASL Authorization Identities .............19
-           5.2.2. SASL Semantics within LDAP .........................20
-           5.2.3. SASL EXTERNAL Authentication Mechanism .............20
-                  5.2.3.1. Implicit Assertion ........................21
-                  5.2.3.2. Explicit Assertion ........................21
-   6. Security Considerations ........................................21
-      6.1. General LDAP Security Considerations ......................21
-      6.2. StartTLS Security Considerations ..........................22
-      6.3. Bind Operation Security Considerations ....................23
-           6.3.1. Unauthenticated Mechanism Security Considerations ..23
-
-
-
-Harrison                    Standards Track                     [Page 2]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-           6.3.2. Name/Password Mechanism Security Considerations ....23
-           6.3.3. Password-Related Security Considerations ...........23
-           6.3.4. Hashed Password Security Considerations ............24
-      6.4. SASL Security Considerations ..............................24
-      6.5. Related Security Considerations ...........................25
-   7. IANA Considerations ............................................25
-   8. Acknowledgements ...............................................25
-   9. Normative References ...........................................26
-   10. Informative References ........................................27
-   Appendix A. Authentication and Authorization Concepts .............28
-      A.1. Access Control Policy .....................................28
-      A.2. Access Control Factors ....................................28
-      A.3. Authentication, Credentials, Identity .....................28
-      A.4. Authorization Identity ....................................29
-   Appendix B. Summary of Changes ....................................29
-      B.1. Changes Made to RFC 2251 ..................................30
-           B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
-           B.1.2. Section 4.2.2 ("Authentication and Other Security
-                  Services") .........................................30
-      B.2. Changes Made to RFC 2829 ..................................30
-           B.2.1. Section 4 ("Required security mechanisms") .........30
-           B.2.2. Section 5.1 ("Anonymous authentication
-                  procedure") ........................................31
-           B.2.3. Section 6 ("Password-based authentication") ........31
-           B.2.4. Section 6.1 ("Digest authentication") ..............31
-           B.2.5. Section 6.2 ("'simple' authentication choice under
-                  TLS encryption") ...................................31
-           B.2.6. Section 6.3 ("Other authentication choices with
-                  TLS") ..............................................31
-           B.2.7. Section 7.1 ("Certificate-based authentication
-                  with TLS") .........................................31
-           B.2.8. Section 8 ("Other mechanisms") .....................32
-           B.2.9. Section 9 ("Authorization Identity") ...............32
-           B.2.10. Section 10 ("TLS Ciphersuites") ...................32
-      B.3. Changes Made to RFC 2830 ..................................32
-           B.3.1. Section 3.6 ("Server Identity Check") ..............32
-           B.3.2. Section 3.7 ("Refresh of Server Capabilities
-                  Information") ......................................33
-           B.3.3. Section 5 ("Effects of TLS on a Client's
-                  Authorization Identity") ...........................33
-           B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
-
-
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                     [Page 3]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-1.  Introduction
-
-   The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
-   powerful protocol for accessing directories.  It offers means of
-   searching, retrieving, and manipulating directory content and ways to
-   access a rich set of security functions.
-
-   It is vital that these security functions be interoperable among all
-   LDAP clients and servers on the Internet; therefore there has to be a
-   minimum subset of security functions that is common to all
-   implementations that claim LDAP conformance.
-
-   Basic threats to an LDAP directory service include (but are not
-   limited to):
-
-   (1) Unauthorized access to directory data via data-retrieval
-       operations.
-
-   (2) Unauthorized access to directory data by monitoring access of
-       others.
-
-   (3) Unauthorized access to reusable client authentication information
-       by monitoring access of others.
-
-   (4) Unauthorized modification of directory data.
-
-   (5) Unauthorized modification of configuration information.
-
-   (6) Denial of Service: Use of resources (commonly in excess) in a
-       manner intended to deny service to others.
-
-   (7) Spoofing: Tricking a user or client into believing that
-       information came from the directory when in fact it did not,
-       either by modifying data in transit or misdirecting the client's
-       transport connection.  Tricking a user or client into sending
-       privileged information to a hostile entity that appears to be the
-       directory server but is not.  Tricking a directory server into
-       believing that information came from a particular client when in
-       fact it came from a hostile entity.
-
-   (8) Hijacking: An attacker seizes control of an established protocol
-       session.
-
-   Threats (1), (4), (5), (6), (7), and (8) are active attacks.  Threats
-   (2) and (3) are passive attacks.
-
-
-
-
-
-
-Harrison                    Standards Track                     [Page 4]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   Threats (1), (4), (5), and (6) are due to hostile clients.  Threats
-   (2), (3), (7), and (8) are due to hostile agents on the path between
-   client and server or hostile agents posing as a server, e.g., IP
-   spoofing.
-
-   LDAP offers the following security mechanisms:
-
-   (1) Authentication by means of the Bind operation.  The Bind
-       operation provides a simple method that supports anonymous,
-       unauthenticated, and name/password mechanisms, and the Simple
-       Authentication and Security Layer (SASL) method, which supports a
-       wide variety of authentication mechanisms.
-
-   (2) Mechanisms to support vendor-specific access control facilities
-       (LDAP does not offer a standard access control facility).
-
-   (3) Data integrity service by means of security layers in Transport
-       Layer Security (TLS) or SASL mechanisms.
-
-   (4) Data confidentiality service by means of security layers in TLS
-       or SASL mechanisms.
-
-   (5) Server resource usage limitation by means of administrative
-       limits configured on the server.
-
-   (6) Server authentication by means of the TLS protocol or SASL
-       mechanisms.
-
-   LDAP may also be protected by means outside the LDAP protocol, e.g.,
-   with IP layer security [RFC4301].
-
-   Experience has shown that simply allowing implementations to pick and
-   choose the security mechanisms that will be implemented is not a
-   strategy that leads to interoperability.  In the absence of mandates,
-   clients will continue to be written that do not support any security
-   function supported by the server, or worse, they will only support
-   mechanisms that provide inadequate security for most circumstances.
-
-   It is desirable to allow clients to authenticate using a variety of
-   mechanisms including mechanisms where identities are represented as
-   distinguished names [X.501][RFC4512], in string form [RFC4514], or as
-   used in different systems (e.g., simple user names [RFC4013]).
-   Because some authentication mechanisms transmit credentials in plain
-   text form, and/or do not provide data security services and/or are
-   subject to passive attacks, it is necessary to ensure secure
-   interoperability by identifying a mandatory-to-implement mechanism
-   for establishing transport-layer security services.
-
-
-
-
-Harrison                    Standards Track                     [Page 5]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The set of security mechanisms provided in LDAP and described in this
-   document is intended to meet the security needs for a wide range of
-   deployment scenarios and still provide a high degree of
-   interoperability among various LDAP implementations and deployments.
-
-1.1.  Relationship to Other Documents
-
-   This document is an integral part of the LDAP Technical Specification
-   [RFC4510].
-
-   This document, together with [RFC4510], [RFC4511], and [RFC4512],
-   obsoletes RFC 2251 in its entirety.  Sections 4.2.1 (portions) and
-   4.2.2 of RFC 2251 are obsoleted by this document.  Appendix B.1
-   summarizes the substantive changes made to RFC 2251 by this document.
-
-   This document obsoletes RFC 2829 in its entirety.  Appendix B.2
-   summarizes the substantive changes made to RFC 2829 by this document.
-
-   Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511].  The
-   remainder of RFC 2830 is obsoleted by this document.  Appendix B.3
-   summarizes the substantive changes made to RFC 2830 by this document.
-
-1.2.  Conventions
-
-   The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
-   "MAY", and "OPTIONAL" in this document are to be interpreted as
-   described in RFC 2119 [RFC2119].
-
-   The term "user" represents any human or application entity that is
-   accessing the directory using a directory client.  A directory client
-   (or client) is also known as a directory user agent (DUA).
-
-   The term "transport connection" refers to the underlying transport
-   services used to carry the protocol exchange, as well as associations
-   established by these services.
-
-   The term "TLS layer" refers to TLS services used in providing
-   security services, as well as associations established by these
-   services.
-
-   The term "SASL layer" refers to SASL services used in providing
-   security services, as well as associations established by these
-   services.
-
-   The term "LDAP message layer" refers to the LDAP Message (PDU)
-   services used in providing directory services, as well as
-   associations established by these services.
-
-
-
-
-Harrison                    Standards Track                     [Page 6]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The term "LDAP session" refers to combined services (transport
-   connection, TLS layer, SASL layer, LDAP message layer) and their
-   associations.
-
-   In general, security terms in this document are used consistently
-   with the definitions provided in [RFC2828].  In addition, several
-   terms and concepts relating to security, authentication, and
-   authorization are presented in Appendix A of this document.  While
-   the formal definition of these terms and concepts is outside the
-   scope of this document, an understanding of them is prerequisite to
-   understanding much of the material in this document.  Readers who are
-   unfamiliar with security-related concepts are encouraged to review
-   Appendix A before reading the remainder of this document.
-
-2.  Implementation Requirements
-
-   LDAP server implementations MUST support the anonymous authentication
-   mechanism of the simple Bind method (Section 5.1.1).
-
-   LDAP implementations that support any authentication mechanism other
-   than the anonymous authentication mechanism of the simple Bind method
-   MUST support the name/password authentication mechanism of the simple
-   Bind method (Section 5.1.3) and MUST be capable of protecting this
-   name/password authentication using TLS as established by the StartTLS
-   operation (Section 3).
-
-   Implementations SHOULD disallow the use of the name/password
-   authentication mechanism by default when suitable data security
-   services are not in place, and they MAY provide other suitable data
-   security services for use with this authentication mechanism.
-
-   Implementations MAY support additional authentication mechanisms.
-   Some of these mechanisms are discussed below.
-
-   LDAP server implementations SHOULD support client assertion of
-   authorization identity via the SASL EXTERNAL mechanism (Section
-   5.2.3).
-
-   LDAP server implementations that support no authentication mechanism
-   other than the anonymous mechanism of the simple bind method SHOULD
-   support use of TLS as established by the StartTLS operation (Section
-   3).  (Other servers MUST support TLS per the second paragraph of this
-   section.)
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                     [Page 7]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   Implementations supporting TLS MUST support the
-   TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
-   TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.  Support for the
-   latter ciphersuite is recommended to encourage interoperability with
-   implementations conforming to earlier LDAP StartTLS specifications.
-
-3.  StartTLS Operation
-
-   The Start Transport Layer Security (StartTLS) operation defined in
-   Section 4.14 of [RFC4511] provides the ability to establish TLS
-   [RFC4346] in an LDAP session.
-
-   The goals of using the TLS protocol with LDAP are to ensure data
-   confidentiality and integrity, and to optionally provide for
-   authentication.  TLS expressly provides these capabilities, although
-   the authentication services of TLS are available to LDAP only in
-   combination with the SASL EXTERNAL authentication method (see Section
-   5.2.3), and then only if the SASL EXTERNAL implementation chooses to
-   make use of the TLS credentials.
-
-3.1.  TLS Establishment Procedures
-
-   This section describes the overall procedures clients and servers
-   must follow for TLS establishment.  These procedures take into
-   consideration various aspects of the TLS layer including discovery of
-   resultant security level and assertion of the client's authorization
-   identity.
-
-3.1.1.  StartTLS Request Sequencing
-
-   A client may send the StartTLS extended request at any time after
-   establishing an LDAP session, except:
-
-      - when TLS is currently established on the session,
-      - when a multi-stage SASL negotiation is in progress on the
-        session, or
-      - when there are outstanding responses for operation requests
-        previously issued on the session.
-
-   As described in [RFC4511], Section 4.14.1, a (detected) violation of
-   any of these requirements results in a return of the operationsError
-   resultCode.
-
-   Client implementers should ensure that they strictly follow these
-   operation sequencing requirements to prevent interoperability issues.
-   Operational experience has shown that violating these requirements
-
-
-
-
-
-Harrison                    Standards Track                     [Page 8]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   causes interoperability issues because there are race conditions that
-   prevent servers from detecting some violations of these requirements
-   due to factors such as server hardware speed and network latencies.
-
-   There is no general requirement that the client have or have not
-   already performed a Bind operation (Section 5) before sending a
-   StartTLS operation request; however, where a client intends to
-   perform both a Bind operation and a StartTLS operation, it SHOULD
-   first perform the StartTLS operation so that the Bind request and
-   response messages are protected by the data security services
-   established by the StartTLS operation.
-
-3.1.2.  Client Certificate
-
-   If an LDAP server requests or demands that a client provide a user
-   certificate during TLS negotiation and the client does not present a
-   suitable user certificate (e.g., one that can be validated), the
-   server may use a local security policy to determine whether to
-   successfully complete TLS negotiation.
-
-   If a client that has provided a suitable certificate subsequently
-   performs a Bind operation using the SASL EXTERNAL authentication
-   mechanism (Section 5.2.3), information in the certificate may be used
-   by the server to identify and authenticate the client.
-
-3.1.3.  Server Identity Check
-
-   In order to prevent man-in-the-middle attacks, the client MUST verify
-   the server's identity (as presented in the server's Certificate
-   message).  In this section, the client's understanding of the
-   server's identity (typically the identity used to establish the
-   transport connection) is called the "reference identity".
-
-   The client determines the type (e.g., DNS name or IP address) of the
-   reference identity and performs a comparison between the reference
-   identity and each subjectAltName value of the corresponding type
-   until a match is produced.  Once a match is produced, the server's
-   identity has been verified, and the server identity check is
-   complete.  Different subjectAltName types are matched in different
-   ways.  Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
-   various subjectAltName types.
-
-   The client may map the reference identity to a different type prior
-   to performing a comparison.  Mappings may be performed for all
-   available subjectAltName types to which the reference identity can be
-   mapped; however, the reference identity should only be mapped to
-   types for which the mapping is either inherently secure (e.g.,
-   extracting the DNS name from a URI to compare with a subjectAltName
-
-
-
-Harrison                    Standards Track                     [Page 9]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   of type dNSName) or for which the mapping is performed in a secure
-   manner (e.g., using DNSSEC, or using user- or admin-configured host-
-   to-address/address-to-host lookup tables).
-
-   The server's identity may also be verified by comparing the reference
-   identity to the Common Name (CN) [RFC4519] value in the leaf Relative
-   Distinguished Name (RDN) of the subjectName field of the server's
-   certificate.  This comparison is performed using the rules for
-   comparison of DNS names in Section 3.1.3.1, below, with the exception
-   that no wildcard matching is allowed.  Although the use of the Common
-   Name value is existing practice, it is deprecated, and Certification
-   Authorities are encouraged to provide subjectAltName values instead.
-   Note that the TLS implementation may represent DNs in certificates
-   according to X.500 or other conventions.  For example, some X.500
-   implementations order the RDNs in a DN using a left-to-right (most
-   significant to least significant) convention instead of LDAP's
-   right-to-left convention.
-
-   If the server identity check fails, user-oriented clients SHOULD
-   either notify the user (clients may give the user the opportunity to
-   continue with the LDAP session in this case) or close the transport
-   connection and indicate that the server's identity is suspect.
-   Automated clients SHOULD close the transport connection and then
-   return or log an error indicating that the server's identity is
-   suspect or both.
-
-   Beyond the server identity check described in this section, clients
-   should be prepared to do further checking to ensure that the server
-   is authorized to provide the service it is requested to provide.  The
-   client may need to make use of local policy information in making
-   this determination.
-
-3.1.3.1.  Comparison of DNS Names
-
-   If the reference identity is an internationalized domain name,
-   conforming implementations MUST convert it to the ASCII Compatible
-   Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
-   before comparison with subjectAltName values of type dNSName.
-   Specifically, conforming implementations MUST perform the conversion
-   operation specified in Section 4 of RFC 3490 as follows:
-
-      * in step 1, the domain name SHALL be considered a "stored
-        string";
-      * in step 3, set the flag called "UseSTD3ASCIIRules";
-      * in step 4, process each label with the "ToASCII" operation; and
-      * in step 5, change all label separators to U+002E (full stop).
-
-
-
-
-
-Harrison                    Standards Track                    [Page 10]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   After performing the "to-ASCII" conversion, the DNS labels and names
-   MUST be compared for equality according to the rules specified in
-   Section 3 of RFC3490.
-
-   The '*' (ASCII 42) wildcard character is allowed in subjectAltName
-   values of type dNSName, and then only as the left-most (least
-   significant) DNS label in that value.  This wildcard matches any
-   left-most DNS label in the server name.  That is, the subject
-   *.example.com matches the server names a.example.com and
-   b.example.com, but does not match example.com or a.b.example.com.
-
-3.1.3.2.  Comparison of IP Addresses
-
-   When the reference identity is an IP address, the identity MUST be
-   converted to the "network byte order" octet string representation
-   [RFC791][RFC2460].  For IP Version 4, as specified in RFC 791, the
-   octet string will contain exactly four octets.  For IP Version 6, as
-   specified in RFC 2460, the octet string will contain exactly sixteen
-   octets.  This octet string is then compared against subjectAltName
-   values of type iPAddress.  A match occurs if the reference identity
-   octet string and value octet strings are identical.
-
-3.1.3.3.  Comparison of Other subjectName Types
-
-   Client implementations MAY support matching against subjectAltName
-   values of other types as described in other documents.
-
-3.1.4.  Discovery of Resultant Security Level
-
-   After a TLS layer is established in an LDAP session, both parties are
-   to each independently decide whether or not to continue based on
-   local policy and the security level achieved.  If either party
-   decides that the security level is inadequate for it to continue, it
-   SHOULD remove the TLS layer immediately after the TLS (re)negotiation
-   has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below).
-   Implementations may reevaluate the security level at any time and,
-   upon finding it inadequate, should remove the TLS layer.
-
-3.1.5.  Refresh of Server Capabilities Information
-
-   After a TLS layer is established in an LDAP session, the client
-   SHOULD discard or refresh all information about the server that it
-   obtained prior to the initiation of the TLS negotiation and that it
-   did not obtain through secure mechanisms.  This protects against
-   man-in-the-middle attacks that may have altered any server
-   capabilities information retrieved prior to TLS layer installation.
-
-
-
-
-
-Harrison                    Standards Track                    [Page 11]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The server may advertise different capabilities after installing a
-   TLS layer.  In particular, the value of 'supportedSASLMechanisms' may
-   be different after a TLS layer has been installed (specifically, the
-   EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only
-   after a TLS layer has been installed).
-
-3.2.  Effect of TLS on Authorization State
-
-   The establishment, change, and/or closure of TLS may cause the
-   authorization state to move to a new state.  This is discussed
-   further in Section 4.
-
-3.3.  TLS Ciphersuites
-
-   Several issues should be considered when selecting TLS ciphersuites
-   that are appropriate for use in a given circumstance.  These issues
-   include the following:
-
-      - The ciphersuite's ability to provide adequate confidentiality
-        protection for passwords and other data sent over the transport
-        connection.  Client and server implementers should recognize
-        that some TLS ciphersuites provide no confidentiality
-        protection, while other ciphersuites that do provide
-        confidentiality protection may be vulnerable to being cracked
-        using brute force methods, especially in light of ever-
-        increasing CPU speeds that reduce the time needed to
-        successfully mount such attacks.
-
-      - Client and server implementers should carefully consider the
-        value of the password or data being protected versus the level
-        of confidentiality protection provided by the ciphersuite to
-        ensure that the level of protection afforded by the ciphersuite
-        is appropriate.
-
-      - The ciphersuite's vulnerability (or lack thereof) to man-in-the-
-        middle attacks.  Ciphersuites vulnerable to man-in-the-middle
-        attacks SHOULD NOT be used to protect passwords or sensitive
-        data, unless the network configuration is such that the danger
-        of a man-in-the-middle attack is negligible.
-
-      - After a TLS negotiation (either initial or subsequent) is
-        completed, both protocol peers should independently verify that
-        the security services provided by the negotiated ciphersuite are
-        adequate for the intended use of the LDAP session.  If they are
-        not, the TLS layer should be closed.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 12]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-4.  Authorization State
-
-   Every LDAP session has an associated authorization state.  This state
-   is comprised of numerous factors such as what (if any) authentication
-   state has been established, how it was established, and what security
-   services are in place.  Some factors may be determined and/or
-   affected by protocol events (e.g., Bind, StartTLS, or TLS closure),
-   and some factors may be determined by external events (e.g., time of
-   day or server load).
-
-   While it is often convenient to view authorization state in
-   simplistic terms (as we often do in this technical specification)
-   such as "an anonymous state", it is noted that authorization systems
-   in LDAP implementations commonly involve many factors that
-   interrelate in complex manners.
-
-   Authorization in LDAP is a local matter.  One of the key factors in
-   making authorization decisions is authorization identity.  The Bind
-   operation (defined in Section 4.2 of [RFC4511] and discussed further
-   in Section 5 below) allows information to be exchanged between the
-   client and server to establish an authorization identity for the LDAP
-   session.  The Bind operation may also be used to move the LDAP
-   session to an anonymous authorization state (see Section 5.1.1).
-
-   Upon initial establishment of the LDAP session, the session has an
-   anonymous authorization identity.  Among other things this implies
-   that the client need not send a BindRequest in the first PDU of the
-   LDAP message layer.  The client may send any operation request prior
-   to performing a Bind operation, and the server MUST treat it as if it
-   had been performed after an anonymous Bind operation (Section 5.1.1).
-
-   Upon receipt of a Bind request, the server immediately moves the
-   session to an anonymous authorization state.  If the Bind request is
-   successful, the session is moved to the requested authentication
-   state with its associated authorization state.  Otherwise, the
-   session remains in an anonymous state.
-
-   It is noted that other events both internal and external to LDAP may
-   result in the authentication and authorization states being moved to
-   an anonymous one.  For instance, the establishment, change, or
-   closure of data security services may result in a move to an
-   anonymous state, or the user's credential information (e.g.,
-   certificate) may have expired.  The former is an example of an event
-   internal to LDAP, whereas the latter is an example of an event
-   external to LDAP.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 13]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-5.  Bind Operation
-
-   The Bind operation ([RFC4511], Section 4.2) allows authentication
-   information to be exchanged between the client and server to
-   establish a new authorization state.
-
-   The Bind request typically specifies the desired authentication
-   identity.  Some Bind mechanisms also allow the client to specify the
-   authorization identity.  If the authorization identity is not
-   specified, the server derives it from the authentication identity in
-   an implementation-specific manner.
-
-   If the authorization identity is specified, the server MUST verify
-   that the client's authentication identity is permitted to assume
-   (e.g., proxy for) the asserted authorization identity.  The server
-   MUST reject the Bind operation with an invalidCredentials resultCode
-   in the Bind response if the client is not so authorized.
-
-5.1.  Simple Authentication Method
-
-   The simple authentication method of the Bind Operation provides three
-   authentication mechanisms:
-
-      - An anonymous authentication mechanism (Section 5.1.1).
-
-      - An unauthenticated authentication mechanism (Section 5.1.2).
-
-      - A name/password authentication mechanism using credentials
-        consisting of a name (in the form of an LDAP distinguished name
-        [RFC4514]) and a password (Section 5.1.3).
-
-5.1.1.  Anonymous Authentication Mechanism of Simple Bind
-
-   An LDAP client may use the anonymous authentication mechanism of the
-   simple Bind method to explicitly establish an anonymous authorization
-   state by sending a Bind request with a name value of zero length and
-   specifying the simple authentication choice containing a password
-   value of zero length.
-
-5.1.2.  Unauthenticated Authentication Mechanism of Simple Bind
-
-   An LDAP client may use the unauthenticated authentication mechanism
-   of the simple Bind method to establish an anonymous authorization
-   state by sending a Bind request with a name value (a distinguished
-   name in LDAP string form [RFC4514] of non-zero length) and specifying
-   the simple authentication choice containing a password value of zero
-   length.
-
-
-
-
-Harrison                    Standards Track                    [Page 14]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The distinguished name value provided by the client is intended to be
-   used for trace (e.g., logging) purposes only.  The value is not to be
-   authenticated or otherwise validated (including verification that the
-   DN refers to an existing directory object).  The value is not to be
-   used (directly or indirectly) for authorization purposes.
-
-   Unauthenticated Bind operations can have significant security issues
-   (see Section 6.3.1).  In particular, users intending to perform
-   Name/Password Authentication may inadvertently provide an empty
-   password and thus cause poorly implemented clients to request
-   Unauthenticated access.  Clients SHOULD be implemented to require
-   user selection of the Unauthenticated Authentication Mechanism by
-   means other than user input of an empty password.  Clients SHOULD
-   disallow an empty password input to a Name/Password Authentication
-   user interface.  Additionally, Servers SHOULD by default fail
-   Unauthenticated Bind requests with a resultCode of
-   unwillingToPerform.
-
-5.1.3.  Name/Password Authentication Mechanism of Simple Bind
-
-   An LDAP client may use the name/password authentication mechanism of
-   the simple Bind method to establish an authenticated authorization
-   state by sending a Bind request with a name value (a distinguished
-   name in LDAP string form [RFC4514] of non-zero length) and specifying
-   the simple authentication choice containing an OCTET STRING password
-   value of non-zero length.
-
-   Servers that map the DN sent in the Bind request to a directory entry
-   with an associated set of one or more passwords used with this
-   mechanism will compare the presented password to that set of
-   passwords.  The presented password is considered valid if it matches
-   any member of this set.
-
-   A resultCode of invalidDNSyntax indicates that the DN sent in the
-   name value is syntactically invalid.  A resultCode of
-   invalidCredentials indicates that the DN is syntactically correct but
-   not valid for purposes of authentication, that the password is not
-   valid for the DN, or that the server otherwise considers the
-   credentials invalid.  A resultCode of success indicates that the
-   credentials are valid and that the server is willing to provide
-   service to the entity these credentials identify.
-
-   Server behavior is undefined for Bind requests specifying the
-   name/password authentication mechanism with a zero-length name value
-   and a password value of non-zero length.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 15]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The name/password authentication mechanism of the simple Bind method
-   is not suitable for authentication in environments without
-   confidentiality protection.
-
-5.2.  SASL Authentication Method
-
-   The sasl authentication method of the Bind Operation provides
-   facilities for using any SASL mechanism including authentication
-   mechanisms and other services (e.g., data security services).
-
-5.2.1.  SASL Protocol Profile
-
-   LDAP allows authentication via any SASL mechanism [RFC4422].  As LDAP
-   includes native anonymous and name/password (plain text)
-   authentication methods, the ANONYMOUS [RFC4505] and PLAIN [PLAIN]
-   SASL mechanisms are typically not used with LDAP.
-
-   Each protocol that utilizes SASL services is required to supply
-   certain information profiling the way they are exposed through the
-   protocol ([RFC4422], Section 4).  This section explains how each of
-   these profiling requirements is met by LDAP.
-
-5.2.1.1.  SASL Service Name for LDAP
-
-   The SASL service name for LDAP is "ldap", which has been registered
-   with the IANA as a SASL service name.
-
-5.2.1.2.  SASL Authentication Initiation and Protocol Exchange
-
-   SASL authentication is initiated via a BindRequest message
-   ([RFC4511], Section 4.2) with the following parameters:
-
-      - The version is 3.
-      - The AuthenticationChoice is sasl.
-      - The mechanism element of the SaslCredentials sequence contains
-        the value of the desired SASL mechanism.
-      - The optional credentials field of the SaslCredentials sequence
-        MAY be used to provide an initial client response for mechanisms
-        that are defined to have the client send data first (see
-        [RFC4422], Sections 3 and 5).
-
-   In general, a SASL authentication protocol exchange consists of a
-   series of server challenges and client responses, the contents of
-   which are specific to and defined by the SASL mechanism.  Thus, for
-   some SASL authentication mechanisms, it may be necessary for the
-   client to respond to one or more server challenges by sending
-   BindRequest messages multiple times.  A challenge is indicated by the
-   server sending a BindResponse message with the resultCode set to
-
-
-
-Harrison                    Standards Track                    [Page 16]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   saslBindInProgress.  This indicates that the server requires the
-   client to send a new BindRequest message with the same SASL mechanism
-   to continue the authentication process.
-
-   To the LDAP message layer, these challenges and responses are opaque
-   binary tokens of arbitrary length.  LDAP servers use the
-   serverSaslCreds field (an OCTET STRING) in a BindResponse message to
-   transmit each challenge.  LDAP clients use the credentials field (an
-   OCTET STRING) in the SaslCredentials sequence of a BindRequest
-   message to transmit each response.  Note that unlike some Internet
-   protocols where SASL is used, LDAP is not text based and does not
-   Base64-transform these challenge and response values.
-
-   Clients sending a BindRequest message with the sasl choice selected
-   SHOULD send a zero-length value in the name field.  Servers receiving
-   a BindRequest message with the sasl choice selected SHALL ignore any
-   value in the name field.
-
-   A client may abort a SASL Bind negotiation by sending a BindRequest
-   message with a different value in the mechanism field of
-   SaslCredentials or with an AuthenticationChoice other than sasl.
-
-   If the client sends a BindRequest with the sasl mechanism field as an
-   empty string, the server MUST return a BindResponse with a resultCode
-   of authMethodNotSupported.  This will allow the client to abort a
-   negotiation if it wishes to try again with the same SASL mechanism.
-
-   The server indicates completion of the SASL challenge-response
-   exchange by responding with a BindResponse in which the resultCode
-   value is not saslBindInProgress.
-
-   The serverSaslCreds field in the BindResponse can be used to include
-   an optional challenge with a success notification for mechanisms that
-   are defined to have the server send additional data along with the
-   indication of successful completion.
-
-5.2.1.3.  Optional Fields
-
-   As discussed above, LDAP provides an optional field for carrying an
-   initial response in the message initiating the SASL exchange and
-   provides an optional field for carrying additional data in the
-   message indicating the outcome of the authentication exchange.  As
-   the mechanism-specific content in these fields may be zero length,
-   SASL requires protocol specifications to detail how an empty field is
-   distinguished from an absent field.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 17]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   Zero-length initial response data is distinguished from no initial
-   response data in the initiating message, a BindRequest PDU, by the
-   presence of the SaslCredentials.credentials OCTET STRING (of length
-   zero) in that PDU.  If the client does not intend to send an initial
-   response with the BindRequest initiating the SASL exchange, it MUST
-   omit the SaslCredentials.credentials OCTET STRING (rather than
-   include an zero-length OCTET STRING).
-
-   Zero-length additional data is distinguished from no additional
-   response data in the outcome message, a BindResponse PDU, by the
-   presence of the serverSaslCreds OCTET STRING (of length zero) in that
-   PDU.  If a server does not intend to send additional data in the
-   BindResponse message indicating outcome of the exchange, the server
-   SHALL omit the serverSaslCreds OCTET STRING (rather than including a
-   zero-length OCTET STRING).
-
-5.2.1.4.  Octet Where Negotiated Security Layers Take Effect
-
-   SASL layers take effect following the transmission by the server and
-   reception by the client of the final BindResponse in the SASL
-   exchange with a resultCode of success.
-
-   Once a SASL layer providing data integrity or confidentiality
-   services takes effect, the layer remains in effect until a new layer
-   is installed (i.e., at the first octet following the final
-   BindResponse of the Bind operation that caused the new layer to take
-   effect).  Thus, an established SASL layer is not affected by a failed
-   or non-SASL Bind.
-
-5.2.1.5.  Determination of Supported SASL Mechanisms
-
-   Clients may determine the SASL mechanisms a server supports by
-   reading the 'supportedSASLMechanisms' attribute from the root DSE
-   (DSA-Specific Entry) ([RFC4512], Section 5.1).  The values of this
-   attribute, if any, list the mechanisms the server supports in the
-   current LDAP session state.  LDAP servers SHOULD allow all clients --
-   even those with an anonymous authorization -- to retrieve the
-   'supportedSASLMechanisms' attribute of the root DSE both before and
-   after the SASL authentication exchange.  The purpose of the latter is
-   to allow the client to detect possible downgrade attacks (see Section
-   6.4 and [RFC4422], Section 6.1.2).
-
-   Because SASL mechanisms provide critical security functions, clients
-   and servers should be configurable to specify what mechanisms are
-   acceptable and allow only those mechanisms to be used.  Both clients
-   and servers must confirm that the negotiated security level meets
-   their requirements before proceeding to use the session.
-
-
-
-
-Harrison                    Standards Track                    [Page 18]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-5.2.1.6.  Rules for Using SASL Layers
-
-   Upon installing a SASL layer, the client SHOULD discard or refresh
-   all information about the server that it obtained prior to the
-   initiation of the SASL negotiation and that it did not obtain through
-   secure mechanisms.
-
-   If a lower-level security layer (such as TLS) is installed, any SASL
-   layer SHALL be layered on top of such security layers regardless of
-   the order of their negotiation.  In all other respects, the SASL
-   layer and other security layers act independently, e.g., if both a
-   TLS layer and a SASL layer are in effect, then removing the TLS layer
-   does not affect the continuing service of the SASL layer.
-
-5.2.1.7.  Support for Multiple Authentications
-
-   LDAP supports multiple SASL authentications as defined in [RFC4422],
-   Section 4.
-
-5.2.1.8.  SASL Authorization Identities
-
-   Some SASL mechanisms allow clients to request a desired authorization
-   identity for the LDAP session ([RFC4422], Section 3.4).  The decision
-   to allow or disallow the current authentication identity to have
-   access to the requested authorization identity is a matter of local
-   policy.  The authorization identity is a string of UTF-8 [RFC3629]
-   encoded [Unicode] characters corresponding to the following Augmented
-   Backus-Naur Form (ABNF) [RFC4234] grammar:
-
-      authzId = dnAuthzId / uAuthzId
-
-      ; distinguished-name-based authz id
-      dnAuthzId =  "dn:" distinguishedName
-
-      ; unspecified authorization id, UTF-8 encoded
-      uAuthzId = "u:" userid
-      userid = *UTF8 ; syntax unspecified
-
-   where the distinguishedName rule is defined in Section 3 of [RFC4514]
-   and the UTF8 rule is defined in Section 1.4 of [RFC4512].
-
-   The dnAuthzId choice is used to assert authorization identities in
-   the form of a distinguished name to be matched in accordance with the
-   distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15).
-   There is no requirement that the asserted distinguishedName value be
-   that of an entry in the directory.
-
-
-
-
-
-Harrison                    Standards Track                    [Page 19]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   The uAuthzId choice allows clients to assert an authorization
-   identity that is not in distinguished name form.  The format of
-   userid is defined only as a sequence of UTF-8 [RFC3629] encoded
-   [Unicode] characters, and any further interpretation is a local
-   matter.  For example, the userid could identify a user of a specific
-   directory service, be a login name, or be an email address.  A
-   uAuthzId SHOULD NOT be assumed to be globally unique.  To compare
-   uAuthzId values, each uAuthzId value MUST be prepared as a "query"
-   string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm,
-   and then the two values are compared octet-wise.
-
-   The above grammar is extensible.  The authzId production may be
-   extended to support additional forms of identities.  Each form is
-   distinguished by its unique prefix (see Section 3.12 of [RFC4520] for
-   registration requirements).
-
-5.2.2.  SASL Semantics within LDAP
-
-   Implementers must take care to maintain the semantics of SASL
-   specifications when handling data that has different semantics in the
-   LDAP protocol.
-
-   For example, the SASL DIGEST-MD5 authentication mechanism
-   [DIGEST-MD5] utilizes an authentication identity and a realm that are
-   syntactically simple strings and semantically simple username
-   [RFC4013] and realm values.  These values are not LDAP DNs, and there
-   is no requirement that they be represented or treated as such.
-
-5.2.3.  SASL EXTERNAL Authentication Mechanism
-
-   A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism
-   to request the LDAP server to authenticate and establish a resulting
-   authorization identity using security credentials exchanged by a
-   lower security layer (such as by TLS authentication).  If the
-   client's authentication credentials have not been established at a
-   lower security layer, the SASL EXTERNAL Bind MUST fail with a
-   resultCode of inappropriateAuthentication.  Although this situation
-   has the effect of leaving the LDAP session in an anonymous state
-   (Section 4), the state of any installed security layer is unaffected.
-
-   A client may either request that its authorization identity be
-   automatically derived from its authentication credentials exchanged
-   at a lower security layer, or it may explicitly provide a desired
-   authorization identity.  The former is known as an implicit
-   assertion, and the latter as an explicit assertion.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 20]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-5.2.3.1.  Implicit Assertion
-
-   An implicit authorization identity assertion is performed by invoking
-   a Bind request of the SASL form using the EXTERNAL mechanism name
-   that does not include the optional credentials field (found within
-   the SaslCredentials sequence in the BindRequest).  The server will
-   derive the client's authorization identity from the authentication
-   identity supplied by a security layer (e.g., a public key certificate
-   used during TLS layer installation) according to local policy.  The
-   underlying mechanics of how this is accomplished are implementation
-   specific.
-
-5.2.3.2.  Explicit Assertion
-
-   An explicit authorization identity assertion is performed by invoking
-   a Bind request of the SASL form using the EXTERNAL mechanism name
-   that includes the credentials field (found within the SaslCredentials
-   sequence in the BindRequest).  The value of the credentials field (an
-   OCTET STRING) is the asserted authorization identity and MUST be
-   constructed as documented in Section 5.2.1.8.
-
-6.  Security Considerations
-
-   Security issues are discussed throughout this document.  The
-   unsurprising conclusion is that security is an integral and necessary
-   part of LDAP.  This section discusses a number of LDAP-related
-   security considerations.
-
-6.1.  General LDAP Security Considerations
-
-   LDAP itself provides no security or protection from accessing or
-   updating the directory by means other than through the LDAP protocol,
-   e.g., from inspection of server database files by database
-   administrators.
-
-   Sensitive data may be carried in almost any LDAP message, and its
-   disclosure may be subject to privacy laws or other legal regulation
-   in many countries.  Implementers should take appropriate measures to
-   protect sensitive data from disclosure to unauthorized entities.
-
-   A session on which the client has not established data integrity and
-   privacy services (e.g., via StartTLS, IPsec, or a suitable SASL
-   mechanism) is subject to man-in-the-middle attacks to view and modify
-   information in transit.  Client and server implementers SHOULD take
-   measures to protect sensitive data in the LDAP session from these
-   attacks by using data protection services as discussed in this
-   document.  Clients and servers should provide the ability to be
-   configured to require these protections.  A resultCode of
-
-
-
-Harrison                    Standards Track                    [Page 21]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   confidentialityRequired indicates that the server requires
-   establishment of (stronger) data confidentiality protection in order
-   to perform the requested operation.
-
-   Access control should always be applied when reading sensitive
-   information or updating directory information.
-
-   Various security factors, including authentication and authorization
-   information and data security services may change during the course
-   of the LDAP session, or even during the performance of a particular
-   operation.  Implementations should be robust in the handling of
-   changing security factors.
-
-6.2.  StartTLS Security Considerations
-
-   All security gained via use of the StartTLS operation is gained by
-   the use of TLS itself.  The StartTLS operation, on its own, does not
-   provide any additional security.
-
-   The level of security provided through the use of TLS depends
-   directly on both the quality of the TLS implementation used and the
-   style of usage of that implementation.  Additionally, a man-in-the-
-   middle attacker can remove the StartTLS extended operation from the
-   'supportedExtension' attribute of the root DSE.  Both parties SHOULD
-   independently ascertain and consent to the security level achieved
-   once TLS is established and before beginning use of the TLS-
-   protected session.  For example, the security level of the TLS layer
-   might have been negotiated down to plaintext.
-
-   Clients MUST either warn the user when the security level achieved
-   does not provide an acceptable level of data confidentiality and/or
-   data integrity protection, or be configurable to refuse to proceed
-   without an acceptable level of security.
-
-   As stated in Section 3.1.2, a server may use a local security policy
-   to determine whether to successfully complete TLS negotiation.
-   Information in the user's certificate that is originated or verified
-   by the certification authority should be used by the policy
-   administrator when configuring the identification and authorization
-   policy.
-
-   Server implementers SHOULD allow server administrators to elect
-   whether and when data confidentiality and integrity are required, as
-   well as elect whether authentication of the client during the TLS
-   handshake is required.
-
-   Implementers should be aware of and understand TLS security
-   considerations as discussed in the TLS specification [RFC4346].
-
-
-
-Harrison                    Standards Track                    [Page 22]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-6.3.  Bind Operation Security Considerations
-
-   This section discusses several security considerations relevant to
-   LDAP authentication via the Bind operation.
-
-6.3.1.  Unauthenticated Mechanism Security Considerations
-
-   Operational experience shows that clients can (and frequently do)
-   misuse the unauthenticated authentication mechanism of the simple
-   Bind method (see Section 5.1.2).  For example, a client program might
-   make a decision to grant access to non-directory information on the
-   basis of successfully completing a Bind operation.  LDAP server
-   implementations may return a success response to an unauthenticated
-   Bind request.  This may erroneously leave the client with the
-   impression that the server has successfully authenticated the
-   identity represented by the distinguished name when in reality, an
-   anonymous authorization state has been established.  Clients that use
-   the results from a simple Bind operation to make authorization
-   decisions should actively detect unauthenticated Bind requests (by
-   verifying that the supplied password is not empty) and react
-   appropriately.
-
-6.3.2.  Name/Password Mechanism Security Considerations
-
-   The name/password authentication mechanism of the simple Bind method
-   discloses the password to the server, which is an inherent security
-   risk.  There are other mechanisms, such as SASL DIGEST-MD5
-   [DIGEST-MD5], that do not disclose the password to the server.
-
-6.3.3.  Password-Related Security Considerations
-
-   LDAP allows multi-valued password attributes.  In systems where
-   entries are expected to have one and only one password,
-   administrative controls should be provided to enforce this behavior.
-
-   The use of clear text passwords and other unprotected authentication
-   credentials is strongly discouraged over open networks when the
-   underlying transport service cannot guarantee confidentiality.  LDAP
-   implementations SHOULD NOT by default support authentication methods
-   using clear text passwords and other unprotected authentication
-   credentials unless the data on the session is protected using TLS or
-   other data confidentiality and data integrity protection.
-
-   The transmission of passwords in the clear -- typically for
-   authentication or modification -- poses a significant security risk.
-   This risk can be avoided by using SASL authentication [RFC4422]
-
-
-
-
-
-Harrison                    Standards Track                    [Page 23]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   mechanisms that do not transmit passwords in the clear or by
-   negotiating transport or session layer data confidentiality services
-   before transmitting password values.
-
-   To mitigate the security risks associated with the transfer of
-   passwords, a server implementation that supports any password-based
-   authentication mechanism that transmits passwords in the clear MUST
-   support a policy mechanism that at the time of authentication or
-   password modification, requires that:
-
-         A TLS layer has been successfully installed.
-
-         OR
-
-         Some other data confidentiality mechanism that protects the
-         password value from eavesdropping has been provided.
-
-         OR
-
-         The server returns a resultCode of confidentialityRequired for
-         the operation (i.e., name/password Bind with password value,
-         SASL Bind transmitting a password value in the clear, add or
-         modify including a userPassword value, etc.), even if the
-         password value is correct.
-
-   Server implementations may also want to provide policy mechanisms to
-   invalidate or otherwise protect accounts in situations where a server
-   detects that a password for an account has been transmitted in the
-   clear.
-
-6.3.4.  Hashed Password Security Considerations
-
-   Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
-   the password value that may be vulnerable to offline dictionary
-   attacks.  Implementers should take care to protect such hashed
-   password values during transmission using TLS or other
-   confidentiality mechanisms.
-
-6.4.  SASL Security Considerations
-
-   Until data integrity service is installed on an LDAP session, an
-   attacker can modify the transmitted values of the
-   'supportedSASLMechanisms' attribute response and thus downgrade the
-   list of available SASL mechanisms to include only the least secure
-   mechanism.  To detect this type of attack, the client may retrieve
-   the SASL mechanisms the server makes available both before and after
-   data integrity service is installed on an LDAP session.  If the
-   client finds that the integrity-protected list (the list obtained
-
-
-
-Harrison                    Standards Track                    [Page 24]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   after data integrity service was installed) contains a stronger
-   mechanism than those in the previously obtained list, the client
-   should assume the previously obtained list was modified by an
-   attacker.  In this circumstance it is recommended that the client
-   close the underlying transport connection and then reconnect to
-   reestablish the session.
-
-6.5.  Related Security Considerations
-
-   Additional security considerations relating to the various
-   authentication methods and mechanisms discussed in this document
-   apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
-   [RFC3629].
-
-7.  IANA Considerations
-
-   The IANA has updated the LDAP Protocol Mechanism registry to indicate
-   that this document and [RFC4511] provide the definitive technical
-   specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
-   operation.
-
-   The IANA has updated the LDAP LDAPMessage types registry to indicate
-   that this document and [RFC4511] provide the definitive technical
-   specification for the bindRequest (0) and bindResponse (1) message
-   types.
-
-   The IANA has updated the LDAP Bind Authentication Method registry to
-   indicate that this document and [RFC4511] provide the definitive
-   technical specification for the simple (0) and sasl (3) bind
-   authentication methods.
-
-   The IANA has updated the LDAP authzid prefixes registry to indicate
-   that this document provides the definitive technical specification
-   for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
-
-8.  Acknowledgements
-
-   This document combines information originally contained in RFC 2251,
-   RFC 2829, and RFC 2830.  RFC 2251 was a product of the Access,
-   Searching, and Indexing of Directories (ASID) Working Group.  RFC
-   2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
-   Working Group.
-
-   This document is a product of the IETF LDAP Revision (LDAPBIS)
-   working group.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 25]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-9.  Normative References
-
-   [RFC791]     Postel, J., "Internet Protocol", STD 5, RFC 791,
-                September 1981.
-
-   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
-                Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC2460]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
-                (IPv6) Specification", RFC 2460, December 1998.
-
-   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
-                Internationalized Strings ("stringprep")", RFC 3454,
-                December 2002.
-
-   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
-                "Internationalizing Domain Names in Applications
-                (IDNA)", RFC 3490, March 2003.
-
-   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
-                10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4013]    Zeilenga, K., "SASLprep: Stringprep Profile for User
-                Names and Passwords", RFC 4013, February 2005.
-
-   [RFC4234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4346]    Dierks, T. and E. Rescorla, "The TLS Protocol Version
-                1.1", RFC 4346, March 2006.
-
-   [RFC4422]    Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
-                Authentication and Security Layer (SASL)", RFC 4422,
-                June 2006.
-
-   [RFC4510]    Zeilenga, K., Ed., "Lightweight Directory Access
-                Protocol (LDAP): Technical Specification Road Map", RFC
-                4510, June 2006.
-
-   [RFC4511]    Sermersheim, J., Ed., "Lightweight Directory Access
-                Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]    Zeilenga, K., "Lightweight Directory Access Protocol
-                (LDAP): Directory Information Models", RFC 4512, June
-                2006.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 26]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   [RFC4514]    Zeilenga, K., Ed., "Lightweight Directory Access
-                Protocol (LDAP): String Representation of Distinguished
-                Names", RFC 4514, June 2006.
-
-   [RFC4517]    Legg, S., Ed., "Lightweight Directory Access Protocol
-                (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                2006.
-
-   [RFC4519]    Sciberras, A., Ed., "Lightweight Directory Access
-                Protocol (LDAP): Schema for User Applications", RFC
-                4519, June 2006.
-
-   [RFC4520]    Zeilenga, K., "Internet Assigned Numbers Authority
-                (IANA) Considerations for the Lightweight Directory
-                Access Protocol (LDAP)", BCP 64, RFC 4520, 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/).
-
-   [X.501]      ITU-T Rec. X.501, "The Directory: Models", 1993.
-
-10.  Informative References
-
-   [DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
-                Authentication as a SASL Mechanism", Work in Progress,
-                March 2006.
-
-   [PLAIN]      Zeilenga, K., "The Plain SASL Mechanism", Work in
-                Progress, March 2005.
-
-   [RFC2828]    Shirey, R., "Internet Security Glossary", FYI 36, RFC
-                2828, May 2000.
-
-   [RFC4301]    Kent, S. and K. Seo, "Security Architecture for the
-                Internet Protocol", RFC 4301, December 2005.
-
-   [RFC4505]    Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
-                June 2006.
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 27]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-Appendix A.  Authentication and Authorization Concepts
-
-   This appendix is non-normative.
-
-   This appendix defines basic terms, concepts, and interrelationships
-   regarding authentication, authorization, credentials, and identity.
-   These concepts are used in describing how various security approaches
-   are utilized in client authentication and authorization.
-
-A.1.  Access Control Policy
-
-   An access control policy is a set of rules defining the protection of
-   resources, generally in terms of the capabilities of persons or other
-   entities accessing those resources.  Security objects and mechanisms,
-   such as those described here, enable the expression of access control
-   policies and their enforcement.
-
-A.2.  Access Control Factors
-
-   A request, when it is being processed by a server, may be associated
-   with a wide variety of security-related factors.  The server uses
-   these factors to determine whether and how to process the request.
-   These are called access control factors (ACFs).  They might include
-   source IP address, encryption strength, the type of operation being
-   requested, time of day, etc..  Some factors may be specific to the
-   request itself; others may be associated with the transport
-   connection via which the request is transmitted; and others (e.g.,
-   time of day) may be "environmental".
-
-   Access control policies are expressed in terms of access control
-   factors; for example, "a request having ACFs i,j,k can perform
-   operation Y on resource Z".  The set of ACFs that a server makes
-   available for such expressions is implementation specific.
-
-A.3.  Authentication, Credentials, Identity
-
-   Authentication credentials are the evidence supplied by one party to
-   another, asserting the identity of the supplying party (e.g., a user)
-   who is attempting to establish a new authorization state with the
-   other party (typically a server).  Authentication is the process of
-   generating, transmitting, and verifying these credentials and thus
-   the identity they assert.  An authentication identity is the name
-   presented in a credential.
-
-   There are many forms of authentication credentials.  The form used
-   depends upon the particular authentication mechanism negotiated by
-   the parties.  X.509 certificates, Kerberos tickets, and simple
-   identity and password pairs are all examples of authentication
-
-
-
-Harrison                    Standards Track                    [Page 28]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   credential forms.  Note that an authentication mechanism may
-   constrain the form of authentication identities used with it.
-
-A.4.  Authorization Identity
-
-   An authorization identity is one kind of access control factor.  It
-   is the name of the user or other entity that requests that operations
-   be performed.  Access control policies are often expressed in terms
-   of authorization identities; for example, "entity X can perform
-   operation Y on resource Z".
-
-   The authorization identity of an LDAP session is often semantically
-   the same as the authentication identity presented by the client, but
-   it may be different.  SASL allows clients to specify an authorization
-   identity distinct from the authentication identity asserted by the
-   client's credentials.  This permits agents such as proxy servers to
-   authenticate using their own credentials, yet request the access
-   privileges of the identity for which they are proxying [RFC4422].
-   Also, the form of authentication identity supplied by a service like
-   TLS may not correspond to the authorization identities used to
-   express a server's access control policy, thus requiring a server-
-   specific mapping to be done.  The method by which a server composes
-   and validates an authorization identity from the authentication
-   credentials supplied by a client is implementation specific.
-
-Appendix B.  Summary of Changes
-
-   This appendix is non-normative.
-
-   This appendix summarizes substantive changes made to RFC 2251, RFC
-   2829 and RFC 2830.  In addition to the specific changes detailed
-   below, the reader of this document should be aware that numerous
-   general editorial changes have been made to the original content from
-   the source documents.  These changes include the following:
-
-   - The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
-     RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
-     combined into a single document.
-
-   - The combined material was substantially reorganized and edited to
-     group related subjects, improve the document flow, and clarify
-     intent.
-
-   - Changes were made throughout the text to align with definitions of
-     LDAP protocol layers and IETF security terminology.
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 29]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-   - Substantial updates and additions were made to security
-     considerations from both documents based on current operational
-     experience.
-
-B.1.  Changes Made to RFC 2251
-
-   This section summarizes the substantive changes made to Sections
-   4.2.1 and 4.2.2 of RFC 2251 by this document.  Additional substantive
-   changes to Section 4.2.1 of RFC 2251 are also documented in
-   [RFC4511].
-
-B.1.1.  Section 4.2.1 ("Sequencing of the Bind Request")
-
-   - Paragraph 1: Removed the sentence, "If at any stage the client
-     wishes to abort the bind process it MAY unbind and then drop the
-     underlying connection".  The Unbind operation still permits this
-     behavior, but it is not documented explicitly.
-
-   - Clarified that the session is moved to an anonymous state upon
-     receipt of the BindRequest PDU and that it is only moved to a non-
-     anonymous state if and when the Bind request is successful.
-
-B.1.2.  Section 4.2.2 ("Authentication and Other Security Services")
-
-   - RFC 2251 states that anonymous authentication MUST be performed
-     using the simple bind method.  This specification defines the
-     anonymous authentication mechanism of the simple bind method and
-     requires all conforming implementations to support it.  Other
-     authentication mechanisms producing anonymous authentication and
-     authorization state may also be implemented and used by conforming
-     implementations.
-
-B.2.  Changes Made to RFC 2829
-
-   This section summarizes the substantive changes made to RFC 2829.
-
-B.2.1.  Section 4 ("Required security mechanisms")
-
-   - The name/password authentication mechanism (see Section B.2.5
-     below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
-     LDAP's mandatory-to-implement password-based authentication
-     mechanism.  Implementations are encouraged to continue supporting
-     SASL DIGEST-MD5 [DIGEST-MD5].
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 30]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-B.2.2.  Section 5.1 ("Anonymous authentication procedure")
-
-   - Clarified that anonymous authentication involves a name value of
-     zero length and a password value of zero length.  The
-     unauthenticated authentication mechanism was added to handle simple
-     Bind requests involving a name value with a non-zero length and a
-     password value of zero length.
-
-B.2.3.  Section 6 ("Password-based authentication")
-
-   - See Section B.2.1.
-
-B.2.4.  Section 6.1 ("Digest authentication")
-
-   - As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
-     implement, this section is now historical and was not included in
-     this document.  RFC 2829, Section 6.1, continues to document the
-     SASL DIGEST-MD5 authentication mechanism.
-
-B.2.5.  Section 6.2 ("'simple' authentication choice under TLS
-        encryption")
-
-   - Renamed the "simple" authentication mechanism to the name/password
-     authentication mechanism to better describe it.
-
-   - The use of TLS was generalized to align with definitions of LDAP
-     protocol layers.  TLS establishment is now discussed as an
-     independent subject and is generalized for use with all
-     authentication mechanisms and other security layers.
-
-   - Removed the implication that the userPassword attribute is the sole
-     location for storage of password values to be used in
-     authentication.  There is no longer any implied requirement for how
-     or where passwords are stored at the server for use in
-     authentication.
-
-B.2.6.  Section 6.3 ("Other authentication choices with TLS")
-
-   - See Section B.2.5.
-
-B.2.7.  Section 7.1 ("Certificate-based authentication with TLS")
-
-   - See Section B.2.5.
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 31]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-B.2.8.  Section 8 ("Other mechanisms")
-
-   - All SASL authentication mechanisms are explicitly allowed within
-     LDAP.  Specifically, this means the SASL ANONYMOUS and SASL PLAIN
-     mechanisms are no longer precluded from use within LDAP.
-
-B.2.9.  Section 9 ("Authorization Identity")
-
-   - Specified matching rules for dnAuthzId and uAuthzId values.  In
-     particular, the DN value in the dnAuthzId form must be matched
-     using DN matching rules, and the uAuthzId value MUST be prepared
-     using SASLprep rules before being compared octet-wise.
-
-   - Clarified that uAuthzId values should not be assumed to be globally
-     unique.
-
-B.2.10.  Section 10 ("TLS Ciphersuites")
-
-   - TLS ciphersuite recommendations are no longer included in this
-     specification.  Implementations must now support the
-     TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
-     support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
-
-   - Clarified that anonymous authentication involves a name value of
-     zero length and a password value of zero length.  The
-     unauthenticated authentication mechanism was added to handle simple
-     Bind requests involving a name value with a non-zero length and a
-     password value of zero length.
-
-B.3.  Changes Made to RFC 2830
-
-   This section summarizes the substantive changes made to Sections 3
-   and 5 of RFC 2830.  Readers should consult [RFC4511] for summaries of
-   changes to other sections.
-
-B.3.1.  Section 3.6 ("Server Identity Check")
-
-   - Substantially updated the server identity check algorithm to ensure
-     that it is complete and robust.  In particular, the use of all
-     relevant values in the subjectAltName and the subjectName fields
-     are covered by the algorithm and matching rules are specified for
-     each type of value.  Mapped (derived) forms of the server identity
-     may now be used when the mapping is performed in a secure fashion.
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 32]
-
-RFC 4513              LDAP Authentication Methods              June 2006
-
-
-B.3.2.  Section 3.7 ("Refresh of Server Capabilities Information")
-
-   - Clients are no longer required to always refresh information about
-     server capabilities following TLS establishment.  This is to allow
-     for situations where this information was obtained through a secure
-     mechanism.
-
-B.3.3.  Section 5 ("Effects of TLS on a Client's Authorization
-        Identity")
-
-   - Establishing a TLS layer on an LDAP session may now cause the
-     authorization state of the LDAP session to change.
-
-B.3.4.  Section 5.2 ("TLS Connection Closure Effects")
-
-   - Closing a TLS layer on an LDAP session changes the authentication
-     and authorization state of the LDAP session based on local policy.
-     Specifically, this means that implementations are not required to
-     change the authentication and authorization states to anonymous
-     upon TLS closure.
-
-   - Replaced references to RFC 2401 with RFC 4301.
-
-Author's Address
-
-   Roger Harrison
-   Novell, Inc.
-   1800 S.  Novell Place
-   Provo, UT 84606
-   USA
-
-   Phone: +1 801 861 2642
-   EMail: roger_harrison at novell.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 33]
-
-RFC 4513              LDAP Authentication Methods              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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Harrison                    Standards Track                    [Page 34]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4514.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4514.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4514.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                   K. Zeilenga, Ed.
-Request for Comments: 4514                           OpenLDAP Foundation
-Obsoletes: 2253                                                June 2006
-Category: Standards Track
-
-
-             Lightweight Directory Access Protocol (LDAP):
-              String Representation of Distinguished Names
-
-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 X.500 Directory uses distinguished names (DNs) as primary keys to
-   entries in the directory.  This document defines the string
-   representation used in the Lightweight Directory Access Protocol
-   (LDAP) to transfer distinguished names.  The string representation is
-   designed to give a clean representation of commonly used
-   distinguished names, while being able to represent any distinguished
-   name.
-
-1.  Background and Intended Usage
-
-   In X.500-based directory systems [X.500], including those accessed
-   using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
-   distinguished names (DNs) are used to unambiguously refer to
-   directory entries [X.501][RFC4512].
-
-   The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
-   In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
-   directory protocols), DNs are encoded using the Basic Encoding Rules
-   (BER) [X.690].  In LDAP, DNs are represented in the string form
-   described in this document.
-
-   It is important to have a common format to be able to unambiguously
-   represent a distinguished name.  The primary goal of this
-   specification is ease of encoding and decoding.  A secondary goal is
-   to have names that are human readable.  It is not expected that LDAP
-
-
-
-Zeilenga                    Standards Track                     [Page 1]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-   implementations with a human user interface would display these
-   strings directly to the user, but that they would most likely be
-   performing translations (such as expressing attribute type names in
-   the local national language).
-
-   This document defines the string representation of Distinguished
-   Names used in LDAP [RFC4511][RFC4517].  Section 2 details the
-   RECOMMENDED algorithm for converting a DN from its ASN.1 structured
-   representation to a string.  Section 3 details how to convert a DN
-   from a string to an ASN.1 structured representation.
-
-   While other documents may define other algorithms for converting a DN
-   from its ASN.1 structured representation to a string, all algorithms
-   MUST produce strings that adhere to the requirements of Section 3.
-
-   This document does not define a canonical string representation for
-   DNs.  Comparison of DNs for equality is to be performed in accordance
-   with the distinguishedNameMatch matching rule [RFC4517].
-
-   This document is a integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.  This document obsoletes
-   RFC 2253.  Changes since RFC 2253 are summarized in Appendix B.
-
-   This specification assumes familiarity with X.500 [X.500] and the
-   concept of Distinguished Name [X.501][RFC4512].
-
-1.1.  Conventions
-
-   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>.
-
-   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].
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 2]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-2.  Converting DistinguishedName from ASN.1 to a String
-
-   X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
-   name.  The following is a variant provided for discussion purposes.
-
-      DistinguishedName ::= RDNSequence
-
-      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
-
-      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
-          AttributeTypeAndValue
-
-      AttributeTypeAndValue ::= SEQUENCE {
-          type  AttributeType,
-          value AttributeValue }
-
-   This section defines the RECOMMENDED algorithm for converting a
-   distinguished name from an ASN.1-structured representation to a UTF-8
-   [RFC3629] encoded Unicode [Unicode] character string representation.
-   Other documents may describe other algorithms for converting a
-   distinguished name to a string, but only strings that conform to the
-   grammar defined in Section 3 SHALL be produced by LDAP
-   implementations.
-
-2.1.  Converting the RDNSequence
-
-   If the RDNSequence is an empty sequence, the result is the empty or
-   zero-length string.
-
-   Otherwise, the output consists of the string encodings of each
-   RelativeDistinguishedName in the RDNSequence (according to Section
-   2.2), starting with the last element of the sequence and moving
-   backwards toward the first.
-
-   The encodings of adjoining RelativeDistinguishedNames are separated
-   by a comma (',' U+002C) character.
-
-2.2.  Converting RelativeDistinguishedName
-
-   When converting from an ASN.1 RelativeDistinguishedName to a string,
-   the output consists of the string encodings of each
-   AttributeTypeAndValue (according to Section 2.3), in any order.
-
-   Where there is a multi-valued RDN, the outputs from adjoining
-   AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
-   character.
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 3]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-2.3.  Converting AttributeTypeAndValue
-
-   The AttributeTypeAndValue is encoded as the string representation of
-   the AttributeType, followed by an equals sign ('=' U+003D) character,
-   followed by the string representation of the AttributeValue.  The
-   encoding of the AttributeValue is given in Section 2.4.
-
-   If the AttributeType is defined to have a short name (descriptor)
-   [RFC4512] and that short name is known to be registered [REGISTRY]
-   [RFC4520] as identifying the AttributeType, that short name, a
-   <descr>, is used.  Otherwise the AttributeType is encoded as the
-   dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
-   The <descr> and <numericoid> are defined in [RFC4512].
-
-   Implementations are not expected to dynamically update their
-   knowledge of registered short names.  However, implementations SHOULD
-   provide a mechanism to allow their knowledge of registered short
-   names to be updated.
-
-2.4.  Converting an AttributeValue from ASN.1 to a String
-
-   If the AttributeType is of the dotted-decimal form, the
-   AttributeValue is represented by an number sign ('#' U+0023)
-   character followed by the hexadecimal encoding of each of the octets
-   of the BER encoding of the X.500 AttributeValue.  This form is also
-   used when the syntax of the AttributeValue does not have an LDAP-
-   specific ([RFC4517], Section 3.1) string encoding defined for it, or
-   the LDAP-specific string encoding is not restricted to UTF-8-encoded
-   Unicode characters.  This form may also be used in other cases, such
-   as when a reversible string representation is desired (see Section
-   5.2).
-
-   Otherwise, if the AttributeValue is of a syntax that has a LDAP-
-   specific string encoding, the value is converted first to a UTF-8-
-   encoded Unicode string according to its syntax specification (see
-   [RFC4517], Section 3.3, for examples).  If that UTF-8-encoded Unicode
-   string does not have any of the following characters that need
-   escaping, then that string can be used as the string representation
-   of the value.
-
-      - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
-        the beginning of the string;
-
-      - a space (' ' U+0020) character occurring at the end of the
-        string;
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 4]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-      - one of the characters '"', '+', ',', ';', '<', '>',  or '\'
-        (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
-        respectively);
-
-      - the null (U+0000) character.
-
-   Other characters may be escaped.
-
-   Each octet of the character to be escaped is replaced by a backslash
-   and two hex digits, which form a single octet in the code of the
-   character.  Alternatively, if and only if the character to be escaped
-   is one of
-
-      ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
-      (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
-       U+003C, U+003D, U+003E, U+005C, respectively)
-
-   it can be prefixed by a backslash ('\' U+005C).
-
-   Examples of the escaping mechanism are shown in Section 4.
-
-3.  Parsing a String Back to a Distinguished Name
-
-   The string representation of Distinguished Names is restricted to
-   UTF-8 [RFC3629] encoded Unicode [Unicode] characters.  The structure
-   of this string representation is specified using the following
-   Augmented BNF [RFC4234] grammar:
-
-      distinguishedName = [ relativeDistinguishedName
-          *( COMMA relativeDistinguishedName ) ]
-      relativeDistinguishedName = attributeTypeAndValue
-          *( PLUS attributeTypeAndValue )
-      attributeTypeAndValue = attributeType EQUALS attributeValue
-      attributeType = descr / numericoid
-      attributeValue = string / hexstring
-
-      ; The following characters are to be escaped when they appear
-      ; in the value to be encoded: ESC, one of <escaped>, leading
-      ; SHARP or SPACE, trailing SPACE, and NULL.
-      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
-         ( trailchar / pair ) ] ]
-
-      leadchar = LUTF1 / UTFMB
-      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
-         %x3D / %x3F-5B / %x5D-7F
-
-      trailchar  = TUTF1 / UTFMB
-      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
-
-
-
-Zeilenga                    Standards Track                     [Page 5]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-         %x3D / %x3F-5B / %x5D-7F
-
-      stringchar = SUTF1 / UTFMB
-      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
-         %x3D / %x3F-5B / %x5D-7F
-
-      pair = ESC ( ESC / special / hexpair )
-      special = escaped / SPACE / SHARP / EQUALS
-      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
-      hexstring = SHARP 1*hexpair
-      hexpair = HEX HEX
-
-   where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
-   <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
-   <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
-
-   Each <attributeType>, either a <descr> or a <numericoid>, refers to
-   an attribute type of an attribute value assertion (AVA).  The
-   <attributeType> is followed by an <EQUALS> and an <attributeValue>.
-   The <attributeValue> is either in <string> or <hexstring> form.
-
-   If in <string> form, a LDAP string representation asserted value can
-   be obtained by replacing (left to right, non-recursively) each <pair>
-   appearing in the <string> as follows:
-
-      replace <ESC><ESC> with <ESC>;
-      replace <ESC><special> with <special>;
-      replace <ESC><hexpair> with the octet indicated by the <hexpair>.
-
-   If in <hexstring> form, a BER representation can be obtained from
-   converting each <hexpair> of the <hexstring> to the octet indicated
-   by the <hexpair>.
-
-   There is one or more attribute value assertions, separated by <PLUS>,
-   for a relative distinguished name.
-
-   There is zero or more relative distinguished names, separated by
-   <COMMA>, for a distinguished name.
-
-   Implementations MUST recognize AttributeType name strings
-   (descriptors) listed in the following table, but MAY recognize other
-   name strings.
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 6]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-      String  X.500 AttributeType
-      ------  --------------------------------------------
-      CN      commonName (2.5.4.3)
-      L       localityName (2.5.4.7)
-      ST      stateOrProvinceName (2.5.4.8)
-      O       organizationName (2.5.4.10)
-      OU      organizationalUnitName (2.5.4.11)
-      C       countryName (2.5.4.6)
-      STREET  streetAddress (2.5.4.9)
-      DC      domainComponent (0.9.2342.19200300.100.1.25)
-      UID     userId (0.9.2342.19200300.100.1.1)
-
-   These attribute types are described in [RFC4519].
-
-   Implementations MAY recognize other DN string representations.
-   However, as there is no requirement that alternative DN string
-   representations be recognized (and, if so, how), implementations
-   SHOULD only generate DN strings in accordance with Section 2 of this
-   document.
-
-4.  Examples
-
-   This notation is designed to be convenient for common forms of name.
-   This section gives a few examples of distinguished names written
-   using this notation.  First is a name containing three relative
-   distinguished names (RDNs):
-
-      UID=jsmith,DC=example,DC=net
-
-   Here is an example of a name containing three RDNs, in which the
-   first RDN is multi-valued:
-
-      OU=Sales+CN=J.  Smith,DC=example,DC=net
-
-   This example shows the method of escaping of a special characters
-   appearing in a common name:
-
-      CN=James \"Jim\" Smith\, III,DC=example,DC=net
-
-   The following shows the method for encoding a value that contains a
-   carriage return character:
-
-      CN=Before\0dAfter,DC=example,DC=net
-
-   In this RDN example, the type in the RDN is unrecognized, and the
-   value is the BER encoding of an OCTET STRING containing two octets,
-   0x48 and 0x69.
-
-
-
-
-Zeilenga                    Standards Track                     [Page 7]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-      1.3.6.1.4.1.1466.0=#04024869
-
-   Finally, this example shows an RDN whose commonName value consists of
-   5 letters:
-
-      Unicode Character                Code       UTF-8   Escaped
-      -------------------------------  ------     ------  --------
-      LATIN CAPITAL LETTER L           U+004C     0x4C    L
-      LATIN SMALL LETTER U             U+0075     0x75    u
-      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
-      LATIN SMALL LETTER I             U+0069     0x69    i
-      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87
-
-   This could be encoded in printable ASCII [ASCII] (useful for
-   debugging purposes) as:
-
-      CN=Lu\C4\8Di\C4\87
-
-5.  Security Considerations
-
-   The following security considerations are specific to the handling of
-   distinguished names.  LDAP security considerations are discussed in
-   [RFC4511] and other documents comprising the LDAP Technical
-   Specification [RFC4510].
-
-5.1.  Disclosure
-
-   Distinguished Names typically consist of descriptive information
-   about the entries they name, which can be people, organizations,
-   devices, or other real-world objects.  This frequently includes some
-   of the following kinds of information:
-
-      - the common name of the object (i.e., a person's full name)
-      - an email or TCP/IP address
-      - its physical location (country, locality, city, street address)
-      - organizational attributes (such as department name or
-        affiliation)
-
-   In some cases, such information can be considered sensitive.  In many
-   countries, privacy laws exist that prohibit disclosure of certain
-   kinds of descriptive information (e.g., email addresses).  Hence,
-   server implementers are encouraged to support Directory Information
-   Tree (DIT) structural rules and name forms [RFC4512], as these
-   provide a mechanism for administrators to select appropriate naming
-   attributes for entries.  Administrators are encouraged to use
-   mechanisms, access controls, and other administrative controls that
-   may be available to restrict use of attributes containing sensitive
-   information in naming of entries.   Additionally, use of
-
-
-
-Zeilenga                    Standards Track                     [Page 8]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-   authentication and data security services in LDAP [RFC4513][RFC4511]
-   should be considered.
-
-5.2.  Use of Distinguished Names in Security Applications
-
-   The transformations of an AttributeValue value from its X.501 form to
-   an LDAP string representation are not always reversible back to the
-   same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
-   form.  An example of a situation that requires the DER form of a
-   distinguished name is the verification of an X.509 certificate.
-
-   For example, a distinguished name consisting of one RDN with one AVA,
-   in which the type is commonName and the value is of the TeletexString
-   choice with the letters 'Sam', would be represented in LDAP as the
-   string <CN=Sam>.  Another distinguished name in which the value is
-   still 'Sam', but is of the PrintableString choice, would have the
-   same representation <CN=Sam>.
-
-   Applications that require the reconstruction of the DER form of the
-   value SHOULD NOT use the string representation of attribute syntaxes
-   when converting a distinguished name to the LDAP format.  Instead,
-   they SHOULD use the hexadecimal form prefixed by the number sign ('#'
-   U+0023) as described in the first paragraph of Section 2.4.
-
-6.  Acknowledgements
-
-   This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
-   Steve Kille.  RFC 2253 was a product of the IETF ASID Working Group.
-
-   This document is a product of the IETF LDAPBIS Working Group.
-
-7.  References
-
-7.1.  Normative References
-
-   [REGISTRY]    IANA, Object Identifier Descriptors Registry,
-                 <http://www.iana.org/assignments/ldap-parameters>.
-
-   [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/).
-
-
-
-
-
-Zeilenga                    Standards Track                     [Page 9]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-   [X.501]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
-                 2:1994).
-
-   [X.680]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "Abstract
-                 Syntax Notation One (ASN.1) - Specification of Basic
-                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
-
-   [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
-                 Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
-                 10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
-                 Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Technical Specification Road Map", RFC
-                 4510, June 2006.
-
-   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
-                 (LDAP): Directory Information Models", RFC 4512, June
-                 2006.
-
-   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Authentication Methods and Security
-                 Mechanisms", RFC 4513, June 2006.
-
-   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
-                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
-                 2006.
-
-   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
-                 Protocol (LDAP): Schema for User Applications", RFC
-                 4519, June 2006.
-
-   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
-                 (IANA) Considerations for the Lightweight Directory
-                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 10]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-7.2.  Informative References
-
-   [ASCII]       Coded Character Set--7-bit American Standard Code for
-                 Information Interchange, ANSI X3.4-1986.
-
-   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
-                 #17, Character Encoding Model", UTR17,
-                 <http://www.unicode.org/unicode/reports/tr17/>, August
-                 2000.
-
-   [Glossary]    The Unicode Consortium, "Unicode Glossary",
-                 <http://www.unicode.org/glossary/>.
-
-   [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.511]       International Telecommunication Union -
-                 Telecommunication Standardization Sector, "The
-                 Directory: Abstract Service Definition", X.511(1993)
-                 (also ISO/IEC 9594-3:1993).
-
-   [X.690]       International Telecommunication Union -
-                 Telecommunication Standardization Sector,
-                 "Specification of ASN.1 encoding rules: Basic Encoding
-                 Rules (BER), Canonical Encoding Rules (CER), and
-                 Distinguished Encoding Rules (DER)", X.690(1997) (also
-                 ISO/IEC 8825-1:1998).
-
-   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
-                 Technical Specification", RFC 2849, June 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 11]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-Appendix A.  Presentation Issues
-
-   This appendix is provided for informational purposes only; it is not
-   a normative part of this specification.
-
-   The string representation described in this document is not intended
-   to be presented to humans without translation.  However, at times it
-   may be desirable to present non-translated DN strings to users.  This
-   section discusses presentation issues associated with non-translated
-   DN strings.  Issues with presentation of translated DN strings are
-   not discussed in this appendix.  Transcoding issues are also not
-   discussed in this appendix.
-
-   This appendix provides guidance for applications presenting DN
-   strings to users.  This section is not comprehensive; it does not
-   discuss all presentation issues that implementers may face.
-
-   Not all user interfaces are capable of displaying the full set of
-   Unicode characters.  Some Unicode characters are not displayable.
-
-   It is recommended that human interfaces use the optional hex pair
-   escaping mechanism (Section 2.3) to produce a string representation
-   suitable for display to the user.  For example, an application can
-   generate a DN string for display that escapes all non-printable
-   characters appearing in the AttributeValue's string representation
-   (as demonstrated in the final example of Section 4).
-
-   When a DN string is displayed in free-form text, it is often
-   necessary to distinguish the DN string from surrounding text.  While
-   this is often done with whitespace (as demonstrated in Section 4), it
-   is noted that DN strings may end with whitespace.  Careful readers of
-   Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
-   may only appear in the DN string if escaped.  These characters are
-   intended to be used in free-form text to distinguish a DN string from
-   surrounding text.  For example, <CN=Sam\ > distinguishes the string
-   representation of the DN composed of one RDN consisting of the AVA
-   (the commonName (CN) value 'Sam ') from the surrounding text.  It
-   should be noted to the user that the wrapping '<' and '>' characters
-   are not part of the DN string.
-
-   DN strings can be quite long.  It is often desirable to line-wrap
-   overly long DN strings in presentations.  Line wrapping should be
-   done by inserting whitespace after the RDN separator character or, if
-   necessary, after the AVA separator character.  It should be noted to
-   the user that the inserted whitespace is not part of the DN string
-   and is to be removed before use in LDAP.  For example, the following
-   DN string is long:
-
-
-
-
-Zeilenga                    Standards Track                    [Page 12]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-         CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
-         O=OpenLDAP Foundation,ST=California,C=US
-
-   So it has been line-wrapped for readability.  The extra whitespace is
-   to be removed before the DN string is used in LDAP.
-
-   Inserting whitespace is not advised because it may not be obvious to
-   the user which whitespace is part of the DN string and which
-   whitespace was added for readability.
-
-   Another alternative is to use the LDAP Data Interchange Format (LDIF)
-   [RFC2849].  For example:
-
-         # This entry has a long DN...
-         dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
-          O=OpenLDAP Foundation,ST=California,C=US
-         CN: Kurt D.  Zeilenga
-         SN: Zeilenga
-         objectClass: person
-
-Appendix B.  Changes Made since RFC 2253
-
-   This appendix is provided for informational purposes only, it is not
-   a normative part of this specification.
-
-   The following substantive changes were made to RFC 2253:
-
-      - Removed IESG Note.  The IESG Note has been addressed.
-      - Replaced all references to ISO 10646-1 with [Unicode].
-      - Clarified (in Section 1) that this document does not define a
-        canonical string representation.
-      - Clarified that Section 2 describes the RECOMMENDED encoding
-        algorithm and that alternative algorithms are allowed.  Some
-        encoding options described in RFC 2253 are now treated as
-        alternative algorithms in this specification.
-      - Revised specification (in Section 2) to allow short names of any
-        registered attribute type to appear in string representations of
-        DNs instead of being restricted to a "published table".  Removed
-        "as an example" language.  Added statement (in Section 3)
-        allowing recognition of additional names but require recognition
-        of those names in the published table.  The table now appears in
-        Section 3.
-      - Removed specification of additional requirements for LDAPv2
-        implementations which also support LDAPv3 (RFC 2253, Section 4)
-        as LDAPv2 is now Historic.
-      - Allowed recognition of alternative string representations.
-      - Updated Section 2.4 to allow hex pair escaping of all characters
-        and clarified escaping for when multiple octet UTF-8 encodings
-
-
-
-Zeilenga                    Standards Track                    [Page 13]
-
-RFC 4514               LDAP: Distinguished Names               June 2006
-
-
-        are present.  Indicated that null (U+0000) character is to be
-        escaped.  Indicated that equals sign ('=' U+003D) character may
-        be escaped as '\='.
-      - Rewrote Section 3 to use ABNF as defined in RFC 4234.
-      - Updated the Section 3 ABNF.  Changes include:
-        + allowed AttributeType short names of length 1 (e.g., 'L'),
-        + used more restrictive <oid> production in AttributeTypes,
-        + did not require escaping of equals sign ('=' U+003D)
-          characters,
-        + did not require escaping of non-leading number sign ('#'
-          U+0023) characters,
-        + allowed space (' ' U+0020) to be escaped as '\ ',
-        + required hex escaping of null (U+0000) characters, and
-        + removed LDAPv2-only constructs.
-      - Updated Section 3 to describe how to parse elements of the
-        grammar.
-      - Rewrote examples.
-      - Added reference to documentations containing general LDAP
-        security considerations.
-      - Added discussion of presentation issues (Appendix A).
-      - Added this appendix.
-
-   In addition, numerous editorial changes were made.
-
-Editor's Address
-
-   Kurt D.  Zeilenga
-   OpenLDAP Foundation
-
-   EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 14]
-
-RFC 4514               LDAP: Distinguished Names               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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Zeilenga                    Standards Track                    [Page 15]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4515.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4515.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4515.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      M. Smith, Ed.
-Request for Comments: 4515                           Pearl Crescent, LLC
-Obsoletes: 2254                                                 T. Howes
-Category: Standards Track                                  Opsware, Inc.
-                                                               June 2006
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                String Representation of Search Filters
-
-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
-
-   Lightweight Directory Access Protocol (LDAP) search filters are
-   transmitted in the LDAP protocol using a binary representation that
-   is appropriate for use on the network.  This document defines a
-   human-readable string representation of LDAP search filters that is
-   appropriate for use in LDAP URLs (RFC 4516) and in other
-   applications.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. LDAP Search Filter Definition ...................................2
-   3. String Search Filter Definition .................................3
-   4. Examples ........................................................5
-   5. Security Considerations .........................................7
-   6. Normative References ............................................7
-   7. Informative References ..........................................8
-   8. Acknowledgements ................................................8
-   Appendix A: Changes Since RFC 2254 .................................9
-      A.1. Technical Changes ..........................................9
-      A.2. Editorial Changes ..........................................9
-
-
-
-
-
-
-
-Smith and Howes             Standards Track                     [Page 1]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-1.  Introduction
-
-   The Lightweight Directory Access Protocol (LDAP) [RFC4510] defines a
-   network representation of a search filter transmitted to an LDAP
-   server.  Some applications may find it useful to have a common way of
-   representing these search filters in a human-readable form; LDAP URLs
-   [RFC4516] are an example of one such application.  This document
-   defines a human-readable string format for representing the full
-   range of possible LDAP version 3 search filters, including extended
-   match filters.
-
-   This document is a integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.
-
-   This document replaces RFC 2254.  Changes to RFC 2254 are summarized
-   in Appendix A.
-
-   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].
-
-2.  LDAP Search Filter Definition
-
-   An LDAP search filter is defined in Section 4.5.1 of [RFC4511] as
-   follows:
-
-        Filter ::= CHOICE {
-            and                [0] SET SIZE (1..MAX) OF filter Filter,
-            or                 [1] SET SIZE (1..MAX) OF filter Filter,
-            not                [2] Filter,
-            equalityMatch      [3] AttributeValueAssertion,
-            substrings         [4] SubstringFilter,
-            greaterOrEqual     [5] AttributeValueAssertion,
-            lessOrEqual        [6] AttributeValueAssertion,
-            present            [7] AttributeDescription,
-            approxMatch        [8] AttributeValueAssertion,
-            extensibleMatch    [9] MatchingRuleAssertion }
-
-        SubstringFilter ::= SEQUENCE {
-            type    AttributeDescription,
-            -- initial and final can occur at most once
-            substrings    SEQUENCE SIZE (1..MAX) OF substring CHOICE {
-             initial        [0] AssertionValue,
-             any            [1] AssertionValue,
-             final          [2] AssertionValue } }
-
-
-
-
-
-Smith and Howes             Standards Track                     [Page 2]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-        AttributeValueAssertion ::= SEQUENCE {
-            attributeDesc   AttributeDescription,
-            assertionValue  AssertionValue }
-
-        MatchingRuleAssertion ::= SEQUENCE {
-            matchingRule    [1] MatchingRuleId OPTIONAL,
-            type            [2] AttributeDescription OPTIONAL,
-            matchValue      [3] AssertionValue,
-            dnAttributes    [4] BOOLEAN DEFAULT FALSE }
-
-        AttributeDescription ::= LDAPString
-                        -- Constrained to <attributedescription>
-                        -- [RFC4512]
-
-        AttributeValue ::= OCTET STRING
-
-        MatchingRuleId ::= LDAPString
-
-        AssertionValue ::= OCTET STRING
-
-        LDAPString ::= OCTET STRING -- UTF-8 encoded,
-                                    -- [Unicode] characters
-
-   The AttributeDescription, as defined in [RFC4511], is a string
-   representation of the attribute description that is discussed in
-   [RFC4512].  The AttributeValue and AssertionValue OCTET STRING have
-   the form defined in [RFC4517].  The Filter is encoded for
-   transmission over a network using the Basic Encoding Rules (BER)
-   defined in [X.690], with simplifications described in [RFC4511].
-
-3.  String Search Filter Definition
-
-   The string representation of an LDAP search filter is a string of
-   UTF-8 [RFC3629] encoded Unicode characters [Unicode] that is defined
-   by the following grammar, following the ABNF notation defined in
-   [RFC4234].  The productions used that are not defined here are
-   defined in Section 1.4 (Common ABNF Productions) of [RFC4512] unless
-   otherwise noted.  The filter format uses a prefix notation.
-
-      filter         = LPAREN filtercomp RPAREN
-      filtercomp     = and / or / not / item
-      and            = AMPERSAND filterlist
-      or             = VERTBAR filterlist
-      not            = EXCLAMATION filter
-      filterlist     = 1*filter
-      item           = simple / present / substring / extensible
-      simple         = attr filtertype assertionvalue
-      filtertype     = equal / approx / greaterorequal / lessorequal
-
-
-
-Smith and Howes             Standards Track                     [Page 3]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-      equal          = EQUALS
-      approx         = TILDE EQUALS
-      greaterorequal = RANGLE EQUALS
-      lessorequal    = LANGLE EQUALS
-      extensible     = ( attr [dnattrs]
-                           [matchingrule] COLON EQUALS assertionvalue )
-                       / ( [dnattrs]
-                            matchingrule COLON EQUALS assertionvalue )
-      present        = attr EQUALS ASTERISK
-      substring      = attr EQUALS [initial] any [final]
-      initial        = assertionvalue
-      any            = ASTERISK *(assertionvalue ASTERISK)
-      final          = assertionvalue
-      attr           = attributedescription
-                         ; The attributedescription rule is defined in
-                         ; Section 2.5 of [RFC4512].
-      dnattrs        = COLON "dn"
-      matchingrule   = COLON oid
-      assertionvalue = valueencoding
-      ; The <valueencoding> rule is used to encode an <AssertionValue>
-      ; from Section 4.1.6 of [RFC4511].
-      valueencoding  = 0*(normal / escaped)
-      normal         = UTF1SUBSET / UTFMB
-      escaped        = ESC HEX HEX
-      UTF1SUBSET     = %x01-27 / %x2B-5B / %x5D-7F
-                          ; UTF1SUBSET excludes 0x00 (NUL), LPAREN,
-                          ; RPAREN, ASTERISK, and ESC.
-      EXCLAMATION    = %x21 ; exclamation mark ("!")
-      AMPERSAND      = %x26 ; ampersand (or AND symbol) ("&")
-      ASTERISK       = %x2A ; asterisk ("*")
-      COLON          = %x3A ; colon (":")
-      VERTBAR        = %x7C ; vertical bar (or pipe) ("|")
-      TILDE          = %x7E ; tilde ("~")
-
-   Note that although both the <substring> and <present> productions in
-   the grammar above can produce the "attr=*" construct, this construct
-   is used only to denote a presence filter.
-
-   The <valueencoding> rule ensures that the entire filter string is a
-   valid UTF-8 string and provides that the octets that represent the
-   ASCII characters "*" (ASCII 0x2a), "(" (ASCII 0x28), ")" (ASCII
-   0x29), "\" (ASCII 0x5c), and NUL (ASCII 0x00) are represented as a
-   backslash "\" (ASCII 0x5c) followed by the two hexadecimal digits
-   representing the value of the encoded octet.
-
-
-
-
-
-
-
-Smith and Howes             Standards Track                     [Page 4]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-   This simple escaping mechanism eliminates filter-parsing ambiguities
-   and allows any filter that can be represented in LDAP to be
-   represented as a NUL-terminated string.  Other octets that are part
-   of the <normal> set may be escaped using this mechanism, for example,
-   non-printing ASCII characters.
-
-   For AssertionValues that contain UTF-8 character data, each octet of
-   the character to be escaped is replaced by a backslash and two hex
-   digits, which form a single octet in the code of the character.  For
-   example, the filter checking whether the "cn" attribute contained a
-   value with the character "*" anywhere in it would be represented as
-   "(cn=*\2a*)".
-
-   As indicated by the <valueencoding> rule, implementations MUST escape
-   all octets greater than 0x7F that are not part of a valid UTF-8
-   encoding sequence when they generate a string representation of a
-   search filter.  Implementations SHOULD accept as input strings that
-   are not valid UTF-8 strings.  This is necessary because RFC 2254 did
-   not clearly define the term "string representation" (and in
-   particular did not mention that the string representation of an LDAP
-   search filter is a string of UTF-8-encoded Unicode characters).
-
-4.  Examples
-
-   This section gives a few examples of search filters written using
-   this notation.
-
-        (cn=Babs Jensen)
-        (!(cn=Tim Howes))
-        (&(objectClass=Person)(|(sn=Jensen)(cn=Babs J*)))
-        (o=univ*of*mich*)
-        (seeAlso=)
-
-   The following examples illustrate the use of extensible matching.
-
-        (cn:caseExactMatch:=Fred Flintstone)
-        (cn:=Betty Rubble)
-        (sn:dn:2.4.6.8.10:=Barney Rubble)
-        (o:dn:=Ace Industry)
-        (:1.2.3:=Wilma Flintstone)
-        (:DN:2.4.6.8.10:=Dino)
-
-   The first example shows use of the matching rule "caseExactMatch."
-
-   The second example demonstrates use of a MatchingRuleAssertion form
-   without a matchingRule.
-
-
-
-
-
-Smith and Howes             Standards Track                     [Page 5]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-   The third example illustrates the use of the ":oid" notation to
-   indicate that the matching rule identified by the OID "2.4.6.8.10"
-   should be used when making comparisons, and that the attributes of an
-   entry's distinguished name should be considered part of the entry
-   when evaluating the match (indicated by the use of ":dn").
-
-   The fourth example denotes an equality match, except that DN
-   components should be considered part of the entry when doing the
-   match.
-
-   The fifth example is a filter that should be applied to any attribute
-   supporting the matching rule given (since the <attr> has been
-   omitted).
-
-   The sixth and final example is also a filter that should be applied
-   to any attribute supporting the matching rule given.  Attributes
-   supporting the matching rule contained in the DN should also be
-   considered.
-
-   The following examples illustrate the use of the escaping mechanism.
-
-        (o=Parens R Us \28for all your parenthetical needs\29)
-        (cn=*\2A*)
-        (filename=C:\5cMyFile)
-        (bin=\00\00\00\04)
-        (sn=Lu\c4\8di\c4\87)
-        (1.3.6.1.4.1.1466.0=\04\02\48\69)
-
-   The first example shows the use of the escaping mechanism to
-   represent parenthesis characters.  The second shows how to represent
-   a "*" in an assertion value, preventing it from being interpreted as
-   a substring indicator.  The third illustrates the escaping of the
-   backslash character.
-
-   The fourth example shows a filter searching for the four-octet value
-   00 00 00 04 (hex), illustrating the use of the escaping mechanism to
-   represent arbitrary data, including NUL characters.
-
-   The fifth example illustrates the use of the escaping mechanism to
-   represent various non-ASCII UTF-8 characters.  Specifically, there
-   are 5 characters in the <assertionvalue> portion of this example:
-   LATIN CAPITAL LETTER L (U+004C), LATIN SMALL LETTER U (U+0075), LATIN
-   SMALL LETTER C WITH CARON (U+010D), LATIN SMALL LETTER I (U+0069),
-   and LATIN SMALL LETTER C WITH ACUTE (U+0107).
-
-   The sixth and final example demonstrates assertion of a BER-encoded
-   value.
-
-
-
-
-Smith and Howes             Standards Track                     [Page 6]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-5.  Security Considerations
-
-   This memo describes a string representation of LDAP search filters.
-   While the representation itself has no known security implications,
-   LDAP search filters do.  They are interpreted by LDAP servers to
-   select entries from which data is retrieved.  LDAP servers should
-   take care to protect the data they maintain from unauthorized access.
-
-   Please refer to the Security Considerations sections of [RFC4511] and
-   [RFC4513] for more information.
-
-6.  Normative References
-
-   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
-               Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
-               10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
-               Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4510]   Zeilenga, K., Ed., "Lightweight Directory Access Protocol
-               (LDAP): Technical Specification Road Map", RFC 4510, June
-               2006.
-
-   [RFC4511]   Sermersheim, J., Ed., "Lightweight Directory Access
-               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]   Zeilenga, K., "Lightweight Directory Access Protocol
-               (LDAP): Directory Information Models", RFC 4512, June
-               2006.
-
-   [RFC4513]   Harrison, R., Ed., "Lightweight Directory Access Protocol
-               (LDAP): Authentication Methods and Security Mechanisms",
-               RFC 4513, 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."
-
-
-
-
-Smith and Howes             Standards Track                     [Page 7]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-7.  Informative References
-
-   [RFC4516]   Smith, M., Ed. and T. Howes, "Lightweight Directory
-               Access Protocol (LDAP): Uniform Resource Locator", RFC
-               4516, June 2006.
-
-   [X.690]     Specification of ASN.1 encoding rules: Basic, Canonical,
-               and Distinguished Encoding Rules, ITU-T Recommendation
-               X.690, 1994.
-
-8.  Acknowledgements
-
-   This document replaces RFC 2254 by Tim Howes.  RFC 2254 was a product
-   of the IETF ASID Working Group.
-
-   Changes included in this revised specification are based upon
-   discussions among the authors, discussions within the LDAP (v3)
-   Revision Working Group (ldapbis), and discussions within other IETF
-   Working Groups.  The contributions of individuals in these working
-   groups is gratefully acknowledged.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith and Howes             Standards Track                     [Page 8]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-Appendix A: Changes Since RFC 2254
-
-A.1.  Technical Changes
-
-   Replaced [ISO 10646] reference with [Unicode].
-
-   The following technical changes were made to the contents of the
-   "String Search Filter Definition" section:
-
-   Added statement that the string representation is a string of UTF-8-
-   encoded Unicode characters.
-
-   Revised all of the ABNF to use common productions from [RFC4512].
-
-   Replaced the "value" rule with a new "assertionvalue" rule within the
-   "simple", "extensible", and "substring" ("initial", "any", and
-   "final") rules.  This matches a change made in [RFC4517].
-
-   Added "(" and ")" around the components of the <extensible>
-   subproductions for clarity.
-
-   Revised the "attr", "matchingrule", and "assertionvalue" ABNF to more
-   precisely reference productions from the [RFC4512] and [RFC4511]
-   documents.
-
-   "String Search Filter Definition" section: replaced "greater" and
-   "less" with "greaterorequal" and "lessorequal" to avoid confusion.
-
-   Introduced the "valueencoding" and associated "normal" and "escaped"
-   rules to reduce the dependence on descriptive text.  The "normal"
-   production restricts filter strings to valid UTF-8 sequences.
-
-   Added a statement about expected behavior in light of RFC 2254's lack
-   of a clear definition of "string representation."
-
-A.2.  Editorial Changes
-
-   Changed document title to include "LDAP:" prefix.
-
-   IESG Note: removed note about lack of satisfactory mandatory
-   authentication mechanisms.
-
-   Header and "Authors' Addresses" sections: added Mark Smith as the
-   document editor and updated affiliation and contact information.
-
-   "Table of Contents" and "Intellectual Property" sections: added.
-
-   Copyright: updated per latest IETF guidelines.
-
-
-
-Smith and Howes             Standards Track                     [Page 9]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-   "Abstract" section: separated from introductory material.
-
-   "Introduction" section: new section; separated from the Abstract.
-   Updated second paragraph to indicate that RFC 2254 is replaced by
-   this document (instead of RFC 1960).  Added reference to the
-   [RFC4510] document.
-
-   "LDAP Search Filter Definition" section: made corrections to the LDAP
-   search filter ABNF so it matches that used in [RFC4511].
-
-   Clarified the definition of 'value' (now 'assertionvalue') to take
-   into account the fact that it is not precisely an AttributeAssertion
-   from [RFC4511] Section 4.1.6 (special handling is required for some
-   characters).  Added a note that each octet of a character to be
-   escaped is replaced by a backslash and two hex digits, which
-   represent a single octet.
-
-   "Examples" section: added four additional examples: (seeAlso=),
-   (cn:=Betty Rubble), (:1.2.3:=Wilma Flintstone), and
-   (1.3.6.1.4.1.1466.0=\04\02\48\69).  Replaced one occurrence of "a
-   value" with "an assertion value".  Corrected the description of this
-   example: (sn:dn:2.4.6.8.10:=Barney Rubble).  Replaced the numeric OID
-   in the first extensible match example with "caseExactMatch" to
-   demonstrate use of the descriptive form.  Used "DN" (uppercase) in
-   the last extensible match example to remind the reader to treat the
-   <dnattrs> production as case insensitive.  Reworded the description
-   of the fourth escaping mechanism example to avoid making assumptions
-   about byte order.  Added text to the fifth escaping mechanism example
-   to spell out what the non-ASCII characters are in Unicode terms.
-
-   "Security Considerations" section: added references to [RFC4511] and
-   [RFC4513].
-
-   "Normative References" section: renamed from "References" per new RFC
-   guidelines.  Changed from [1] style to [RFC4511] style throughout the
-   document.  Added entries for [Unicode], [RFC2119], [RFC4513],
-   [RFC4512], and [RFC4510] and updated the UTF-8 reference.  Replaced
-   RFC 822 reference with a reference to RFC 4234.
-
-   "Informative References" section: (new section) moved [X.690] to this
-   section.  Added a reference to [RFC4516].
-
-   "Acknowledgements" section: added.
-
-   "Appendix A: Changes Since RFC 2254" section: added.
-
-   Surrounded the names of all ABNF productions with "<" and ">" where
-   they are used in descriptive text.
-
-
-
-Smith and Howes             Standards Track                    [Page 10]
-
-RFC 4515     LDAP: String Representation of Search Filters     June 2006
-
-
-   Replaced all occurrences of "LDAPv3" with "LDAP."
-
-Authors' Addresses
-
-   Mark Smith, Editor
-   Pearl Crescent, LLC
-   447 Marlpool Dr.
-   Saline, MI 48176
-   USA
-
-   Phone: +1 734 944-2856
-   EMail: mcs at pearlcrescent.com
-
-
-   Tim Howes
-   Opsware, Inc.
-   599 N. Mathilda Ave.
-   Sunnyvale, CA 94085
-   USA
-
-   Phone: +1 408 744-7509
-   EMail: howes at opsware.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith and Howes             Standards Track                    [Page 11]
-
-RFC 4515     LDAP: String Representation of Search Filters     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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Smith and Howes             Standards Track                    [Page 12]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4516.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4516.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4516.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                      M. Smith, Ed.
-Request for Comments: 4516                           Pearl Crescent, LLC
-Obsoletes: 2255                                                 T. Howes
-Category: Standards Track                                  Opsware, Inc.
-                                                               June 2006
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                        Uniform Resource Locator
-
-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
-
-   This document describes a format for a Lightweight Directory Access
-   Protocol (LDAP) Uniform Resource Locator (URL).  An LDAP URL
-   describes an LDAP search operation that is used to retrieve
-   information from an LDAP directory, or, in the context of an LDAP
-   referral or reference, an LDAP URL describes a service where an LDAP
-   operation may be progressed.
-
-Table of Contents
-
-   1. Introduction ....................................................2
-   2. URL Definition ..................................................2
-      2.1. Percent-Encoding ...........................................4
-   3. Defaults for Fields of the LDAP URL .............................5
-   4. Examples ........................................................6
-   5. Security Considerations .........................................8
-   6. Normative References ............................................9
-   7. Informative References .........................................10
-   8. Acknowledgements ...............................................10
-   Appendix A: Changes Since RFC 2255 ................................11
-      A.1. Technical Changes .........................................11
-      A.2. Editorial Changes .........................................11
-
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 1]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-1.  Introduction
-
-   LDAP is the Lightweight Directory Access Protocol [RFC4510].  This
-   document specifies the LDAP URL format for version 3 of LDAP and
-   clarifies how LDAP URLs are resolved.  This document also defines an
-   extension mechanism for LDAP URLs.  This mechanism may be used to
-   provide access to new LDAP extensions.
-
-   Note that not all the parameters of the LDAP search operation
-   described in [RFC4511] can be expressed using the format defined in
-   this document.  Note also that URLs may be used to represent
-   reference knowledge, including that for non-search operations.
-
-   This document is an integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.
-
-   This document replaces RFC 2255.  See Appendix A for a list of
-   changes relative to RFC 2255.
-
-   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].
-
-2.  URL Definition
-
-   An LDAP URL begins with the protocol prefix "ldap" and is defined by
-   the following grammar, following the ABNF notation defined in
-   [RFC4234].
-
-      ldapurl     = scheme COLON SLASH SLASH [host [COLON port]]
-                       [SLASH dn [QUESTION [attributes]
-                       [QUESTION [scope] [QUESTION [filter]
-                       [QUESTION extensions]]]]]
-                                      ; <host> and <port> are defined
-                                      ;   in Sections 3.2.2 and 3.2.3
-                                      ;   of [RFC3986].
-                                      ; <filter> is from Section 3 of
-                                      ;   [RFC4515], subject to the
-                                      ;   provisions of the
-                                      ;   "Percent-Encoding" section
-                                      ;   below.
-
-      scheme      = "ldap"
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 2]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-      dn          = distinguishedName ; From Section 3 of [RFC4514],
-                                      ; subject to the provisions of
-                                      ; the "Percent-Encoding"
-                                      ; section below.
-
-      attributes  = attrdesc *(COMMA attrdesc)
-      attrdesc    = selector *(COMMA selector)
-      selector    = attributeSelector ; From Section 4.5.1 of
-                                      ; [RFC4511], subject to the
-                                      ; provisions of the
-                                      ; "Percent-Encoding" section
-                                      ; below.
-
-      scope       = "base" / "one" / "sub"
-      extensions  = extension *(COMMA extension)
-      extension   = [EXCLAMATION] extype [EQUALS exvalue]
-      extype      = oid               ; From section 1.4 of [RFC4512].
-
-      exvalue     = LDAPString        ; From section 4.1.2 of
-                                      ; [RFC4511], subject to the
-                                      ; provisions of the
-                                      ; "Percent-Encoding" section
-                                      ; below.
-
-      EXCLAMATION = %x21              ; exclamation mark ("!")
-      SLASH       = %x2F              ; forward slash ("/")
-      COLON       = %x3A              ; colon (":")
-      QUESTION    = %x3F              ; question mark ("?")
-
-   The "ldap" prefix indicates an entry or entries accessible from the
-   LDAP server running on the given hostname at the given portnumber.
-   Note that the <host> may contain literal IPv6 addresses as specified
-   in Section 3.2.2 of [RFC3986].
-
-   The <dn> is an LDAP Distinguished Name using the string format
-   described in [RFC4514].  It identifies the base object of the LDAP
-   search or the target of a non-search operation.
-
-   The <attributes> construct is used to indicate which attributes
-   should be returned from the entry or entries.
-
-   The <scope> construct is used to specify the scope of the search to
-   perform in the given LDAP server.  The allowable scopes are "base"
-   for a base object search, "one" for a one-level search, or "sub" for
-   a subtree search.
-
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 3]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-   The <filter> is used to specify the search filter to apply to entries
-   within the specified scope during the search.  It has the format
-   specified in [RFC4515].
-
-   The <extensions> construct provides the LDAP URL with an
-   extensibility mechanism, allowing the capabilities of the URL to be
-   extended in the future.  Extensions are a simple comma-separated list
-   of type=value pairs, where the =value portion MAY be omitted for
-   options not requiring it.  Each type=value pair is a separate
-   extension.  These LDAP URL extensions are not necessarily related to
-   any of the LDAP extension mechanisms.  Extensions may be supported or
-   unsupported by the client resolving the URL.  An extension prefixed
-   with a '!' character (ASCII 0x21) is critical.  An extension not
-   prefixed with a '!' character is non-critical.
-
-   If an LDAP URL extension is implemented (that is, if the
-   implementation understands it and is able to use it), the
-   implementation MUST make use of it.  If an extension is not
-   implemented and is marked critical, the implementation MUST NOT
-   process the URL.  If an extension is not implemented and is not
-   marked critical, the implementation MUST ignore the extension.
-
-   The extension type (<extype>) MAY be specified using the numeric OID
-   <numericoid> form (e.g., 1.2.3.4) or the descriptor <descr> form
-   (e.g., myLDAPURLExtension).  Use of the <descr> form SHOULD be
-   restricted to registered object identifier descriptive names.  See
-   [RFC4520] for registration details and usage guidelines for
-   descriptive names.
-
-   No LDAP URL extensions are defined in this document.  Other documents
-   or a future version of this document MAY define one or more
-   extensions.
-
-2.1.  Percent-Encoding
-
-   A generated LDAP URL MUST consist only of the restricted set of
-   characters included in one of the following three productions defined
-   in [RFC3986]:
-
-         <reserved>
-         <unreserved>
-         <pct-encoded>
-
-   Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as
-   input.  An octet MUST be encoded using the percent-encoding mechanism
-   described in section 2.1 of [RFC3986] in any of these situations:
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 4]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-      The octet is not in the reserved set defined in section 2.2 of
-      [RFC3986] or in the unreserved set defined in section 2.3 of
-      [RFC3986].
-
-      It is the single Reserved character '?' and occurs inside a <dn>,
-      <filter>, or other element of an LDAP URL.
-
-      It is a comma character ',' that occurs inside an <exvalue>.
-
-   Note that before the percent-encoding mechanism is applied, the
-   extensions component of the LDAP URL may contain one or more null
-   (zero) bytes.  No other component may.
-
-3.  Defaults for Fields of the LDAP URL
-
-   Some fields of the LDAP URL are optional, as described above.  In the
-   absence of any other specification, the following general defaults
-   SHOULD be used when a field is absent.  Note that other documents MAY
-   specify different defaulting rules; for example, section 4.1.10 of
-   [RFC4511] specifies a different rule for determining the correct DN
-   to use when it is absent in an LDAP URL that is returned as a
-   referral.
-
-   <host>
-      If no <host> is given, the client must have some a priori
-      knowledge of an appropriate LDAP server to contact.
-
-   <port>
-      The default LDAP port is TCP port 389.
-
-   <dn>
-      If no <dn> is given, the default is the zero-length DN, "".
-
-   <attributes>
-      If the <attributes> part is omitted, all user attributes of the
-      entry or entries should be requested (e.g., by setting the
-      attributes field AttributeDescriptionList in the LDAP search
-      request to a NULL list, or by using the special <alluserattrs>
-      selector "*").
-
-   <scope>
-      If <scope> is omitted, a <scope> of "base" is assumed.
-
-   <filter>
-      If <filter> is omitted, a filter of "(objectClass=*)" is assumed.
-
-   <extensions>
-      If <extensions> is omitted, no extensions are assumed.
-
-
-
-Smith & Howes               Standards Track                     [Page 5]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-4.  Examples
-
-   The following are some example LDAP URLs that use the format defined
-   above.  The first example is an LDAP URL referring to the University
-   of Michigan entry, available from an LDAP server of the client's
-   choosing:
-
-      ldap:///o=University%20of%20Michigan,c=US
-
-   The next example is an LDAP URL referring to the University of
-   Michigan entry in a particular ldap server:
-
-      ldap://ldap1.example.net/o=University%20of%20Michigan,c=US
-
-   Both of these URLs correspond to a base object search of the
-   "o=University of Michigan,c=US" entry using a filter of
-   "(objectclass=*)", requesting all attributes.
-
-   The next example is an LDAP URL referring to only the postalAddress
-   attribute of the University of Michigan entry:
-
-      ldap://ldap1.example.net/o=University%20of%20Michigan,
-             c=US?postalAddress
-
-   The corresponding LDAP search operation is the same as in the
-   previous example, except that only the postalAddress attribute is
-   requested.
-
-   The next example is an LDAP URL referring to the set of entries found
-   by querying the given LDAP server on port 6666 and doing a subtree
-   search of the University of Michigan for any entry with a common name
-   of "Babs Jensen", retrieving all attributes:
-
-      ldap://ldap1.example.net:6666/o=University%20of%20Michigan,
-             c=US??sub?(cn=Babs%20Jensen)
-
-   The next example is an LDAP URL referring to all children of the c=GB
-   entry:
-
-      LDAP://ldap1.example.com/c=GB?objectClass?ONE
-
-   The objectClass attribute is requested to be returned along with the
-   entries, and the default filter of "(objectclass=*)" is used.
-
-   The next example is an LDAP URL to retrieve the mail attribute for
-   the LDAP entry named "o=Question?,c=US", illustrating the use of the
-   percent-encoding mechanism on the reserved character '?'.
-
-
-
-
-Smith & Howes               Standards Track                     [Page 6]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-      ldap://ldap2.example.com/o=Question%3f,c=US?mail
-
-   The next example (which is broken into two lines for readability)
-   illustrates the interaction between the LDAP string representation of
-   the filters-quoting mechanism and the URL-quoting mechanisms.
-
-      ldap://ldap3.example.com/o=Babsco,c=US
-              ???(four-octet=%5c00%5c00%5c00%5c04)
-
-   The filter in this example uses the LDAP escaping mechanism of \ to
-   encode three zero or null bytes in the value.  In LDAP, the filter
-   would be written as (four-octet=\00\00\00\04).  Because the \
-   character must be escaped in a URL, the \s are percent-encoded as %5c
-   (or %5C) in the URL encoding.
-
-   The next example illustrates the interaction between the LDAP string
-   representation of the DNs-quoting mechanism and URL-quoting
-   mechanisms.
-
-      ldap://ldap.example.com/o=An%20Example%5C2C%20Inc.,c=US
-
-   The DN encoded in the above URL is:
-
-      o=An Example\2C Inc.,c=US
-
-   That is, the left-most RDN value is:
-
-      An Example, Inc.
-
-   The following three URLs are equivalent, assuming that the defaulting
-   rules specified in Section 3 of this document are used:
-
-      ldap://ldap.example.net
-      ldap://ldap.example.net/
-      ldap://ldap.example.net/?
-
-   These three URLs point to the root DSE on the ldap.example.net
-   server.
-
-   The final two examples show use of a hypothetical, experimental bind
-   name extension (the value associated with the extension is an LDAP
-   DN).
-
-      ldap:///??sub??e-bindname=cn=Manager%2cdc=example%2cdc=com
-      ldap:///??sub??!e-bindname=cn=Manager%2cdc=example%2cdc=com
-
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 7]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-   The two URLs are the same, except that the second one marks the
-   e-bindname extension as critical.  Notice the use of the percent-
-   encoding mechanism to encode the commas within the distinguished name
-   value in the e-bindname extension.
-
-5.  Security Considerations
-
-   The general URL security considerations discussed in [RFC3986] are
-   relevant for LDAP URLs.
-
-   The use of security mechanisms when processing LDAP URLs requires
-   particular care, since clients may encounter many different servers
-   via URLs, and since URLs are likely to be processed automatically,
-   without user intervention.  A client SHOULD have a user-configurable
-   policy that controls which servers the client will establish LDAP
-   sessions with and with which security mechanisms, and SHOULD NOT
-   establish LDAP sessions that are inconsistent with this policy.  If a
-   client chooses to reuse an existing LDAP session when resolving one
-   or more LDAP URLs, it MUST ensure that the session is compatible with
-   the URL and that no security policies are violated.
-
-   Sending authentication information, no matter the mechanism, may
-   violate a user's privacy requirements.  In the absence of specific
-   policy permitting authentication information to be sent to a server,
-   a client should use an anonymous LDAP session.  (Note that clients
-   conforming to previous LDAP URL specifications, where all LDAP
-   sessions are anonymous and unprotected, are consistent with this
-   specification; they simply have the default security policy.)  Simply
-   opening a transport connection to another server may violate some
-   users' privacy requirements, so clients should provide the user with
-   a way to control URL processing.
-
-   Some authentication methods, in particular, reusable passwords sent
-   to the server, may reveal easily-abused information to the remote
-   server or to eavesdroppers in transit and should not be used in URL
-   processing unless they are explicitly permitted by policy.
-   Confirmation by the human user of the use of authentication
-   information is appropriate in many circumstances.  Use of strong
-   authentication methods that do not reveal sensitive information is
-   much preferred.  If the URL represents a referral for an update
-   operation, strong authentication methods SHOULD be used.  Please
-   refer to the Security Considerations section of [RFC4513] for more
-   information.
-
-   The LDAP URL format allows the specification of an arbitrary LDAP
-   search operation to be performed when evaluating the LDAP URL.
-   Following an LDAP URL may cause unexpected results, for example, the
-   retrieval of large amounts of data or the initiation of a long-lived
-
-
-
-Smith & Howes               Standards Track                     [Page 8]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-   search.  The security implications of resolving an LDAP URL are the
-   same as those of resolving an LDAP search query.
-
-6.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifier (URI): Generic Syntax", STD 66, RFC
-              3986, January 2005.
-
-   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510, June
-              2006.
-
-   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
-              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Directory Information Models", RFC 4512, June
-              2006.
-
-   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
-              (LDAP): Authentication Methods and Security Mechanisms",
-              RFC 4513, June 2006.
-
-   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
-              (LDAP): String Representation of Distinguished Names", RFC
-              4514, June 2006.
-
-   [RFC4515]  Smith, M. Ed. and T. Howes, "Lightweight Directory Access
-              Protocol (LDAP): String Representation of Search Filters",
-              RFC 4515, June 2006.
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                     [Page 9]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-7.  Informative References
-
-   [RFC2396]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-              Resource Identifiers (URI): Generic Syntax", RFC 2396,
-              August 1998.
-
-   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
-              Considerations for the Lightweight Directory Access
-              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-8.  Acknowledgements
-
-   The LDAP URL format was originally defined at the University of
-   Michigan.  This material is based upon work supported by the National
-   Science Foundation under Grant No. NCR-9416667.  The support of both
-   the University of Michigan and the National Science Foundation is
-   gratefully acknowledged.
-
-   This document obsoletes RFC 2255 by Tim Howes and Mark Smith.
-   Changes included in this revised specification are based upon
-   discussions among the authors, discussions within the LDAP (v3)
-   Revision Working Group (ldapbis), and discussions within other IETF
-   Working Groups.  The contributions of individuals in these working
-   groups is gratefully acknowledged.  Several people in particular have
-   made valuable comments on this document: RL "Bob" Morgan, Mark Wahl,
-   Kurt Zeilenga, Jim Sermersheim, and Hallvard Furuseth deserve special
-   thanks for their contributions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                    [Page 10]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-Appendix A: Changes Since RFC 2255
-
-A.1.  Technical Changes
-
-   The following technical changes were made to the contents of the "URL
-   Definition" section:
-
-   Revised all of the ABNF to use common productions from [RFC4512].
-
-   Replaced references to [RFC2396] with a reference to [RFC3986] (this
-   allows literal IPv6 addresses to be used inside the <host> portion of
-   the URL, and a note was added to remind the reader of this
-   enhancement).  Referencing [RFC3986] required changes to the ABNF and
-   text so that productions that are no longer defined by [RFC3986] are
-   not used.  For example, <hostport> is not defined by [RFC3986] so it
-   has been replaced with host [COLON port].  Note that [RFC3986]
-   includes new definitions for the "Reserved" and "Unreserved" sets of
-   characters, and the net result is that the following two additional
-   characters should be percent-encoded when they appear anywhere in the
-   data used to construct an LDAP URL: "[" and "]" (these two characters
-   were first added to the Reserved set by RFC 2732).
-
-   Changed the definition of <attrdesc> to refer to <attributeSelector>
-   from [RFC4511].  This allows the use of "*" in the <attrdesc> part of
-   the URL.  It is believed that existing implementations of RFC 2255
-   already support this.
-
-   Avoided use of <prose-val> (bracketed-string) productions in the
-   <dn>, <host>, <attrdesc>, and <exvalue> rules.
-
-   Changed the ABNF for <ldapurl> to group the <dn> component with the
-   preceding <SLASH>.
-
-   Changed the <extype> rule to be an <oid> from [RFC4512].
-
-   Changed the text about extension types so it references [RFC4520].
-   Reordered rules to more closely follow the order in which the
-   elements appear in the URL.
-
-   "Bindname Extension": removed due to lack of known implementations.
-
-A.2.  Editorial Changes
-
-   Changed document title to include "LDAP:" prefix.
-
-   IESG Note: removed note about lack of satisfactory mandatory
-   authentication mechanisms.
-
-
-
-
-Smith & Howes               Standards Track                    [Page 11]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-   "Status of this Memo" section: updated boilerplate to match current
-   I-D guidelines.
-
-   "Abstract" section: separated from introductory material.
-
-   "Table of Contents" and "Intellectual Property" sections: added.
-
-   "Introduction" section: new section; separated from the Abstract.
-   Changed the text indicate that RFC 2255 is replaced by this document
-   (instead of RFC 1959).  Added text to indicate that LDAP URLs are
-   used for references and referrals.  Fixed typo (replaced the nonsense
-   phrase "to perform to retrieve" with "used to retrieve").  Added a
-   note to let the reader know that not all of the parameters of the
-   LDAP search operation described in [RFC4511] can be expressed using
-   this format.
-
-   "URL Definition" section: removed second copy of <ldapurl> grammar
-   and following two paragraphs (editorial error in RFC 2255).  Fixed
-   line break within '!' sequence.  Reformatted the ABNF to improve
-   readability by aligning comments and adding some blank lines.
-   Replaced "residing in the LDAP server" with "accessible from the LDAP
-   server" in the sentence immediately following the ABNF.  Removed the
-   sentence "Individual attrdesc names are as defined for
-   AttributeDescription in [RFC4511]."  because [RFC4511]'s
-   <attributeSelector> is now used directly in the ABNF.  Reworded last
-   paragraph to clarify which characters must be percent-encoded.  Added
-   text to indicate that LDAP URLs are used for references and
-   referrals.  Added text that refers to the ABNF from RFC 4234.
-   Clarified and strengthened the requirements with respect to
-   processing of URLs that contain implemented and not implemented
-   extensions (the approach now closely matches that specified in
-   [RFC4511] for LDAP controls).
-
-   "Defaults for Fields of the LDAP URL" section: added; formed by
-   moving text about defaults out of the "URL Definition" section.
-   Replaced direct reference to the attribute name "*" with a reference
-   to the special <alluserattrs> selector "*" defined in [RFC4511].
-
-   "URL Processing" section: removed.
-
-   "Examples" section: Modified examples to use example.com and
-   example.net hostnames.  Added missing '?' to the LDAP URL example
-   whose filter contains three null bytes.  Removed space after one
-   comma within a DN.  Revised the bindname example to use e-bindname.
-   Changed the name of an attribute used in one example from "int" to
-   "four-octet" to avoid potential confusion.  Added an example that
-   demonstrates the interaction between DN escaping and URL percent-
-   encoding.  Added some examples to show URL equivalence with respect
-
-
-
-Smith & Howes               Standards Track                    [Page 12]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-   to the <dn> portion of the URL.  Used uppercase in some examples to
-   remind the reader that some tokens are case-insensitive.
-
-   "Security Considerations" section: Added a note about connection
-   reuse.  Added a note about using strong authentication methods for
-   updates.  Added a reference to [RFC4513].  Added note that simply
-   opening a connection may violate some users' privacy requirements.
-   Adopted the working group's revised LDAP terminology specification by
-   replacing the word "connection" with "LDAP session" or "LDAP
-   connection" as appropriate.
-
-   "Acknowledgements" section: added statement that this document
-   obsoletes RFC 2255.  Added Kurt Zeilenga, Jim Sermersheim, and
-   Hallvard Furuseth.
-
-   "Normative References" section: renamed from "References" per new RFC
-   guidelines.  Changed from [1] style to [RFC4511] style throughout the
-   document.  Added references to RFC 4234 and RFC 3629.  Updated all
-   RFC 1738 references to point to the appropriate sections within
-   [RFC3986].  Updated the LDAP references to refer to LDAPBis WG
-   documents.  Removed the reference to the LDAP Attribute Syntaxes
-   document and added references to the [RFC4513], [RFC4520], and
-   [RFC4510] documents.
-
-   "Informative References" section: added.
-
-   Header and "Authors' Addresses" sections: added "editor" next to Mark
-   Smith's name.  Updated affiliation and contact information.
-
-   Copyright: updated the year.
-
-   Throughout the document: surrounded the names of all ABNF productions
-   with "<" and ">" where they are used in descriptive text.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                    [Page 13]
-
-RFC 4516             LDAP: Uniform Resource Locator            June 2006
-
-
-Authors' Addresses
-
-   Mark Smith, Editor
-   Pearl Crescent, LLC
-   447 Marlpool Dr.
-   Saline, MI 48176
-   USA
-
-   Phone: +1 734 944-2856
-   EMail: mcs at pearlcrescent.com
-
-
-   Tim Howes
-   Opsware, Inc.
-   599 N. Mathilda Ave.
-   Sunnyvale, CA 94085
-   USA
-
-   Phone: +1 408 744-7509
-   EMail: howes at opsware.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                    [Page 14]
-
-RFC 4516             LDAP: Uniform Resource Locator            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 at ietf.org.
-
-Acknowledgement
-
-   Funding for the RFC Editor function is provided by the IETF
-   Administrative Support Activity (IASA).
-
-
-
-
-
-
-
-Smith & Howes               Standards Track                    [Page 15]
-

Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4517.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4517.txt	2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4517.txt	2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Legg, Ed.
-Request for Comments: 4517                                       eB2Bcom
-Obsoletes: 2252, 2256                                          June 2006
-Updates: 3698
-Category: Standards Track
-
-
-             Lightweight Directory Access Protocol (LDAP):
-                      Syntaxes and Matching Rules
-
-
-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
-
-   Each attribute stored in a Lightweight Directory Access Protocol
-   (LDAP) directory, whose values may be transferred in the LDAP
-   protocol, has a defined syntax that constrains the structure and
-   format of its values.  The comparison semantics for values of a
-   syntax are not part of the syntax definition but are instead provided
-   through separately defined matching rules.  Matching rules specify an
-   argument, an assertion value, which also has a defined syntax.  This
-   document defines a base set of syntaxes and matching rules for use in
-   defining attributes for LDAP directories.
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Conventions .....................................................4
-   3. Syntaxes ........................................................4
-      3.1. General Considerations .....................................5
-      3.2. Common Definitions .........................................5
-      3.3. Syntax Definitions .........................................6
-           3.3.1. Attribute Type Description ..........................6
-           3.3.2. Bit String ..........................................6
-           3.3.3. Boolean .............................................7
-           3.3.4. Country String ......................................7
-           3.3.5. Delivery Method .....................................8
-
-
-
-Legg                        Standards Track                     [Page 1]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-           3.3.6. Directory String ....................................8
-           3.3.7. DIT Content Rule Description ........................9
-           3.3.8. DIT Structure Rule Description .....................10
-           3.3.9. DN .................................................10
-           3.3.10. Enhanced Guide ....................................11
-           3.3.11. Facsimile Telephone Number ........................12
-           3.3.12. Fax ...............................................12
-           3.3.13. Generalized Time ..................................13
-           3.3.14. Guide .............................................14
-           3.3.15. IA5 String ........................................15
-           3.3.16. Integer ...........................................15
-           3.3.17. JPEG ..............................................15
-           3.3.18. LDAP Syntax Description ...........................16
-           3.3.19. Matching Rule Description .........................16
-           3.3.20. Matching Rule Use Description .....................17
-           3.3.21. Name and Optional UID .............................17
-           3.3.22. Name Form Description .............................18
-           3.3.23. Numeric String ....................................18
-           3.3.24. Object Class Description ..........................18
-           3.3.25. Octet String ......................................19
-           3.3.26. OID ...............................................19
-           3.3.27. Other Mailbox .....................................20
-           3.3.28. Postal Address ....................................20
-           3.3.29. Printable String ..................................21
-           3.3.30. Substring Assertion ...............................22
-           3.3.31. Telephone Number ..................................23
-           3.3.32. Teletex Terminal Identifier .......................23
-           3.3.33. Telex Number ......................................24
-           3.3.34. UTC Time ..........................................24
-   4. Matching Rules .................................................25
-      4.1. General Considerations ....................................25
-      4.2. Matching Rule Definitions .................................27
-           4.2.1. bitStringMatch .....................................27
-           4.2.2. booleanMatch .......................................28
-           4.2.3. caseExactIA5Match ..................................28
-           4.2.4. caseExactMatch .....................................29
-           4.2.5. caseExactOrderingMatch .............................29
-           4.2.6. caseExactSubstringsMatch ...........................30
-           4.2.7. caseIgnoreIA5Match .................................30
-           4.2.8. caseIgnoreIA5SubstringsMatch .......................31
-           4.2.9. caseIgnoreListMatch ................................31
-           4.2.10. caseIgnoreListSubstringsMatch .....................32
-           4.2.11. caseIgnoreMatch ...................................33
-           4.2.12. caseIgnoreOrderingMatch ...........................33
-           4.2.13. caseIgnoreSubstringsMatch .........................34
-           4.2.14. directoryStringFirstComponentMatch ................34
-           4.2.15. distinguishedNameMatch ............................35
-           4.2.16. generalizedTimeMatch ..............................36
-
-
-
-Legg                        Standards Track                     [Page 2]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-           4.2.17. generalizedTimeOrderingMatch ......................36
-           4.2.18. integerFirstComponentMatch ........................36
-           4.2.19. integerMatch ......................................37
-           4.2.20. integerOrderingMatch ..............................37
-           4.2.21. keywordMatch ......................................38
-           4.2.22. numericStringMatch ................................38
-           4.2.23. numericStringOrderingMatch ........................39
-           4.2.24. numericStringSubstringsMatch ......................39
-           4.2.25. objectIdentifierFirstComponentMatch ...............40
-           4.2.26. objectIdentifierMatch .............................40
-           4.2.27. octetStringMatch ..................................41
-           4.2.28. octetStringOrderingMatch ..........................41
-           4.2.29. telephoneNumberMatch ..............................42
-           4.2.30. telephoneNumberSubstringsMatch ....................42
-           4.2.31. uniqueMemberMatch .................................43
-           4.2.32. wordMatch .........................................44
-   5. Security Considerations ........................................44
-   6. Acknowledgements ...............................................44
-   7. IANA Considerations ............................................45
-   8. References .....................................................46
-      8.1. Normative References ......................................46
-      8.2. Informative References ....................................48
-   Appendix A. Summary of Syntax Object Identifiers ..................49
-   Appendix B. Changes from RFC 2252 .................................49
-
-1.  Introduction
-
-   Each attribute stored in a Lightweight Directory Access Protocol
-   (LDAP) directory [RFC4510], whose values may be transferred in the
-   LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
-   constrains the structure and format of its values.  The comparison
-   semantics for values of a syntax are not part of the syntax
-   definition but are instead provided through separately defined
-   matching rules.  Matching rules specify an argument, an assertion
-   value, which also has a defined syntax.  This document defines a base
-   set of syntaxes and matching rules for use in defining attributes for
-   LDAP directories.
-
-   Readers are advised to familiarize themselves with the Directory
-   Information Models [RFC4512] before reading the rest of this
-   document.  Section 3 provides definitions for the base set of LDAP
-   syntaxes.  Section 4 provides definitions for the base set of
-   matching rules for LDAP.
-
-   This document is an integral part of the LDAP technical specification
-   [RFC4510], which obsoletes the previously defined LDAP technical
-   specification, RFC 3377, in its entirety.
-
-
-
-
-Legg                        Standards Track                     [Page 3]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512].  The
-   remainder of RFC 2252 is obsoleted by this document.  Sections 6 and
-   8 of RFC 2256 are obsoleted by this document.  The remainder of RFC
-   2256 is obsoleted by [RFC4519] and [RFC4512].  All but Section 2.11
-   of RFC 3698 is obsoleted by this document.
-
-   A number of schema elements that were included in the previous
-   revision of the LDAP technical specification are not included in this
-   revision of LDAP.  Public Key Infrastructure schema elements are now
-   specified in [RFC4523].  Unless reintroduced in future technical
-   specifications, the remainder are to be considered Historic.
-
-   The changes with respect to RFC 2252 are described in Appendix B of
-   this document.
-
-2.  Conventions
-
-   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
-   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
-   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
-   [RFC2119].
-
-   Syntax definitions are written according to the <SyntaxDescription>
-   ABNF [RFC4234] rule specified in [RFC4512], and matching rule
-   definitions are written according to the <MatchingRuleDescription>
-   ABNF rule specified in [RFC4512], except that the syntax and matching
-   rule definitions provided in this document are line-wrapped for
-   readability.  When such definitions are transferred as attribute
-   values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
-   matchingRules attributes [RFC4512], respectively), then those values
-   would not contain line breaks.
-
-3.  Syntaxes
-
-   Syntax definitions constrain the structure of attribute values stored
-   in an LDAP directory, and determine the representation of attribute
-   and assertion values transferred in the LDAP protocol.
-
-   Syntaxes that are required for directory operation, or that are in
-   common use, are specified in this section.  Servers SHOULD recognize
-   all the syntaxes listed in this document, but are not required to
-   otherwise support them, and MAY recognise or support other syntaxes.
-   However, the definition of additional arbitrary syntaxes is
-   discouraged since it will hinder interoperability.  Client and server
-   implementations typically do not have the ability to dynamically
-   recognize new syntaxes.
-
-
-
-
-
-Legg                        Standards Track                     [Page 4]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-3.1.  General Considerations
-
-   The description of each syntax specifies how attribute or assertion
-   values conforming to the syntax are to be represented when
-   transferred in the LDAP protocol [RFC4511].  This representation is
-   referred to as the LDAP-specific encoding to distinguish it from
-   other methods of encoding attribute values (e.g., the Basic Encoding
-   Rules (BER) encoding [BER] used by X.500 [X.500] directories).
-
-   The LDAP-specific encoding of a given attribute syntax always
-   produces octet-aligned values.  To the greatest extent possible,
-   encoding rules for LDAP syntaxes should produce character strings
-   that can be displayed with little or no translation by clients
-   implementing LDAP.  However, clients MUST NOT assume that the LDAP-
-   specific encoding of a value of an unrecognized syntax is a human-
-   readable character string.  There are a few cases (e.g., the JPEG
-   syntax) when it is not reasonable to produce a human-readable
-   representation.
-
-   Each LDAP syntax is uniquely identified with an object identifier
-   [ASN.1] represented in the dotted-decimal format (short descriptive
-   names are not defined for syntaxes).  These object identifiers are
-   not intended to be displayed to users.  The object identifiers for
-   the syntaxes defined in this document are summarized in Appendix A.
-
-   A suggested minimum upper bound on the number of characters in an
-   attribute value with a string-based syntax, or the number of octets
-   in a value for all other syntaxes, MAY be indicated by appending the
-   bound inside of curly braces following the syntax's OBJECT IDENTIFIER
-   in an attribute type definition (see the <noidlen> rule in
-   [RFC4512]).  Such a bound is not considered part of the syntax
-   identifier.
-
-   For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
-   definition suggests that the directory server will allow a value of
-   the attribute to be up to 64 characters long, although it may allow
-   longer character strings.  Note that a single character of the
-   Directory String syntax can be encoded in more than one octet, since
-   UTF-8 [RFC3629] is a variable-length encoding.  Therefore, a 64-
-   character string may be more than 64 octets in length.
-
-3.2.  Common Definitions
-
-   The following ABNF rules are used in a number of the syntax
-   definitions in Section 3.3.
-
-      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
-                           PLUS / COMMA / HYPHEN / DOT / EQUALS /
-
-
-
-Legg                        Standards Track                     [Page 5]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-                           SLASH / COLON / QUESTION / SPACE
-      PrintableString    = 1*PrintableCharacter
-      IA5String          = *(%x00-7F)
-      SLASH              = %x2F  ; forward slash ("/")
-      COLON              = %x3A  ; colon (":")
-      QUESTION           = %x3F  ; question mark ("?")
-
-   The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
-   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
-   [RFC4512].
-
-3.3.  Syntax Definitions
-
-3.3.1.  Attribute Type Description
-
-   A value of the Attribute Type Description syntax is the definition of
-   an attribute type.  The LDAP-specific encoding of a value of this
-   syntax is defined by the <AttributeTypeDescription> rule in
-   [RFC4512].
-
-      For example, the following definition of the createTimestamp
-      attribute type from [RFC4512] is also a value of the Attribute
-      Type Description syntax.  (Note: Line breaks have been added for
-      readability; they are not part of the value when transferred in
-      protocol.)
-
-         ( 2.5.18.1 NAME 'createTimestamp'
-            EQUALITY generalizedTimeMatch
-            ORDERING generalizedTimeOrderingMatch
-            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
-            SINGLE-VALUE NO-USER-MODIFICATION
-            USAGE directoryOperation )
-
-   The LDAP definition for the Attribute Type Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
-
-   This syntax corresponds to the AttributeTypeDescription ASN.1 type
-   from [X.501].
-
-3.3.2.  Bit String
-
-   A value of the Bit String syntax is a sequence of binary digits.  The
-   LDAP-specific encoding of a value of this syntax is defined by the
-   following ABNF:
-
-      BitString    = SQUOTE *binary-digit SQUOTE "B"
-      binary-digit = "0" / "1"
-
-
-
-Legg                        Standards Track                     [Page 6]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The <SQUOTE> rule is defined in [RFC4512].
-
-      Example:
-         '0101111101'B
-
-   The LDAP definition for the Bit String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
-
-   This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
-
-3.3.3.  Boolean
-
-   A value of the Boolean syntax is one of the Boolean values, true or
-   false.  The LDAP-specific encoding of a value of this syntax is
-   defined by the following ABNF:
-
-      Boolean = "TRUE" / "FALSE"
-
-   The LDAP definition for the Boolean syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
-
-   This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
-
-3.3.4.  Country String
-
-   A value of the Country String syntax is one of the two-character
-   codes from ISO 3166 [ISO3166] for representing a country.  The LDAP-
-   specific encoding of a value of this syntax is defined by the
-   following ABNF:
-
-      CountryString  = 2(PrintableCharacter)
-
-   The <PrintableCharacter> rule is defined in Section 3.2.
-
-      Examples:
-
-         US
-         AU
-
-   The LDAP definition for the Country String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
-
-   This syntax corresponds to the following ASN.1 type from [X.520]:
-
-      PrintableString (SIZE (2)) -- ISO 3166 codes only
-
-
-
-Legg                        Standards Track                     [Page 7]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-3.3.5.  Delivery Method
-
-   A value of the Delivery Method syntax is a sequence of items that
-   indicate, in preference order, the service(s) by which an entity is
-   willing and/or capable of receiving messages.  The LDAP-specific
-   encoding of a value of this syntax is defined by the following ABNF:
-
-      DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
-
-      pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
-            "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
-
-   The <WSP> and <DOLLAR> rules are defined in [RFC4512].
-
-      Example:
-         telephone $ videotex
-
-   The LDAP definition for the Delivery Method syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
-
-   This syntax corresponds to the following ASN.1 type from [X.520]:
-
-      SEQUENCE OF INTEGER {
-          any-delivery-method     (0),
-          mhs-delivery            (1),
-          physical-delivery       (2),
-          telex-delivery          (3),
-          teletex-delivery        (4),
-          g3-facsimile-delivery   (5),
-          g4-facsimile-delivery   (6),
-          ia5-terminal-delivery   (7),
-          videotex-delivery       (8),
-          telephone-delivery      (9) }
-
-3.3.6.  Directory String
-
-   A value of the Directory String syntax is a string of one or more
-   arbitrary characters from the Universal Character Set (UCS) [UCS].  A
-   zero-length character string is not permitted.  The LDAP-specific
-   encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of
-   the character string.  Such encodings conform to the following ABNF:
-
-      DirectoryString = 1*UTF8
-
-   The <UTF8> rule is defined in [RFC4512].
-
-
-
-
-
-Legg                        Standards Track                     [Page 8]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      Example:
-         This is a value of Directory String containing #!%#@.
-
-   Servers and clients MUST be prepared to receive arbitrary UCS code
-   points, including code points outside the range of printable ASCII
-   and code points not presently assigned to any character.
-
-   Attribute type definitions using the Directory String syntax should
-   not restrict the format of Directory String values, e.g., by
-   requiring that the character string conforms to specific patterns
-   described by ABNF.  A new syntax should be defined in such cases.
-
-   The LDAP definition for the Directory String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
-
-   This syntax corresponds to the DirectoryString parameterized ASN.1
-   type from [X.520].
-
-   The DirectoryString ASN.1 type allows a choice between the
-   TeletexString, PrintableString, or UniversalString ASN.1 types from
-   [ASN.1].  However, note that the chosen alternative is not indicated
-   in the LDAP-specific encoding of a Directory String value.
-
-   Implementations that convert Directory String values from the LDAP-
-   specific encoding to the BER encoding used by X.500 must choose an
-   alternative that permits the particular characters in the string and
-   must convert the characters from the UTF-8 encoding into the
-   character encoding of the chosen alternative.  When converting
-   Directory String values from the BER encoding to the LDAP-specific
-   encoding, the characters must be converted from the character
-   encoding of the chosen alternative into the UTF-8 encoding.  These
-   conversions SHOULD be done in a manner consistent with the Transcode
-   step of the string preparation algorithms [RFC4518] for LDAP.
-
-3.3.7.  DIT Content Rule Description
-
-   A value of the DIT Content Rule Description syntax is the definition
-   of a DIT (Directory Information Tree) content rule.  The LDAP-
-   specific encoding of a value of this syntax is defined by the
-   <DITContentRuleDescription> rule in [RFC4512].
-
-      Example:
-         ( 2.5.6.4 DESC 'content rule for organization'
-            NOT ( x121Address $ telexNumber ) )
-
-      Note: A line break has been added for readability; it is not part
-      of the value.
-
-
-
-Legg                        Standards Track                     [Page 9]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The LDAP definition for the DIT Content Rule Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.16
-         DESC 'DIT Content Rule Description' )
-
-   This syntax corresponds to the DITContentRuleDescription ASN.1 type
-   from [X.501].
-
-3.3.8.  DIT Structure Rule Description
-
-   A value of the DIT Structure Rule Description syntax is the
-   definition of a DIT structure rule.  The LDAP-specific encoding of a
-   value of this syntax is defined by the <DITStructureRuleDescription>
-   rule in [RFC4512].
-
-      Example:
-         ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
-
-   The LDAP definition for the DIT Structure Rule Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.17
-         DESC 'DIT Structure Rule Description' )
-
-   This syntax corresponds to the DITStructureRuleDescription ASN.1 type
-   from [X.501].
-
-3.3.9.  DN
-
-   A value of the DN syntax is the (purported) distinguished name (DN)
-   of an entry [RFC4512].  The LDAP-specific encoding of a value of this
-   syntax is defined by the <distinguishedName> rule from the string
-   representation of distinguished names [RFC4514].
-
-      Examples (from [RFC4514]):
-         UID=jsmith,DC=example,DC=net
-         OU=Sales+CN=J. Smith,DC=example,DC=net
-         CN=John Smith\, III,DC=example,DC=net
-         CN=Before\0dAfter,DC=example,DC=net
-         1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
-         CN=Lu\C4\8Di\C4\87
-
-   The LDAP definition for the DN syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
-
-   The DN syntax corresponds to the DistinguishedName ASN.1 type from
-   [X.501].  Note that a BER encoded distinguished name (as used by
-   X.500) re-encoded into the LDAP-specific encoding is not necessarily
-
-
-
-Legg                        Standards Track                    [Page 10]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   reversible to the original BER encoding since the chosen string type
-   in any DirectoryString components of the distinguished name is not
-   indicated in the LDAP-specific encoding of the distinguished name
-   (see Section 3.3.6).
-
-3.3.10.  Enhanced Guide
-
-   A value of the Enhanced Guide syntax suggests criteria, which consist
-   of combinations of attribute types and filter operators, to be used
-   in constructing filters to search for entries of particular object
-   classes.  The Enhanced Guide syntax improves upon the Guide syntax by
-   allowing the recommended depth of the search to be specified.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      EnhancedGuide = object-class SHARP WSP criteria WSP
-                         SHARP WSP subset
-      object-class  = WSP oid WSP
-      subset        = "baseobject" / "oneLevel" / "wholeSubtree"
-
-      criteria   = and-term *( BAR and-term )
-      and-term   = term *( AMPERSAND term )
-      term       = EXCLAIM term /
-                   attributetype DOLLAR match-type /
-                   LPAREN criteria RPAREN /
-                   true /
-                   false
-      match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
-      true       = "?true"
-      false      = "?false"
-      BAR        = %x7C  ; vertical bar ("|")
-      AMPERSAND  = %x26  ; ampersand ("&")
-      EXCLAIM    = %x21  ; exclamation mark ("!")
-
-   The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and
-   <DOLLAR> rules are defined in [RFC4512].
-
-   The LDAP definition for the Enhanced Guide syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
-
-      Example:
-         person#(sn$EQ)#oneLevel
-
-   The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
-   from [X.520].  The EnhancedGuide type references the Criteria ASN.1
-   type, also from [X.520].  The <true> rule, above, represents an empty
-
-
-
-Legg                        Standards Track                    [Page 11]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   "and" expression in a value of the Criteria type.  The <false> rule,
-   above, represents an empty "or" expression in a value of the Criteria
-   type.
-
-3.3.11.  Facsimile Telephone Number
-
-   A value of the Facsimile Telephone Number syntax is a subscriber
-   number of a facsimile device on the public switched telephone
-   network.  The LDAP-specific encoding of a value of this syntax is
-   defined by the following ABNF:
-
-      fax-number       = telephone-number *( DOLLAR fax-parameter )
-      telephone-number = PrintableString
-      fax-parameter    = "twoDimensional" /
-                         "fineResolution" /
-                         "unlimitedLength" /
-                         "b4Length" /
-                         "a3Width" /
-                         "b4Width" /
-                         "uncompressed"
-
-   The <telephone-number> is a string of printable characters that
-   complies with the internationally agreed format for representing
-   international telephone numbers [E.123].  The <PrintableString> rule
-   is defined in Section 3.2.  The <DOLLAR> rule is defined in
-   [RFC4512].
-
-   The LDAP definition for the Facsimile Telephone Number syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
-
-   The Facsimile Telephone Number syntax corresponds to the
-   FacsimileTelephoneNumber ASN.1 type from [X.520].
-
-3.3.12.  Fax
-
-   A value of the Fax syntax is an image that is produced using the
-   Group 3 facsimile process [FAX] to duplicate an object, such as a
-   memo.  The LDAP-specific encoding of a value of this syntax is the
-   string of octets for a Group 3 Fax image as defined in [FAX].
-
-   The LDAP definition for the Fax syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
-
-   The ASN.1 type corresponding to the Fax syntax is defined as follows,
-   assuming EXPLICIT TAGS:
-
-
-
-
-Legg                        Standards Track                    [Page 12]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      Fax ::= CHOICE {
-        g3-facsimile  [3] G3FacsimileBodyPart
-      }
-
-   The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
-
-3.3.13.  Generalized Time
-
-   A value of the Generalized Time syntax is a character string
-   representing a date and time.  The LDAP-specific encoding of a value
-   of this syntax is a restriction of the format defined in [ISO8601],
-   and is described by the following ABNF:
-
-      GeneralizedTime = century year month day hour
-                           [ minute [ second / leap-second ] ]
-                           [ fraction ]
-                           g-time-zone
-
-      century = 2(%x30-39) ; "00" to "99"
-      year    = 2(%x30-39) ; "00" to "99"
-      month   =   ( %x30 %x31-39 ) ; "01" (January) to "09"
-                / ( %x31 %x30-32 ) ; "10" to "12"
-      day     =   ( %x30 %x31-39 )    ; "01" to "09"
-                / ( %x31-32 %x30-39 ) ; "10" to "29"
-                / ( %x33 %x30-31 )    ; "30" to "31"
-      hour    = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
-      minute  = %x30-35 %x30-39                        ; "00" to "59"
-
-      second      = ( %x30-35 %x30-39 ) ; "00" to "59"
-      leap-second = ( %x36 %x30 )       ; "60"
-
-      fraction        = ( DOT / COMMA ) 1*(%x30-39)
-      g-time-zone     = %x5A  ; "Z"
-                        / g-differential
-      g-differential  = ( MINUS / PLUS ) hour [ minute ]
-      MINUS           = %x2D  ; minus sign ("-")
-
-   The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
-
-   The above ABNF allows character strings that do not represent valid
-   dates (in the Gregorian calendar) and/or valid times (e.g., February
-   31, 1994).  Such character strings SHOULD be considered invalid for
-   this syntax.
-
-   The time value represents coordinated universal time (equivalent to
-   Greenwich Mean Time) if the "Z" form of <g-time-zone> is used;
-   otherwise, the value represents a local time in the time zone
-   indicated by <g-differential>.  In the latter case, coordinated
-
-
-
-Legg                        Standards Track                    [Page 13]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   universal time can be calculated by subtracting the differential from
-   the local time.  The "Z" form of <g-time-zone> SHOULD be used in
-   preference to <g-differential>.
-
-   If <minute> is omitted, then <fraction> represents a fraction of an
-   hour; otherwise, if <second> and <leap-second> are omitted, then
-   <fraction> represents a fraction of a minute; otherwise, <fraction>
-   represents a fraction of a second.
-
-      Examples:
-         199412161032Z
-         199412160532-0500
-
-   Both example values represent the same coordinated universal time:
-   10:32 AM, December 16, 1994.
-
-   The LDAP definition for the Generalized Time syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
-
-   This syntax corresponds to the GeneralizedTime ASN.1 type from
-   [ASN.1], with the constraint that local time without a differential
-   SHALL NOT be used.
-
-3.3.14.  Guide
-
-   A value of the Guide syntax suggests criteria, which consist of
-   combinations of attribute types and filter operators, to be used in
-   constructing filters to search for entries of particular object
-   classes.  The Guide syntax is obsolete and should not be used for
-   defining new attribute types.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      Guide = [ object-class SHARP ] criteria
-
-   The <object-class> and <criteria> rules are defined in Section
-   3.3.10.  The <SHARP> rule is defined in [RFC4512].
-
-   The LDAP definition for the Guide syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
-
-   The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 14]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-3.3.15.  IA5 String
-
-   A value of the IA5 String syntax is a string of zero, one, or more
-   characters from International Alphabet 5 (IA5) [T.50], the
-   international version of the ASCII character set.  The LDAP-specific
-   encoding of a value of this syntax is the unconverted string of
-   characters, which conforms to the <IA5String> rule in Section 3.2.
-
-   The LDAP definition for the IA5 String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
-
-   This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
-
-3.3.16.  Integer
-
-   A value of the Integer syntax is a whole number of unlimited
-   magnitude.  The LDAP-specific encoding of a value of this syntax is
-   the optionally signed decimal digit character string representation
-   of the number (for example, the number 1321 is represented by the
-   character string "1321").  The encoding is defined by the following
-   ABNF:
-
-      Integer = ( HYPHEN LDIGIT *DIGIT ) / number
-
-   The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in
-   [RFC4512].
-
-   The LDAP definition for the Integer syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
-
-   This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
-
-3.3.17.  JPEG
-
-   A value of the JPEG syntax is an image in the JPEG File Interchange
-   Format (JFIF), as described in [JPEG].  The LDAP-specific encoding of
-   a value of this syntax is the sequence of octets of the JFIF encoding
-   of the image.
-
-   The LDAP definition for the JPEG syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
-
-   The JPEG syntax corresponds to the following ASN.1 type:
-
-
-
-
-
-Legg                        Standards Track                    [Page 15]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      JPEG ::= OCTET STRING (CONSTRAINED BY
-                   { -- contents octets are an image in the --
-                     -- JPEG File Interchange Format -- })
-
-3.3.18.  LDAP Syntax Description
-
-   A value of the LDAP Syntax Description syntax is the description of
-   an LDAP syntax.  The LDAP-specific encoding of a value of this syntax
-   is defined by the <SyntaxDescription> rule in [RFC4512].
-
-   The LDAP definition for the LDAP Syntax Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
-
-   The above LDAP definition for the LDAP Syntax Description syntax is
-   itself a legal value of the LDAP Syntax Description syntax.
-
-   The ASN.1 type corresponding to the LDAP Syntax Description syntax is
-   defined as follows, assuming EXPLICIT TAGS:
-
-      LDAPSyntaxDescription ::= SEQUENCE {
-          identifier      OBJECT IDENTIFIER,
-          description     DirectoryString { ub-schema } OPTIONAL }
-
-   The DirectoryString parameterized ASN.1 type is defined in [X.520].
-
-   The value of ub-schema (an integer) is implementation defined.  A
-   non-normative definition appears in [X.520].
-
-3.3.19.  Matching Rule Description
-
-   A value of the Matching Rule Description syntax is the definition of
-   a matching rule.  The LDAP-specific encoding of a value of this
-   syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
-
-      Example:
-         ( 2.5.13.2 NAME 'caseIgnoreMatch'
-            SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   Note: A line break has been added for readability; it is not part of
-   the syntax.
-
-   The LDAP definition for the Matching Rule Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
-
-   This syntax corresponds to the MatchingRuleDescription ASN.1 type
-   from [X.501].
-
-
-
-Legg                        Standards Track                    [Page 16]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-3.3.20.  Matching Rule Use Description
-
-   A value of the Matching Rule Use Description syntax indicates the
-   attribute types to which a matching rule may be applied in an
-   extensibleMatch search filter [RFC4511].  The LDAP-specific encoding
-   of a value of this syntax is defined by the
-   <MatchingRuleUseDescription> rule in [RFC4512].
-
-      Example:
-         ( 2.5.13.16 APPLIES ( givenName $ surname ) )
-
-   The LDAP definition for the Matching Rule Use Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.31
-         DESC 'Matching Rule Use Description' )
-
-   This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
-   from [X.501].
-
-3.3.21.  Name and Optional UID
-
-   A value of the Name and Optional UID syntax is the distinguished name
-   [RFC4512] of an entity optionally accompanied by a unique identifier
-   that serves to differentiate the entity from others with an identical
-   distinguished name.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      NameAndOptionalUID = distinguishedName [ SHARP BitString ]
-
-   The <BitString> rule is defined in Section 3.3.2.  The
-   <distinguishedName> rule is defined in [RFC4514].  The <SHARP> rule
-   is defined in [RFC4512].
-
-   Note that although the '#' character may occur in the string
-   representation of a distinguished name, no additional escaping of
-   this character is performed when a <distinguishedName> is encoded in
-   a <NameAndOptionalUID>.
-
-      Example:
-         1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
-
-   The LDAP definition for the Name and Optional UID syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
-
-
-
-
-
-Legg                        Standards Track                    [Page 17]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   This syntax corresponds to the NameAndOptionalUID ASN.1 type from
-   [X.520].
-
-3.3.22.  Name Form Description
-
-   A value of the Name Form Description syntax is the definition of a
-   name form, which regulates how entries may be named.  The LDAP-
-   specific encoding of a value of this syntax is defined by the
-   <NameFormDescription> rule in [RFC4512].
-
-      Example:
-         ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
-
-   The LDAP definition for the Name Form Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
-
-   This syntax corresponds to the NameFormDescription ASN.1 type from
-   [X.501].
-
-3.3.23.  Numeric String
-
-   A value of the Numeric String syntax is a sequence of one or more
-   numerals and spaces.  The LDAP-specific encoding of a value of this
-   syntax is the unconverted string of characters, which conforms to the
-   following ABNF:
-
-      NumericString = 1*(DIGIT / SPACE)
-
-   The <DIGIT> and <SPACE> rules are defined in [RFC4512].
-
-      Example:
-         15 079 672 281
-
-   The LDAP definition for the Numeric String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
-
-   This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
-
-3.3.24.  Object Class Description
-
-   A value of the Object Class Description syntax is the definition of
-   an object class.  The LDAP-specific encoding of a value of this
-   syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 18]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      Example:
-         ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
-            MAY ( searchGuide $ description ) )
-
-   Note: A line break has been added for readability; it is not part of
-   the syntax.
-
-   The LDAP definition for the Object Class Description syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
-
-   This syntax corresponds to the ObjectClassDescription ASN.1 type from
-   [X.501].
-
-3.3.25.  Octet String
-
-   A value of the Octet String syntax is a sequence of zero, one, or
-   more arbitrary octets.  The LDAP-specific encoding of a value of this
-   syntax is the unconverted sequence of octets, which conforms to the
-   following ABNF:
-
-      OctetString = *OCTET
-
-   The <OCTET> rule is defined in [RFC4512].  Values of this syntax are
-   not generally human-readable.
-
-   The LDAP definition for the Octet String syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
-
-   This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
-
-3.3.26.  OID
-
-   A value of the OID syntax is an object identifier: a sequence of two
-   or more non-negative integers that uniquely identify some object or
-   item of specification.  Many of the object identifiers used in LDAP
-   also have IANA registered names [RFC4520].
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the <oid> rule in [RFC4512].
-
-      Examples:
-         1.2.3.4
-         cn
-
-   The LDAP definition for the OID syntax is:
-
-
-
-
-Legg                        Standards Track                    [Page 19]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
-
-   This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
-   [ASN.1].
-
-3.3.27.  Other Mailbox
-
-   A value of the Other Mailbox syntax identifies an electronic mailbox,
-   in a particular named mail system.  The LDAP-specific encoding of a
-   value of this syntax is defined by the following ABNF:
-
-      OtherMailbox = mailbox-type DOLLAR mailbox
-      mailbox-type = PrintableString
-      mailbox      = IA5String
-
-   The <mailbox-type> rule represents the type of mail system in which
-   the mailbox resides (for example, "MCIMail"), and <mailbox> is the
-   actual mailbox in the mail system described by <mailbox-type>.  The
-   <PrintableString> and <IA5String> rules are defined in Section 3.2.
-   The <DOLLAR> rule is defined in [RFC4512].
-
-   The LDAP definition for the Other Mailbox syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
-
-   The ASN.1 type corresponding to the Other Mailbox syntax is defined
-   as follows, assuming EXPLICIT TAGS:
-
-      OtherMailbox ::= SEQUENCE {
-          mailboxType  PrintableString,
-          mailbox      IA5String
-      }
-
-3.3.28.  Postal Address
-
-   A value of the Postal Address syntax is a sequence of strings of one
-   or more arbitrary UCS characters, which form an address in a physical
-   mail system.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-
-
-
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 20]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      PostalAddress = line *( DOLLAR line )
-      line          = 1*line-char
-      line-char     = %x00-23
-                      / (%x5C "24")  ; escaped "$"
-                      / %x25-5B
-                      / (%x5C "5C")  ; escaped "\"
-                      / %x5D-7F
-                      / UTFMB
-
-   Each character string (i.e., <line>) of a postal address value is
-   encoded as a UTF-8 [RFC3629] string, except that "\" and "$"
-   characters, if they occur in the string, are escaped by a "\"
-   character followed by the two hexadecimal digit code for the
-   character.  The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
-
-   Many servers limit the postal address to no more than six lines of no
-   more than thirty characters each.
-
-      Example:
-         1234 Main St.$Anytown, CA 12345$USA
-         \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
-
-   The LDAP definition for the Postal Address syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
-
-   This syntax corresponds to the PostalAddress ASN.1 type from [X.520];
-   that is
-
-      PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
-          DirectoryString { ub-postal-string }
-
-   The values of ub-postal-line and ub-postal-string (both integers) are
-   implementation defined.  Non-normative definitions appear in [X.520].
-
-3.3.29.  Printable String
-
-   A value of the Printable String syntax is a string of one or more
-   latin alphabetic, numeric, and selected punctuation characters as
-   specified by the <PrintableCharacter> rule in Section 3.2.
-
-   The LDAP-specific encoding of a value of this syntax is the
-   unconverted string of characters, which conforms to the
-   <PrintableString> rule in Section 3.2.
-
-      Example:
-         This is a PrintableString.
-
-
-
-
-Legg                        Standards Track                    [Page 21]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The LDAP definition for the PrintableString syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
-
-   This syntax corresponds to the PrintableString ASN.1 type from
-   [ASN.1].
-
-3.3.30.  Substring Assertion
-
-   A value of the Substring Assertion syntax is a sequence of zero, one,
-   or more character substrings used as an argument for substring
-   extensible matching of character string attribute values; i.e., as
-   the matchValue of a MatchingRuleAssertion [RFC4511].  Each substring
-   is a string of one or more arbitrary characters from the Universal
-   Character Set (UCS) [UCS].  A zero-length substring is not permitted.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      SubstringAssertion = [ initial ] any [ final ]
-
-      initial  = substring
-      any      = ASTERISK *(substring ASTERISK)
-      final    = substring
-      ASTERISK = %x2A  ; asterisk ("*")
-
-      substring           = 1*substring-character
-      substring-character = %x00-29
-                            / (%x5C "2A")  ; escaped "*"
-                            / %x2B-5B
-                            / (%x5C "5C")  ; escaped "\"
-                            / %x5D-7F
-                            / UTFMB
-
-   Each <substring> of a Substring Assertion value is encoded as a UTF-8
-   [RFC3629] string, except that "\" and "*" characters, if they occur
-   in the substring, are escaped by a "\" character followed by the two
-   hexadecimal digit code for the character.
-
-   The Substring Assertion syntax is used only as the syntax of
-   assertion values in the extensible match.  It is not used as an
-   attribute syntax, or in the SubstringFilter [RFC4511].
-
-   The LDAP definition for the Substring Assertion syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
-
-
-
-
-
-Legg                        Standards Track                    [Page 22]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   This syntax corresponds to the SubstringAssertion ASN.1 type from
-   [X.520].
-
-3.3.31.  Telephone Number
-
-   A value of the Telephone Number syntax is a string of printable
-   characters that complies with the internationally agreed format for
-   representing international telephone numbers [E.123].
-
-   The LDAP-specific encoding of a value of this syntax is the
-   unconverted string of characters, which conforms to the
-   <PrintableString> rule in Section 3.2.
-
-      Examples:
-         +1 512 315 0280
-         +1-512-315-0280
-         +61 3 9896 7830
-
-   The LDAP definition for the Telephone Number syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
-
-   The Telephone Number syntax corresponds to the following ASN.1 type
-   from [X.520]:
-
-      PrintableString (SIZE(1..ub-telephone-number))
-
-   The value of ub-telephone-number (an integer) is implementation
-   defined.  A non-normative definition appears in [X.520].
-
-3.3.32.  Teletex Terminal Identifier
-
-   A value of this syntax specifies the identifier and (optionally)
-   parameters of a teletex terminal.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      teletex-id = ttx-term *(DOLLAR ttx-param)
-      ttx-term   = PrintableString          ; terminal identifier
-      ttx-param  = ttx-key COLON ttx-value  ; parameter
-      ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
-      ttx-value  = *ttx-value-octet
-
-      ttx-value-octet = %x00-23
-                        / (%x5C "24")  ; escaped "$"
-                        / %x25-5B
-                        / (%x5C "5C")  ; escaped "\"
-
-
-
-Legg                        Standards Track                    [Page 23]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-                        / %x5D-FF
-
-   The <PrintableString> and <COLON> rules are defined in Section 3.2.
-   The <DOLLAR> rule is defined in [RFC4512].
-
-   The LDAP definition for the Teletex Terminal Identifier syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.51
-         DESC 'Teletex Terminal Identifier' )
-
-   This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
-   from [X.520].
-
-3.3.33.  Telex Number
-
-   A value of the Telex Number syntax specifies the telex number,
-   country code, and answerback code of a telex terminal.
-
-   The LDAP-specific encoding of a value of this syntax is defined by
-   the following ABNF:
-
-      telex-number  = actual-number DOLLAR country-code
-                         DOLLAR answerback
-      actual-number = PrintableString
-      country-code  = PrintableString
-      answerback    = PrintableString
-
-   The <PrintableString> rule is defined in Section 3.2.  The <DOLLAR>
-   rule is defined in [RFC4512].
-
-   The LDAP definition for the Telex Number syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
-
-   This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
-
-3.3.34.  UTC Time
-
-   A value of the UTC Time syntax is a character string representing a
-   date and time to a precision of one minute or one second.  The year
-   is given as a two-digit number.  The LDAP-specific encoding of a
-   value of this syntax follows the format defined in [ASN.1] for the
-   UTCTime type and is described by the following ABNF:
-
-      UTCTime         = year month day hour minute [ second ]
-                           [ u-time-zone ]
-      u-time-zone     = %x5A  ; "Z"
-                        / u-differential
-
-
-
-Legg                        Standards Track                    [Page 24]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      u-differential  = ( MINUS / PLUS ) hour minute
-
-   The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS>
-   rules are defined in Section 3.3.13.  The <PLUS> rule is defined in
-   [RFC4512].
-
-   The above ABNF allows character strings that do not represent valid
-   dates (in the Gregorian calendar) and/or valid times.  Such character
-   strings SHOULD be considered invalid for this syntax.
-
-   The time value represents coordinated universal time if the "Z" form
-   of <u-time-zone> is used; otherwise, the value represents a local
-   time.  In the latter case, if <u-differential> is provided, then
-   coordinated universal time can be calculated by subtracting the
-   differential from the local time.  The <u-time-zone> SHOULD be
-   present in time values, and the "Z" form of <u-time-zone> SHOULD be
-   used in preference to <u-differential>.
-
-   The LDAP definition for the UTC Time syntax is:
-
-      ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
-
-   Note: This syntax is deprecated in favor of the Generalized Time
-   syntax.
-
-   The UTC Time syntax corresponds to the UTCTime ASN.1 type from
-   [ASN.1].
-
-4.  Matching Rules
-
-   Matching rules are used by directory implementations to compare
-   attribute values against assertion values when performing Search and
-   Compare operations [RFC4511].  They are also used when comparing a
-   purported distinguished name [RFC4512] with the name of an entry.
-   When modifying entries, matching rules are used to identify values to
-   be deleted and to prevent an attribute from containing two equal
-   values.
-
-   Matching rules that are required for directory operation, or that are
-   in common use, are specified in this section.
-
-4.1.  General Considerations
-
-   A matching rule is applied to attribute values through an
-   AttributeValueAssertion or MatchingRuleAssertion [RFC4511].  The
-   conditions under which an AttributeValueAssertion or
-   MatchingRuleAssertion evaluates to Undefined are specified elsewhere
-   [RFC4511].  If an assertion is not Undefined, then the result of the
-
-
-
-Legg                        Standards Track                    [Page 25]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   assertion is the result of applying the selected matching rule.  A
-   matching rule evaluates to TRUE, and in some cases Undefined, as
-   specified in the description of the matching rule; otherwise, it
-   evaluates to FALSE.
-
-   Each assertion contains an assertion value.  The definition of each
-   matching rule specifies the syntax for the assertion value.  The
-   syntax of the assertion value is typically, but not necessarily, the
-   same as the syntax of the attribute values to which the matching rule
-   may be applied.  Note that an AssertionValue in a SubstringFilter
-   [RFC4511] conforms to the assertion syntax of the equality matching
-   rule for the attribute type rather than to the assertion syntax of
-   the substrings matching rule for the attribute type.  Conceptually,
-   the entire SubstringFilter is converted into an assertion value of
-   the substrings matching rule prior to applying the rule.
-
-   The definition of each matching rule indicates the attribute syntaxes
-   to which the rule may be applied, by specifying conditions the
-   corresponding ASN.1 type of a candidate attribute syntax must
-   satisfy.  These conditions are also satisfied if the corresponding
-   ASN.1 type is a tagged or constrained derivative of the ASN.1 type
-   explicitly mentioned in the rule description (i.e., ASN.1 tags and
-   constraints are ignored in checking applicability), or is an
-   alternative reference notation for the explicitly mentioned type.
-   Each rule description lists, as examples of applicable attribute
-   syntaxes, the complete list of the syntaxes defined in this document
-   to which the matching rule applies.  A matching rule may be
-   applicable to additional syntaxes defined in other documents if those
-   syntaxes satisfy the conditions on the corresponding ASN.1 type.
-
-   The description of each matching rule indicates whether the rule is
-   suitable for use as the equality matching rule (EQUALITY), ordering
-   matching rule (ORDERING), or substrings matching rule (SUBSTR) in an
-   attribute type definition [RFC4512].
-
-   Each matching rule is uniquely identified with an object identifier.
-   The definition of a matching rule should not subsequently be changed.
-   If a change is desirable, then a new matching rule with a different
-   object identifier should be defined instead.
-
-   Servers MAY implement the wordMatch and keywordMatch matching rules,
-   but they SHOULD implement the other matching rules in Section 4.2.
-   Servers MAY implement additional matching rules.
-
-   Servers that implement the extensibleMatch filter SHOULD allow the
-   matching rules listed in Section 4.2 to be used in the
-   extensibleMatch filter and SHOULD allow matching rules to be used
-   with all attribute types known to the server, where the assertion
-
-
-
-Legg                        Standards Track                    [Page 26]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   syntax of the matching rule is the same as the value syntax of the
-   attribute.
-
-   Servers MUST publish, in the matchingRules attribute, the definitions
-   of matching rules referenced by values of the attributeTypes and
-   matchingRuleUse attributes in the same subschema entry.  Other
-   unreferenced matching rules MAY be published in the matchingRules
-   attribute.
-
-   If the server supports the extensibleMatch filter, then the server
-   MAY use the matchingRuleUse attribute to indicate the applicability
-   (in an extensibleMatch filter) of selected matching rules to
-   nominated attribute types.
-
-4.2.  Matching Rule Definitions
-
-   Nominated character strings in assertion and attribute values are
-   prepared according to the string preparation algorithms [RFC4518] for
-   LDAP when evaluating the following matching rules:
-
-      numericStringMatch,
-      numericStringSubstringsMatch,
-      caseExactMatch,
-      caseExactOrderingMatch,
-      caseExactSubstringsMatch,
-      caseExactIA5Match,
-      caseIgnoreIA5Match,
-      caseIgnoreIA5SubstringsMatch,
-      caseIgnoreListMatch,
-      caseIgnoreListSubstringsMatch,
-      caseIgnoreMatch,
-      caseIgnoreOrderingMatch,
-      caseIgnoreSubstringsMatch,
-      directoryStringFirstComponentMatch,
-      telephoneNumberMatch,
-      telephoneNumberSubstringsMatch and
-      wordMatch.
-
-   The Transcode, Normalize, Prohibit, and Check bidi steps are the same
-   for each of the matching rules.  However, the Map and Insignificant
-   Character Handling steps depend on the specific rule, as detailed in
-   the description of these matching rules in the sections that follow.
-
-4.2.1.  bitStringMatch
-
-   The bitStringMatch rule compares an assertion value of the Bit String
-   syntax to an attribute value of a syntax (e.g., the Bit String
-   syntax) whose corresponding ASN.1 type is BIT STRING.
-
-
-
-Legg                        Standards Track                    [Page 27]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   If the corresponding ASN.1 type of the attribute syntax does not have
-   a named bit list [ASN.1] (which is the case for the Bit String
-   syntax), then the rule evaluates to TRUE if and only if the attribute
-   value has the same number of bits as the assertion value and the bits
-   match on a bitwise basis.
-
-   If the corresponding ASN.1 type does have a named bit list, then
-   bitStringMatch operates as above, except that trailing zero bits in
-   the attribute and assertion values are treated as absent.
-
-   The LDAP definition for the bitStringMatch rule is:
-
-      ( 2.5.13.16 NAME 'bitStringMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
-   The bitStringMatch rule is an equality matching rule.
-
-4.2.2.  booleanMatch
-
-   The booleanMatch rule compares an assertion value of the Boolean
-   syntax to an attribute value of a syntax (e.g., the Boolean syntax)
-   whose corresponding ASN.1 type is BOOLEAN.
-
-   The rule evaluates to TRUE if and only if the attribute value and the
-   assertion value are both TRUE or both FALSE.
-
-   The LDAP definition for the booleanMatch rule is:
-
-      ( 2.5.13.13 NAME 'booleanMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
-
-   The booleanMatch rule is an equality matching rule.
-
-4.2.3.  caseExactIA5Match
-
-   The caseExactIA5Match rule compares an assertion value of the IA5
-   String syntax to an attribute value of a syntax (e.g., the IA5 String
-   syntax) whose corresponding ASN.1 type is IA5String.
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-
-
-Legg                        Standards Track                    [Page 28]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The LDAP definition for the caseExactIA5Match rule is:
-
-      ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-   The caseExactIA5Match rule is an equality matching rule.
-
-4.2.4.  caseExactMatch
-
-   The caseExactMatch rule compares an assertion value of the Directory
-   String syntax to an attribute value of a syntax (e.g., the Directory
-   String, Printable String, Country String, or Telephone Number syntax)
-   whose corresponding ASN.1 type is DirectoryString or one of the
-   alternative string types of DirectoryString, such as PrintableString
-   (the other alternatives do not correspond to any syntax defined in
-   this document).
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseExactMatch rule is:
-
-      ( 2.5.13.5 NAME 'caseExactMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   The caseExactMatch rule is an equality matching rule.
-
-4.2.5.  caseExactOrderingMatch
-
-   The caseExactOrderingMatch rule compares an assertion value of the
-   Directory String syntax to an attribute value of a syntax (e.g., the
-   Directory String, Printable String, Country String, or Telephone
-   Number syntax) whose corresponding ASN.1 type is DirectoryString or
-   one of its alternative string types.
-
-   The rule evaluates to TRUE if and only if, in the code point
-   collation order, the prepared attribute value character string
-   appears earlier than the prepared assertion value character string;
-   i.e., the attribute value is "less than" the assertion value.
-
-
-
-
-
-Legg                        Standards Track                    [Page 29]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseExactOrderingMatch rule is:
-
-      ( 2.5.13.6 NAME 'caseExactOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   The caseExactOrderingMatch rule is an ordering matching rule.
-
-4.2.6.  caseExactSubstringsMatch
-
-   The caseExactSubstringsMatch rule compares an assertion value of the
-   Substring Assertion syntax to an attribute value of a syntax (e.g.,
-   the Directory String, Printable String, Country String, or Telephone
-   Number syntax) whose corresponding ASN.1 type is DirectoryString or
-   one of its alternative string types.
-
-   The rule evaluates to TRUE if and only if (1) the prepared substrings
-   of the assertion value match disjoint portions of the prepared
-   attribute value character string in the order of the substrings in
-   the assertion value, (2) an <initial> substring, if present, matches
-   the beginning of the prepared attribute value character string, and
-   (3) a <final> substring, if present, matches the end of the prepared
-   attribute value character string.  A prepared substring matches a
-   portion of the prepared attribute value character string if
-   corresponding characters have the same code point.
-
-   In preparing the attribute value and assertion value substrings for
-   comparison, characters are not case folded in the Map preparation
-   step, and only Insignificant Space Handling is applied in the
-   Insignificant Character Handling step.
-
-   The LDAP definition for the caseExactSubstringsMatch rule is:
-
-      ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The caseExactSubstringsMatch rule is a substrings matching rule.
-
-4.2.7.  caseIgnoreIA5Match
-
-   The caseIgnoreIA5Match rule compares an assertion value of the IA5
-   String syntax to an attribute value of a syntax (e.g., the IA5 String
-   syntax) whose corresponding ASN.1 type is IA5String.
-
-
-
-
-Legg                        Standards Track                    [Page 30]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseIgnoreIA5Match rule is:
-
-      ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-   The caseIgnoreIA5Match rule is an equality matching rule.
-
-4.2.8.  caseIgnoreIA5SubstringsMatch
-
-   The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
-   the Substring Assertion syntax to an attribute value of a syntax
-   (e.g., the IA5 String syntax) whose corresponding ASN.1 type is
-   IA5String.
-
-   The rule evaluates to TRUE if and only if (1) the prepared substrings
-   of the assertion value match disjoint portions of the prepared
-   attribute value character string in the order of the substrings in
-   the assertion value, (2) an <initial> substring, if present, matches
-   the beginning of the prepared attribute value character string, and
-   (3) a <final> substring, if present, matches the end of the prepared
-   attribute value character string.  A prepared substring matches a
-   portion of the prepared attribute value character string if
-   corresponding characters have the same code point.
-
-   In preparing the attribute value and assertion value substrings for
-   comparison, characters are case folded in the Map preparation step,
-   and only Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-      ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
-
-4.2.9.  caseIgnoreListMatch
-
-   The caseIgnoreListMatch rule compares an assertion value that is a
-   sequence of strings to an attribute value of a syntax (e.g., the
-
-
-
-Legg                        Standards Track                    [Page 31]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
-   OF the DirectoryString ASN.1 type.
-
-   The rule evaluates to TRUE if and only if the attribute value and the
-   assertion value have the same number of strings and corresponding
-   strings (by position) match according to the caseIgnoreMatch matching
-   rule.
-
-   In [X.520], the assertion syntax for this matching rule is defined to
-   be:
-
-      SEQUENCE OF DirectoryString {ub-match}
-
-   That is, it is different from the corresponding type for the Postal
-   Address syntax.  The choice of the Postal Address syntax for the
-   assertion syntax of the caseIgnoreListMatch in LDAP should not be
-   seen as limiting the matching rule to apply only to attributes with
-   the Postal Address syntax.
-
-   The LDAP definition for the caseIgnoreListMatch rule is:
-
-      ( 2.5.13.11 NAME 'caseIgnoreListMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-   The caseIgnoreListMatch rule is an equality matching rule.
-
-4.2.10.  caseIgnoreListSubstringsMatch
-
-   The caseIgnoreListSubstringsMatch rule compares an assertion value of
-   the Substring Assertion syntax to an attribute value of a syntax
-   (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
-   SEQUENCE OF the DirectoryString ASN.1 type.
-
-   The rule evaluates to TRUE if and only if the assertion value
-   matches, per the caseIgnoreSubstringsMatch rule, the character string
-   formed by concatenating the strings of the attribute value, except
-   that none of the <initial>, <any>, or <final> substrings of the
-   assertion value are considered to match a substring of the
-   concatenated string which spans more than one of the original strings
-   of the attribute value.
-
-   Note that, in terms of the LDAP-specific encoding of the Postal
-   Address syntax, the concatenated string omits the <DOLLAR> line
-   separator and the escaping of "\" and "$" characters.
-
-   The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
-
-      ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
-
-
-
-Legg                        Standards Track                    [Page 32]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
-
-4.2.11.  caseIgnoreMatch
-
-   The caseIgnoreMatch rule compares an assertion value of the Directory
-   String syntax to an attribute value of a syntax (e.g., the Directory
-   String, Printable String, Country String, or Telephone Number syntax)
-   whose corresponding ASN.1 type is DirectoryString or one of its
-   alternative string types.
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseIgnoreMatch rule is:
-
-      ( 2.5.13.2 NAME 'caseIgnoreMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   The caseIgnoreMatch rule is an equality matching rule.
-
-4.2.12.  caseIgnoreOrderingMatch
-
-   The caseIgnoreOrderingMatch rule compares an assertion value of the
-   Directory String syntax to an attribute value of a syntax (e.g., the
-   Directory String, Printable String, Country String, or Telephone
-   Number syntax) whose corresponding ASN.1 type is DirectoryString or
-   one of its alternative string types.
-
-   The rule evaluates to TRUE if and only if, in the code point
-   collation order, the prepared attribute value character string
-   appears earlier than the prepared assertion value character string;
-   i.e., the attribute value is "less than" the assertion value.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are case folded in the Map preparation step, and only
-   Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseIgnoreOrderingMatch rule is:
-
-
-
-Legg                        Standards Track                    [Page 33]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   The caseIgnoreOrderingMatch rule is an ordering matching rule.
-
-4.2.13.  caseIgnoreSubstringsMatch
-
-   The caseIgnoreSubstringsMatch rule compares an assertion value of the
-   Substring Assertion syntax to an attribute value of a syntax (e.g.,
-   the Directory String, Printable String, Country String, or Telephone
-   Number syntax) whose corresponding ASN.1 type is DirectoryString or
-   one of its alternative string types.
-
-   The rule evaluates to TRUE if and only if (1) the prepared substrings
-   of the assertion value match disjoint portions of the prepared
-   attribute value character string in the order of the substrings in
-   the assertion value, (2) an <initial> substring, if present, matches
-   the beginning of the prepared attribute value character string, and
-   (3) a <final> substring, if present, matches the end of the prepared
-   attribute value character string.  A prepared substring matches a
-   portion of the prepared attribute value character string if
-   corresponding characters have the same code point.
-
-   In preparing the attribute value and assertion value substrings for
-   comparison, characters are case folded in the Map preparation step,
-   and only Insignificant Space Handling is applied in the Insignificant
-   Character Handling step.
-
-   The LDAP definition for the caseIgnoreSubstringsMatch rule is:
-
-      ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The caseIgnoreSubstringsMatch rule is a substrings matching rule.
-
-4.2.14.  directoryStringFirstComponentMatch
-
-   The directoryStringFirstComponentMatch rule compares an assertion
-   value of the Directory String syntax to an attribute value of a
-   syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
-   first component of the DirectoryString ASN.1 type.
-
-   Note that the assertion syntax of this matching rule differs from the
-   attribute syntax of attributes for which this is the equality
-   matching rule.
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 34]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The rule evaluates to TRUE if and only if the assertion value matches
-   the first component of the attribute value using the rules of
-   caseIgnoreMatch.
-
-   The LDAP definition for the directoryStringFirstComponentMatch
-   matching rule is:
-
-      ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-   The directoryStringFirstComponentMatch rule is an equality matching
-   rule.  When using directoryStringFirstComponentMatch to compare two
-   attribute values (of an applicable syntax), an assertion value must
-   first be derived from one of the attribute values.  An assertion
-   value can be derived from an attribute value by taking the first
-   component of that attribute value.
-
-4.2.15.  distinguishedNameMatch
-
-   The distinguishedNameMatch rule compares an assertion value of the DN
-   syntax to an attribute value of a syntax (e.g., the DN syntax) whose
-   corresponding ASN.1 type is DistinguishedName.
-
-   The rule evaluates to TRUE if and only if the attribute value and the
-   assertion value have the same number of relative distinguished names
-   and corresponding relative distinguished names (by position) are the
-   same.  A relative distinguished name (RDN) of the assertion value is
-   the same as an RDN of the attribute value if and only if they have
-   the same number of attribute value assertions and each attribute
-   value assertion (AVA) of the first RDN is the same as the AVA of the
-   second RDN with the same attribute type.  The order of the AVAs is
-   not significant.  Also note that a particular attribute type may
-   appear in at most one AVA in an RDN.  Two AVAs with the same
-   attribute type are the same if their values are equal according to
-   the equality matching rule of the attribute type.  If one or more of
-   the AVA comparisons evaluate to Undefined and the remaining AVA
-   comparisons return TRUE then the distinguishedNameMatch rule
-   evaluates to Undefined.
-
-   The LDAP definition for the distinguishedNameMatch rule is:
-
-      ( 2.5.13.1 NAME 'distinguishedNameMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
-   The distinguishedNameMatch rule is an equality matching rule.
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 35]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-4.2.16.  generalizedTimeMatch
-
-   The generalizedTimeMatch rule compares an assertion value of the
-   Generalized Time syntax to an attribute value of a syntax (e.g., the
-   Generalized Time syntax) whose corresponding ASN.1 type is
-   GeneralizedTime.
-
-   The rule evaluates to TRUE if and only if the attribute value
-   represents the same universal coordinated time as the assertion
-   value.  If a time is specified with the minutes or seconds absent,
-   then the number of minutes or seconds (respectively) is assumed to be
-   zero.
-
-   The LDAP definition for the generalizedTimeMatch rule is:
-
-      ( 2.5.13.27 NAME 'generalizedTimeMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
-   The generalizedTimeMatch rule is an equality matching rule.
-
-4.2.17.  generalizedTimeOrderingMatch
-
-   The generalizedTimeOrderingMatch rule compares the time ordering of
-   an assertion value of the Generalized Time syntax to an attribute
-   value of a syntax (e.g., the Generalized Time syntax) whose
-   corresponding ASN.1 type is GeneralizedTime.
-
-   The rule evaluates to TRUE if and only if the attribute value
-   represents a universal coordinated time that is earlier than the
-   universal coordinated time represented by the assertion value.
-
-   The LDAP definition for the generalizedTimeOrderingMatch rule is:
-
-      ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
-
-   The generalizedTimeOrderingMatch rule is an ordering matching rule.
-
-4.2.18.  integerFirstComponentMatch
-
-   The integerFirstComponentMatch rule compares an assertion value of
-   the Integer syntax to an attribute value of a syntax (e.g., the DIT
-   Structure Rule Description syntax) whose corresponding ASN.1 type is
-   a SEQUENCE with a mandatory first component of the INTEGER ASN.1
-   type.
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 36]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   Note that the assertion syntax of this matching rule differs from the
-   attribute syntax of attributes for which this is the equality
-   matching rule.
-
-   The rule evaluates to TRUE if and only if the assertion value and the
-   first component of the attribute value are the same integer value.
-
-   The LDAP definition for the integerFirstComponentMatch matching rule
-   is:
-
-      ( 2.5.13.29 NAME 'integerFirstComponentMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
-   The integerFirstComponentMatch rule is an equality matching rule.
-   When using integerFirstComponentMatch to compare two attribute values
-   (of an applicable syntax), an assertion value must first be derived
-   from one of the attribute values.  An assertion value can be derived
-   from an attribute value by taking the first component of that
-   attribute value.
-
-4.2.19.  integerMatch
-
-   The integerMatch rule compares an assertion value of the Integer
-   syntax to an attribute value of a syntax (e.g., the Integer syntax)
-   whose corresponding ASN.1 type is INTEGER.
-
-   The rule evaluates to TRUE if and only if the attribute value and the
-   assertion value are the same integer value.
-
-   The LDAP definition for the integerMatch matching rule is:
-
-      ( 2.5.13.14 NAME 'integerMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
-   The integerMatch rule is an equality matching rule.
-
-4.2.20.  integerOrderingMatch
-
-   The integerOrderingMatch rule compares an assertion value of the
-   Integer syntax to an attribute value of a syntax (e.g., the Integer
-   syntax) whose corresponding ASN.1 type is INTEGER.
-
-   The rule evaluates to TRUE if and only if the integer value of the
-   attribute value is less than the integer value of the assertion
-   value.
-
-   The LDAP definition for the integerOrderingMatch matching rule is:
-
-
-
-
-Legg                        Standards Track                    [Page 37]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      ( 2.5.13.15 NAME 'integerOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
-
-   The integerOrderingMatch rule is an ordering matching rule.
-
-4.2.21.  keywordMatch
-
-   The keywordMatch rule compares an assertion value of the Directory
-   String syntax to an attribute value of a syntax (e.g., the Directory
-   String syntax) whose corresponding ASN.1 type is DirectoryString.
-
-   The rule evaluates to TRUE if and only if the assertion value
-   character string matches any keyword in the attribute value.  The
-   identification of keywords in the attribute value and the exactness
-   of the match are both implementation specific.
-
-   The LDAP definition for the keywordMatch rule is:
-
-      ( 2.5.13.33 NAME 'keywordMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-4.2.22.  numericStringMatch
-
-   The numericStringMatch rule compares an assertion value of the
-   Numeric String syntax to an attribute value of a syntax (e.g., the
-   Numeric String syntax) whose corresponding ASN.1 type is
-   NumericString.
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-   numericString Insignificant Character Handling is applied in the
-   Insignificant Character Handling step.
-
-   The LDAP definition for the numericStringMatch matching rule is:
-
-      ( 2.5.13.8 NAME 'numericStringMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
-   The numericStringMatch rule is an equality matching rule.
-
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 38]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-4.2.23.  numericStringOrderingMatch
-
-   The numericStringOrderingMatch rule compares an assertion value of
-   the Numeric String syntax to an attribute value of a syntax (e.g.,
-   the Numeric String syntax) whose corresponding ASN.1 type is
-   NumericString.
-
-   The rule evaluates to TRUE if and only if, in the code point
-   collation order, the prepared attribute value character string
-   appears earlier than the prepared assertion value character string;
-   i.e., the attribute value is "less than" the assertion value.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-   numericString Insignificant Character Handling is applied in the
-   Insignificant Character Handling step.
-
-   The rule is identical to the caseIgnoreOrderingMatch rule except that
-   all space characters are skipped during comparison (case is
-   irrelevant as the characters are numeric).
-
-   The LDAP definition for the numericStringOrderingMatch matching rule
-   is:
-
-      ( 2.5.13.9 NAME 'numericStringOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
-   The numericStringOrderingMatch rule is an ordering matching rule.
-
-4.2.24.  numericStringSubstringsMatch
-
-   The numericStringSubstringsMatch rule compares an assertion value of
-   the Substring Assertion syntax to an attribute value of a syntax
-   (e.g., the Numeric String syntax) whose corresponding ASN.1 type is
-   NumericString.
-
-   The rule evaluates to TRUE if and only if (1) the prepared substrings
-   of the assertion value match disjoint portions of the prepared
-   attribute value character string in the order of the substrings in
-   the assertion value, (2) an <initial> substring, if present, matches
-   the beginning of the prepared attribute value character string, and
-   (3) a <final> substring, if present, matches the end of the prepared
-   attribute value character string.  A prepared substring matches a
-   portion of the prepared attribute value character string if
-   corresponding characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are not case folded in the Map preparation step, and only
-
-
-
-Legg                        Standards Track                    [Page 39]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   numericString Insignificant Character Handling is applied in the
-   Insignificant Character Handling step.
-
-   The LDAP definition for the numericStringSubstringsMatch matching
-   rule is:
-
-      ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The numericStringSubstringsMatch rule is a substrings matching rule.
-
-4.2.25.  objectIdentifierFirstComponentMatch
-
-   The objectIdentifierFirstComponentMatch rule compares an assertion
-   value of the OID syntax to an attribute value of a syntax (e.g., the
-   Attribute Type Description, DIT Content Rule Description, LDAP Syntax
-   Description, Matching Rule Description, Matching Rule Use
-   Description, Name Form Description, or Object Class Description
-   syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
-   first component of the OBJECT IDENTIFIER ASN.1 type.
-
-   Note that the assertion syntax of this matching rule differs from the
-   attribute syntax of attributes for which this is the equality
-   matching rule.
-
-   The rule evaluates to TRUE if and only if the assertion value matches
-   the first component of the attribute value using the rules of
-   objectIdentifierMatch.
-
-   The LDAP definition for the objectIdentifierFirstComponentMatch
-   matching rule is:
-
-      ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-   The objectIdentifierFirstComponentMatch rule is an equality matching
-   rule.  When using objectIdentifierFirstComponentMatch to compare two
-   attribute values (of an applicable syntax), an assertion value must
-   first be derived from one of the attribute values.  An assertion
-   value can be derived from an attribute value by taking the first
-   component of that attribute value.
-
-4.2.26.  objectIdentifierMatch
-
-   The objectIdentifierMatch rule compares an assertion value of the OID
-   syntax to an attribute value of a syntax (e.g., the OID syntax) whose
-   corresponding ASN.1 type is OBJECT IDENTIFIER.
-
-
-
-
-Legg                        Standards Track                    [Page 40]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   The rule evaluates to TRUE if and only if the assertion value and the
-   attribute value represent the same object identifier; that is, the
-   same sequence of integers, whether represented explicitly in the
-   <numericoid> form of <oid> or implicitly in the <descr> form (see
-   [RFC4512]).
-
-   If an LDAP client supplies an assertion value in the <descr> form and
-   the chosen descriptor is not recognized by the server, then the
-   objectIdentifierMatch rule evaluates to Undefined.
-
-   The LDAP definition for the objectIdentifierMatch matching rule is:
-
-      ( 2.5.13.0 NAME 'objectIdentifierMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
-
-   The objectIdentifierMatch rule is an equality matching rule.
-
-4.2.27.  octetStringMatch
-
-   The octetStringMatch rule compares an assertion value of the Octet
-   String syntax to an attribute value of a syntax (e.g., the Octet
-   String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
-   STRING ASN.1 type.
-
-   The rule evaluates to TRUE if and only if the attribute value and the
-   assertion value are the same length and corresponding octets (by
-   position) are the same.
-
-   The LDAP definition for the octetStringMatch matching rule is:
-
-      ( 2.5.13.17 NAME 'octetStringMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
-   The octetStringMatch rule is an equality matching rule.
-
-4.2.28.  octetStringOrderingMatch
-
-   The octetStringOrderingMatch rule compares an assertion value of the
-   Octet String syntax to an attribute value of a syntax (e.g., the
-   Octet String or JPEG syntax) whose corresponding ASN.1 type is the
-   OCTET STRING ASN.1 type.
-
-   The rule evaluates to TRUE if and only if the attribute value appears
-   earlier in the collation order than the assertion value.  The rule
-   compares octet strings from the first octet to the last octet, and
-   from the most significant bit to the least significant bit within the
-   octet.  The first occurrence of a different bit determines the
-   ordering of the strings.  A zero bit precedes a one bit.  If the
-
-
-
-Legg                        Standards Track                    [Page 41]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   strings contain different numbers of octets but the longer string is
-   identical to the shorter string up to the length of the shorter
-   string, then the shorter string precedes the longer string.
-
-   The LDAP definition for the octetStringOrderingMatch matching rule
-   is:
-
-      ( 2.5.13.18 NAME 'octetStringOrderingMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
-   The octetStringOrderingMatch rule is an ordering matching rule.
-
-4.2.29.  telephoneNumberMatch
-
-   The telephoneNumberMatch rule compares an assertion value of the
-   Telephone Number syntax to an attribute value of a syntax (e.g., the
-   Telephone Number syntax) whose corresponding ASN.1 type is a
-   PrintableString representing a telephone number.
-
-   The rule evaluates to TRUE if and only if the prepared attribute
-   value character string and the prepared assertion value character
-   string have the same number of characters and corresponding
-   characters have the same code point.
-
-   In preparing the attribute value and assertion value for comparison,
-   characters are case folded in the Map preparation step, and only
-   telephoneNumber Insignificant Character Handling is applied in the
-   Insignificant Character Handling step.
-
-   The LDAP definition for the telephoneNumberMatch matching rule is:
-
-      ( 2.5.13.20 NAME 'telephoneNumberMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
-   The telephoneNumberMatch rule is an equality matching rule.
-
-4.2.30.  telephoneNumberSubstringsMatch
-
-   The telephoneNumberSubstringsMatch rule compares an assertion value
-   of the Substring Assertion syntax to an attribute value of a syntax
-   (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is
-   a PrintableString representing a telephone number.
-
-   The rule evaluates to TRUE if and only if (1) the prepared substrings
-   of the assertion value match disjoint portions of the prepared
-   attribute value character string in the order of the substrings in
-   the assertion value, (2) an <initial> substring, if present, matches
-   the beginning of the prepared attribute value character string, and
-
-
-
-Legg                        Standards Track                    [Page 42]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   (3) a <final> substring, if present, matches the end of the prepared
-   attribute value character string.  A prepared substring matches a
-   portion of the prepared attribute value character string if
-   corresponding characters have the same code point.
-
-   In preparing the attribute value and assertion value substrings for
-   comparison, characters are case folded in the Map preparation step,
-   and only telephoneNumber Insignificant Character Handling is applied
-   in the Insignificant Character Handling step.
-
-   The LDAP definition for the telephoneNumberSubstringsMatch matching
-   rule is:
-
-      ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
-
-   The telephoneNumberSubstringsMatch rule is a substrings matching
-   rule.
-
-4.2.31.  uniqueMemberMatch
-
-   The uniqueMemberMatch rule compares an assertion value of the Name
-   And Optional UID syntax to an attribute value of a syntax (e.g., the
-   Name And Optional UID syntax) whose corresponding ASN.1 type is
-   NameAndOptionalUID.
-
-   The rule evaluates to TRUE if and only if the <distinguishedName>
-   components of the assertion value and attribute value match according
-   to the distinguishedNameMatch rule and either, (1) the <BitString>
-   component is absent from both the attribute value and assertion
-   value, or (2) the <BitString> component is present in both the
-   attribute value and the assertion value and the <BitString> component
-   of the assertion value matches the <BitString> component of the
-   attribute value according to the bitStringMatch rule.
-
-   Note that this matching rule has been altered from its description in
-   X.520 [X.520] in order to make the matching rule commutative.  Server
-   implementors should consider using the original X.520 semantics
-   (where the matching was less exact) for approximate matching of
-   attributes with uniqueMemberMatch as the equality matching rule.
-
-   The LDAP definition for the uniqueMemberMatch matching rule is:
-
-      ( 2.5.13.23 NAME 'uniqueMemberMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
-   The uniqueMemberMatch rule is an equality matching rule.
-
-
-
-
-Legg                        Standards Track                    [Page 43]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-4.2.32.  wordMatch
-
-   The wordMatch rule compares an assertion value of the Directory
-   String syntax to an attribute value of a syntax (e.g., the Directory
-   String syntax) whose corresponding ASN.1 type is DirectoryString.
-
-   The rule evaluates to TRUE if and only if the assertion value word
-   matches, according to the semantics of caseIgnoreMatch, any word in
-   the attribute value.  The precise definition of a word is
-   implementation specific.
-
-   The LDAP definition for the wordMatch rule is:
-
-      ( 2.5.13.32 NAME 'wordMatch'
-         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
-5.  Security Considerations
-
-   In general, the LDAP-specific encodings for syntaxes defined in this
-   document do not define canonical encodings.  That is, a
-   transformation from an LDAP-specific encoding into some other
-   encoding (e.g., BER) and back into the LDAP-specific encoding will
-   not necessarily reproduce exactly the original octets of the LDAP-
-   specific encoding.  Therefore, an LDAP-specific encoding should not
-   be used where a canonical encoding is required.
-
-   Furthermore, the LDAP-specific encodings do not necessarily enable an
-   alternative encoding of values of the Directory String and DN
-   syntaxes to be reconstructed; e.g., a transformation from a
-   Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
-   encoding and back to a DER encoding may not reproduce the original
-   DER encoding.  Therefore, LDAP-specific encodings should not be used
-   where reversibility to DER is needed; e.g., for the verification of
-   digital signatures.  Instead, DER or a DER-reversible encoding should
-   be used.
-
-   When interpreting security-sensitive fields (in particular, fields
-   used to grant or deny access), implementations MUST ensure that any
-   matching rule comparisons are done on the underlying abstract value,
-   regardless of the particular encoding used.
-
-6.  Acknowledgements
-
-   This document is primarily a revision of RFC 2252 by M. Wahl, A.
-   Coulbeck, T. Howes, and S. Kille.  RFC 2252 was a product of the IETF
-   ASID Working Group.
-
-
-
-
-
-Legg                        Standards Track                    [Page 44]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   This document is based on input from the IETF LDAPBIS working group.
-   The author would like to thank Kathy Dally for editing the early
-   drafts of this document, and Jim Sermersheim and Kurt Zeilenga for
-   their significant contributions to this revision.
-
-7.  IANA Considerations
-
-   The Internet Assigned Numbers Authority (IANA) has updated the LDAP
-   descriptors registry [BCP64] as indicated by the following templates:
-
-      Subject: Request for LDAP Descriptor Registration Update
-      Descriptor (short name): see comment
-      Object Identifier: see comment
-      Person & email address to contact for further information:
-        Steven Legg <steven.legg at eb2bcom.com>
-      Usage: see comment
-      Specification: RFC 4517
-      Author/Change Controller: IESG
-
-      NAME                              Type  OID
-      ------------------------------------------------------------------
-      bitStringMatch                       M  2.5.13.16
-      booleanMatch                         M  2.5.13.13
-      caseExactIA5Match                    M  1.3.6.1.4.1.1466.109.114.1
-      caseExactMatch                       M  2.5.13.5
-      caseExactOrderingMatch               M  2.5.13.6
-      caseExactSubstringsMatch             M  2.5.13.7
-      caseIgnoreIA5Match                   M  1.3.6.1.4.1.1466.109.114.2
-      caseIgnoreListMatch                  M  2.5.13.11
-      caseIgnoreListSubstringsMatch        M  2.5.13.12
-      caseIgnoreMatch                      M  2.5.13.2
-      caseIgnoreOrderingMatch              M  2.5.13.3
-      caseIgnoreSubstringsMatch            M  2.5.13.4
-      directoryStringFirstComponentMatch   M  2.5.13.31
-      distinguishedNameMatch               M  2.5.13.1
-      generalizedTimeMatch                 M  2.5.13.27
-      generalizedTimeOrderingMatch         M  2.5.13.28
-      integerFirstComponentMatch           M  2.5.13.29
-      integerMatch                         M  2.5.13.14
-      integerOrderingMatch                 M  2.5.13.15
-      keywordMatch                         M  2.5.13.33
-      numericStringMatch                   M  2.5.13.8
-      numericStringOrderingMatch           M  2.5.13.9
-      numericStringSubstringsMatch         M  2.5.13.10
-      objectIdentifierFirstComponentMatch  M  2.5.13.30
-      octetStringMatch                     M  2.5.13.17
-      octetStringOrderingMatch             M  2.5.13.18
-      telephoneNumberMatch                 M  2.5.13.20
-
-
-
-Legg                        Standards Track                    [Page 45]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-      telephoneNumberSubstringsMatch       M  2.5.13.21
-      uniqueMemberMatch                    M  2.5.13.23
-      wordMatch                            M  2.5.13.32
-
-      The descriptor for the object identifier 2.5.13.0 was incorrectly
-      registered as objectIdentifiersMatch (extraneous \`s') in BCP 64.
-      It has been changed to the following, with a reference to
-      RFC 4517.
-
-      NAME                              Type  OID
-      ------------------------------------------------------------------
-      objectIdentifierMatch                M  2.5.13.0
-
-      Subject: Request for LDAP Descriptor Registration
-      Descriptor (short name): caseIgnoreIA5SubstringsMatch
-      Object Identifier: 1.3.6.1.4.1.1466.109.114.3
-      Person & email address to contact for further information:
-        Steven Legg <steven.legg at eb2bcom.com>
-      Usage: other (M)
-      Specification: RFC 4517
-      Author/Change Controller: IESG
-
-8.  References
-
-8.1.  Normative References
-
-   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
-              Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
-              10646", STD 63, RFC 3629, November 2003.
-
-   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
-              Specifications: ABNF", RFC 4234, October 2005.
-
-   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
-              (LDAP): Technical Specification Road Map", RFC 4510, June
-              2006.
-
-   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
-              Protocol (LDAP): The Protocol", RFC 4511, June 2006.
-
-   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Directory Information Models", RFC 4512, June
-              2006.
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 46]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
-              (LDAP): String Representation of Distinguished Names", RFC
-              4514, June 2006.
-
-   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP): Internationalized String Preparation", RFC 4518,
-              June 2006.
-
-   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
-              Considerations for the Lightweight Directory Access
-              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-   [E.123]    Notation for national and international telephone numbers,
-              ITU-T Recommendation E.123, 1988.
-
-   [FAX]      Standardization of Group 3 facsimile apparatus for
-              document transmission - Terminal Equipment and Protocols
-              for Telematic Services, ITU-T Recommendation T.4, 1993
-
-   [T.50]     International Reference Alphabet (IRA) (Formerly
-              International Alphabet No. 5 or IA5) Information
-              Technology - 7-Bit Coded Character Set for Information
-              Interchange, ITU-T Recommendation T.50, 1992
-
-   [X.420]    ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
-              Information Technology - Message Handling Systems (MHS):
-              Interpersonal messaging system
-
-   [X.501]    ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
-              Information Technology - Open Systems Interconnection -
-              The Directory: Models
-
-   [X.520]    ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
-              Information Technology - Open Systems Interconnection -
-              The Directory: Selected attribute types
-
-   [ASN.1]    ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
-              Information technology - Abstract Syntax Notation One
-              (ASN.1): Specification of basic notation
-
-   [ISO3166]  ISO 3166, "Codes for the representation of names of
-              countries".
-
-   [ISO8601]  ISO 8601:2004, "Data elements and interchange formats --
-              Information interchange -- Representation of dates and
-              times".
-
-
-
-
-
-Legg                        Standards Track                    [Page 47]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   [UCS]      Universal Multiple-Octet Coded Character Set (UCS) -
-              Architecture and Basic Multilingual Plane, ISO/IEC 10646-
-              1:  1993 (with amendments).
-
-   [JPEG]     JPEG File Interchange Format (Version 1.02).  Eric
-              Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
-              1992.
-
-8.2.  Informative References
-
-   [RFC4519]  Sciberras, A., Ed., "Lightweight Directory Access Protocol
-              (LDAP): Schema for User Applications", RFC 4519, June
-              2006.
-
-   [RFC4523]  Zeilenga, K., "Lightweight Directory Access Protocol
-              (LDAP) Schema Definitions for X.509 Certificates", RFC
-              4523, June 2006.
-
-   [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
-              Information Technology - Open Systems Interconnection -
-              The Directory: Overview of concepts, models and services
-
-   [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
-              Information technology - ASN.1 encoding rules:
-              Specification of Basic Encoding Rules (BER), Canonical
-              Encoding Rules (CER) and Distinguished Encoding Rules
-              (DER)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 48]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-Appendix A. Summary of Syntax Object Identifiers
-
-   The following list summarizes the object identifiers assigned to the
-   syntaxes defined in this document.
-
-      Syntax                           OBJECT IDENTIFIER
-      ==============================================================
-      Attribute Type Description       1.3.6.1.4.1.1466.115.121.1.3
-      Bit String                       1.3.6.1.4.1.1466.115.121.1.6
-      Boolean                          1.3.6.1.4.1.1466.115.121.1.7
-      Country String                   1.3.6.1.4.1.1466.115.121.1.11
-      Delivery Method                  1.3.6.1.4.1.1466.115.121.1.14
-      Directory String                 1.3.6.1.4.1.1466.115.121.1.15
-      DIT Content Rule Description     1.3.6.1.4.1.1466.115.121.1.16
-      DIT Structure Rule Description   1.3.6.1.4.1.1466.115.121.1.17
-      DN                               1.3.6.1.4.1.1466.115.121.1.12
-      Enhanced Guide                   1.3.6.1.4.1.1466.115.121.1.21
-      Facsimile Telephone Number       1.3.6.1.4.1.1466.115.121.1.22
-      Fax                              1.3.6.1.4.1.1466.115.121.1.23
-      Generalized Time                 1.3.6.1.4.1.1466.115.121.1.24
-      Guide                            1.3.6.1.4.1.1466.115.121.1.25
-      IA5 String                       1.3.6.1.4.1.1466.115.121.1.26
-      Integer                          1.3.6.1.4.1.1466.115.121.1.27
-      JPEG                             1.3.6.1.4.1.1466.115.121.1.28
-      LDAP Syntax Description          1.3.6.1.4.1.1466.115.121.1.54
-      Matching Rule Description        1.3.6.1.4.1.1466.115.121.1.30
-      Matching Rule Use Description    1.3.6.1.4.1.1466.115.121.1.31
-      Name And Optional UID            1.3.6.1.4.1.1466.115.121.1.34
-      Name Form Description            1.3.6.1.4.1.1466.115.121.1.35
-      Numeric String                   1.3.6.1.4.1.1466.115.121.1.36
-      Object Class Description         1.3.6.1.4.1.1466.115.121.1.37
-      Octet String                     1.3.6.1.4.1.1466.115.121.1.40
-      OID                              1.3.6.1.4.1.1466.115.121.1.38
-      Other Mailbox                    1.3.6.1.4.1.1466.115.121.1.39
-      Postal Address                   1.3.6.1.4.1.1466.115.121.1.41
-      Printable String                 1.3.6.1.4.1.1466.115.121.1.44
-      Substring Assertion              1.3.6.1.4.1.1466.115.121.1.58
-      Telephone Number                 1.3.6.1.4.1.1466.115.121.1.50
-      Teletex Terminal Identifier      1.3.6.1.4.1.1466.115.121.1.51
-      Telex Number                     1.3.6.1.4.1.1466.115.121.1.52
-      UTC Time                         1.3.6.1.4.1.1466.115.121.1.53
-
-Appendix B. Changes from RFC 2252
-
-   This annex lists the significant differences between this
-   specification and RFC 2252.
-
-
-
-
-
-Legg                        Standards Track                    [Page 49]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   This annex is provided for informational purposes only.  It is not a
-   normative part of this specification.
-
-   1.  The IESG Note has been removed.
-
-   2.  The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
-       and revised.  Changes to the parts of these sections moved to
-       [RFC4512] are detailed in [RFC4512].
-
-   3.  BNF descriptions of syntax formats have been replaced by ABNF
-       [RFC4234] specifications.
-
-   4.  The ambiguous statement in RFC 2252, Section 4.3 regarding the
-       use of a backslash quoting mechanism to escape separator symbols
-       has been removed.  The escaping mechanism is now explicitly
-       represented in the ABNF for the syntaxes where this provision
-       applies.
-
-   5.  The description of each of the LDAP syntaxes has been expanded so
-       that they are less dependent on knowledge of X.500 for
-       interpretation.
-
-   6.  The relationship of LDAP syntaxes to corresponding ASN.1 type
-       definitions has been made explicit.
-
-   7.  The set of characters allowed in a <PrintableString> (formerly
-       <printablestring>) has been corrected to align with the
-       PrintableString ASN.1 type in [ASN.1].  Specifically, the double
-       quote character has been removed and the single quote character
-       and equals sign have been added.
-
-   8.  Values of the Directory String, Printable String and Telephone
-       Number syntaxes are now required to have at least one character.
-
-   9.  The <DITContentRuleDescription>, <NameFormDescription> and
-       <DITStructureRuleDescription> rules have been moved to [RFC4512].
-
-   10. The corresponding ASN.1 type for the Other Mailbox syntax has
-       been incorporated from RFC 1274.
-
-   11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
-       has been invented.
-
-   12. The Binary syntax has been removed because it was not adequately
-       specified, implementations with different incompatible
-       interpretations exist, and it was confused with the ;binary
-       transfer encoding.
-
-
-
-
-Legg                        Standards Track                    [Page 50]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-   13. All discussion of transfer options, including the ";binary"
-       option, has been removed.  All imperatives regarding binary
-       transfer of values have been removed.
-
-   14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
-       Terminal Identifier and Telex Number syntaxes from RFC 2256 have
-       been incorporated.
-
-   15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
-       been extended to accommodate empty "and" and "or" expressions.
-
-   16. An encoding for the <ttx-value> rule in the Teletex Terminal
-       Identifier syntax has been defined.
-
-   17. The PKI-related syntaxes (Certificate, Certificate List and
-       Certificate Pair) have been removed.  They are reintroduced in
-       [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
-
-   18. The MHS OR Address syntax has been removed since its
-       specification (in RFC 2156) is not at draft standard maturity.
-
-   19. The DL Submit Permission syntax has been removed as it depends on
-       the MHS OR Address syntax.
-
-   20. The Presentation Address syntax has been removed since its
-       specification (in RFC 1278) is not at draft standard maturity.
-
-   21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
-       Type, LDAP Schema Description, Master And Shadow Access Points,
-       Modify Rights, Protocol Information, Subtree Specification,
-       Supplier Information, Supplier Or Consumer and Supplier And
-       Consumer syntaxes have been removed.  These syntaxes are
-       referenced in RFC 2252, but not defined.
-
-   22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
-       Mail Preference syntax have been removed on the grounds that they
-       are out of scope for the core specification.
-
-   23. The description of each of the matching rules has been expanded
-       so that they are less dependent on knowledge of X.500 for
-       interpretation.
-
-   24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
-       been added.
-
-   25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
-       caseIgnoreSubstringsMatch matching rules have been added to the
-       list of matching rules for which the provisions for handling
-
-
-
-Legg                        Standards Track                    [Page 51]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006
-
-
-       leading, trailing and multiple adjoining whitespace characters
-       apply (now through string preparation).  This is consistent with
-       the definitions of these matching rules in X.500.  The
-       caseIgnoreIA5SubstringsMatch rule has also been added to the
-       list.
-
-   26. The specification of the octetStringMatch matching rule from
-       RFC 2256 has been added to this document.
-
-   27. The presentationAddressMatch matching rule has been removed as it
-       depends on an assertion syntax (Presentation Address) that is not
-       at draft standard maturity.
-
-   28. The protocolInformationMatch matching rule has been removed as it
-       depends on an undefined assertion syntax (Protocol Information).
-
-   29. The definitive reference for ASN.1 has been changed from X.208 to
-       X.680 since X.680 is the version of ASN.1 referred to by X.500.
-
-   30. The specification of the caseIgnoreListSubstringsMatch matching
-       rule from RFC 2798 & X.520 has been added.
-
-   31. String preparation algorithms have been applied to the character
-       string matching rules.
-
-   32. The specifications of the booleanMatch, caseExactMatch,
-       caseExactOrderingMatch, caseExactSubstringsMatch,
-       directoryStringFirstComponentMatch, integerOrderingMatch,
-       keywordMatch, numericStringOrderingMatch,
-       octetStringOrderingMatch and wordMatch matching rules from
-       RFC 3698 & X.520 have been added.
-
-Author's Address
-
-   Steven Legg
-   eB2Bcom
-   Suite3, Woodhouse Corporate Centre
-   935 Station Street
-   Box Hill North, Victoria 3129
-   AUSTRALIA
-
-   Phone: +61 3 9896 7830
-   Fax: +61 3 9896 7801
-   EMail: steven.legg at eb2bcom.com
-
-
-
-
-
-
-
-Legg                        Standards Track                    [Page 52]
-
-RFC 4517           LDAP: Syntaxes and Matching Rules           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 R