[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 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).
-
-
-
-
-
-
-
-Legg Standards Track [Page 53]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4518.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4518.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/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/rfc4519.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4519.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4519.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-Network Working Group A. Sciberras, Ed.
-Request for Comments: 4519 eB2Bcom
-Obsoletes: 2256 June 2006
-Updates: 2247, 2798, 2377
-Category: Standards Track
-
-
- Lightweight Directory Access Protocol (LDAP):
- Schema for User Applications
-
-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 is an integral part of the Lightweight Directory Access
- Protocol (LDAP) technical specification. It provides a technical
- specification of attribute types and object classes intended for use
- by LDAP directory clients for many directory services, such as White
- Pages. These objects are widely used as a basis for the schema in
- many LDAP directories. This document does not cover attributes used
- for the administration of directory servers, nor does it include
- directory objects defined for specific uses in other documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 1]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Relationship with Other Specifications .....................3
- 1.2. Conventions ................................................4
- 1.3. General Issues .............................................4
- 2. Attribute Types .................................................4
- 2.1. 'businessCategory' .........................................5
- 2.2. 'c' ........................................................5
- 2.3. 'cn' .......................................................5
- 2.4. 'dc' .......................................................6
- 2.5. 'description' ..............................................6
- 2.6. 'destinationIndicator' .....................................7
- 2.7. 'distinguishedName' ........................................7
- 2.8. 'dnQualifier' ..............................................8
- 2.9. 'enhancedSearchGuide' ......................................8
- 2.10. 'facsimileTelephoneNumber' ................................9
- 2.11. 'generationQualifier' .....................................9
- 2.12. 'givenName' ...............................................9
- 2.13. 'houseIdentifier' .........................................9
- 2.14. 'initials' ...............................................10
- 2.15. 'internationalISDNNumber' ................................10
- 2.16. 'l' ......................................................10
- 2.17. 'member' .................................................11
- 2.18. 'name' ...................................................11
- 2.19. 'o' ......................................................11
- 2.20. 'ou' .....................................................12
- 2.21. 'owner' ..................................................12
- 2.22. 'physicalDeliveryOfficeName' .............................12
- 2.23. 'postalAddress' ..........................................13
- 2.24. 'postalCode' .............................................13
- 2.25. 'postOfficeBox' ..........................................14
- 2.26. 'preferredDeliveryMethod' ................................14
- 2.27. 'registeredAddress' ......................................14
- 2.28. 'roleOccupant' ...........................................15
- 2.29. 'searchGuide' ............................................15
- 2.30. 'seeAlso' ................................................15
- 2.31. 'serialNumber' ...........................................16
- 2.32. 'sn' .....................................................16
- 2.33. 'st' .....................................................16
- 2.34. 'street' .................................................17
- 2.35. 'telephoneNumber' ........................................17
- 2.36. 'teletexTerminalIdentifier' ..............................17
- 2.37. 'telexNumber' ............................................18
- 2.38. 'title' ..................................................18
- 2.39. 'uid' ....................................................18
- 2.40. 'uniqueMember' ...........................................19
- 2.41. 'userPassword' ...........................................19
-
-
-
-Sciberras Standards Track [Page 2]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- 2.42. 'x121Address' ............................................20
- 2.43. 'x500UniqueIdentifier' ...................................20
- 3. Object Classes .................................................20
- 3.1. 'applicationProcess' ......................................21
- 3.2. 'country' .................................................21
- 3.3. 'dcObject' ................................................21
- 3.4. 'device' ..................................................21
- 3.5. 'groupOfNames' ............................................22
- 3.6. 'groupOfUniqueNames' ......................................22
- 3.7. 'locality' ................................................23
- 3.8. 'organization' ............................................23
- 3.9. 'organizationalPerson' ....................................24
- 3.10. 'organizationalRole' .....................................24
- 3.11. 'organizationalUnit' .....................................24
- 3.12. 'person' .................................................25
- 3.13. 'residentialPerson' ......................................25
- 3.14. 'uidObject' ..............................................26
- 4. IANA Considerations ............................................26
- 5. Security Considerations ........................................28
- 6. Acknowledgements ...............................................28
- 7. References .....................................................29
- 7.1. Normative References ......................................29
- 7.2. Informative References ....................................30
- Appendix A Changes Made Since RFC 2256 ...........................32
-
-1. Introduction
-
- This document provides an overview of attribute types and object
- classes intended for use by Lightweight Directory Access Protocol
- (LDAP) directory clients for many directory services, such as White
- Pages. Originally specified in the X.500 [X.500] documents, these
- objects are widely used as a basis for the schema in many LDAP
- directories. This document does not cover attributes used for the
- administration of directory servers, nor does it include directory
- objects defined for specific uses in other documents.
-
-1.1. Relationship with Other 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. In terms of RFC 2256,
- Sections 6 and 8 of RFC 2256 are obsoleted by [RFC4517]. Sections
- 5.1, 5.2, 7.1, and 7.2 of RFC 2256 are obsoleted by [RFC4512]. The
- remainder of RFC 2256 is obsoleted by this document. The technical
- specification for the 'dc' attribute type and 'dcObject' object class
- found in RFC 2247 are superseded by sections 2.4 and 3.3 of this
- document. The remainder of RFC 2247 remains in force.
-
-
-
-
-Sciberras Standards Track [Page 3]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- This document updates RFC 2798 by replacing the informative
- description of the 'uid' attribute type with the definitive
- description provided in Section 2.39 of this document.
-
- This document updates RFC 2377 by replacing the informative
- description of the 'uidObject' object class with the definitive
- description provided in Section 3.14 of 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. PKI-related schema elements are now specified in
- [RFC4523]. Unless reintroduced in future technical specifications,
- the remainder are to be considered Historic.
-
- The descriptions in this document SHALL be considered definitive for
- use in LDAP.
-
-1.2. 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 RFC 2119 [RFC2119].
-
-1.3. General Issues
-
- This document references Syntaxes defined in Section 3 of [RFC4517]
- and Matching Rules defined in Section 4 of [RFC4517].
-
- The definitions of Attribute Types and Object Classes are written
- using the Augmented Backus-Naur Form (ABNF) [RFC4234] of
- AttributeTypeDescription and ObjectClassDescription given in
- [RFC4512]. Lines have been folded for readability. When such values
- are transferred as attribute values in the LDAP Protocol, the values
- will not contain line breaks.
-
-2. Attribute Types
-
- The attribute types contained in this section hold user information.
-
- There is no requirement that servers implement the 'searchGuide' and
- 'teletexTerminalIdentifier' attribute types. In fact, their use is
- greatly discouraged.
-
- An LDAP server implementation SHOULD recognize the rest of the
- attribute types described in this section.
-
-
-
-
-
-
-Sciberras Standards Track [Page 4]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.1. 'businessCategory'
-
- The 'businessCategory' attribute type describes the kinds of business
- performed by an organization. Each kind is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.15 NAME 'businessCategory'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Examples: "banking", "transportation", and "real estate".
-
-2.2. 'c'
-
- The 'c' ('countryName' in X.500) attribute type contains a two-letter
- ISO 3166 [ISO3166] country code.
- (Source: X.520 [X.520])
-
- ( 2.5.4.6 NAME 'c'
- SUP name
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.11
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.11 refers to the Country String syntax
- [RFC4517].
-
- Examples: "DE", "AU" and "FR".
-
-2.3. 'cn'
-
- The 'cn' ('commonName' in X.500) attribute type contains names of an
- object. Each name is one value of this multi-valued attribute. If
- the object corresponds to a person, it is typically the person's full
- name.
- (Source: X.520 [X.520])
-
- ( 2.5.4.3 NAME 'cn'
- SUP name )
-
- Examples: "Martin K Smith", "Marty Smith" and "printer12".
-
-
-
-
-
-
-Sciberras Standards Track [Page 5]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.4. 'dc'
-
- The 'dc' ('domainComponent' in RFC 1274) attribute type is a string
- holding one component, a label, of a DNS domain name
- [RFC1034][RFC2181] naming a host [RFC1123]. That is, a value of this
- attribute is a string of ASCII characters adhering to the following
- ABNF [RFC4234]:
-
- label = (ALPHA / DIGIT) [*61(ALPHA / DIGIT / HYPHEN) (ALPHA / DIGIT)]
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- DIGIT = %x30-39 ; "0"-"9"
- HYPHEN = %x2D ; hyphen ("-")
-
- The encoding of IA5String for use in LDAP is simply the characters of
- the ASCII label. The equality matching rule is case insensitive, as
- is today's DNS. (Source: RFC 2247 [RFC2247] and RFC 1274 [RFC 1274])
-
- ( 0.9.2342.19200300.100.1.25 NAME 'dc'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.26 refers to the IA5 String syntax
- [RFC4517].
-
- Examples: Valid values include "example" and "com" but not
- "example.com". The latter is invalid as it contains multiple domain
- components.
-
- It is noted that the directory service will not ensure that values of
- this attribute conform to the host label restrictions [RFC1123]
- illustrated by the <label> production provided above. It is the
- directory client's responsibility to ensure that the labels it stores
- in this attribute are appropriately restricted.
-
- Directory applications supporting International Domain Names SHALL
- use the ToASCII method [RFC3490] to produce the domain component
- label. The special considerations discussed in Section 4 of RFC 3490
- [RFC3490] should be taken, depending on whether the domain component
- is used for "stored" or "query" purposes.
-
-2.5. 'description'
-
- The 'description' attribute type contains human-readable descriptive
- phrases about the object. Each description is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
-
-
-Sciberras Standards Track [Page 6]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.4.13 NAME 'description'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Examples: "a color printer", "Maintenance is done every Monday, at
- 1pm.", and "distribution list for all technical staff".
-
-2.6. 'destinationIndicator'
-
- The 'destinationIndicator' attribute type contains country and city
- strings associated with the object (the addressee) needed to provide
- the Public Telegram Service. The strings are composed in accordance
- with CCITT Recommendations F.1 [F.1] and F.31 [F.31]. Each string is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.27 NAME 'destinationIndicator'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [RFC4517].
-
- Examples: "AASD" as a destination indicator for Sydney, Australia.
- "GBLD" as a destination indicator for London, United
- Kingdom.
-
- It is noted that the directory will not ensure that values of this
- attribute conform to the F.1 and F.31 CCITT Recommendations. It is
- the application's responsibility to ensure destination indicators
- that it stores in this attribute are appropriately constructed.
-
-2.7. 'distinguishedName'
-
- The 'distinguishedName' attribute type is not used as the name of the
- object itself, but it is instead a base type from which some user
- attribute types with a DN syntax can inherit.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations that do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
-
-
-
-Sciberras Standards Track [Page 7]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- (Source: X.520 [X.520])
-
- ( 2.5.4.49 NAME 'distinguishedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- 1.3.6.1.4.1.1466.115.121.1.12 refers to the DN syntax [RFC4517].
-
-2.8. 'dnQualifier'
-
- The 'dnQualifier' attribute type contains disambiguating information
- strings to add to the relative distinguished name of an entry. The
- information is intended for use when merging data from multiple
- sources in order to prevent conflicts between entries that would
- otherwise have the same name. Each string is one value of this
- multi-valued attribute. It is recommended that a value of the
- 'dnQualifier' attribute be the same for all entries from a particular
- source.
- (Source: X.520 [X.520])
-
- ( 2.5.4.46 NAME 'dnQualifier'
- EQUALITY caseIgnoreMatch
- ORDERING caseIgnoreOrderingMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [RFC4517].
-
- Examples: "20050322123345Z" - timestamps can be used to disambiguate
- information.
- "123456A" - serial numbers can be used to disambiguate
- information.
-
-2.9. 'enhancedSearchGuide'
-
- The 'enhancedSearchGuide' attribute type contains sets of information
- for use by directory clients in constructing search filters. Each
- set is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.47 NAME 'enhancedSearchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.21 )
-
- 1.3.6.1.4.1.1466.115.121.1.21 refers to the Enhanced Guide syntax
- [RFC4517].
-
-
-
-
-
-Sciberras Standards Track [Page 8]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- Examples: "person#(sn$APPROX)#wholeSubtree" and
- "organizationalUnit#(ou$SUBSTR)#oneLevel".
-
-2.10. 'facsimileTelephoneNumber'
-
- The 'facsimileTelephoneNumber' attribute type contains telephone
- numbers (and, optionally, the parameters) for facsimile terminals.
- Each telephone number is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.23 NAME 'facsimileTelephoneNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.22 )
-
- 1.3.6.1.4.1.1466.115.121.1.22 refers to the Facsimile Telephone
- Number syntax [RFC4517].
-
- Examples: "+61 3 9896 7801" and "+81 3 347 7418$fineResolution".
-
-2.11. 'generationQualifier'
-
- The 'generationQualifier' attribute type contains name strings that
- are typically the suffix part of a person's name. Each string is one
- value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.44 NAME 'generationQualifier'
- SUP name )
-
- Examples: "III", "3rd", and "Jr.".
-
-2.12. 'givenName'
-
- The 'givenName' attribute type contains name strings that are the
- part of a person's name that is not their surname. Each string is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.42 NAME 'givenName'
- SUP name )
-
- Examples: "Andrew", "Charles", and "Joanne".
-
-2.13. 'houseIdentifier'
-
- The 'houseIdentifier' attribute type contains identifiers for a
- building within a location. Each identifier is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
-
-
-Sciberras Standards Track [Page 9]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.4.51 NAME 'houseIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Example: "20" to represent the house number 20.
-
-2.14. 'initials'
-
- The 'initials' attribute type contains strings of initials of some or
- all of an individual's names, except the surname(s). Each string is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.43 NAME 'initials'
- SUP name )
-
- Examples: "K. A." and "K".
-
-2.15. 'internationalISDNNumber'
-
- The 'internationalISDNNumber' attribute type contains Integrated
- Services Digital Network (ISDN) addresses, as defined in the
- International Telecommunication Union (ITU) Recommendation E.164
- [E.164]. Each address is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.25 NAME 'internationalISDNNumber'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [RFC4517].
-
- Example: "0198 333 333".
-
-2.16. 'l'
-
- The 'l' ('localityName' in X.500) attribute type contains names of a
- locality or place, such as a city, county, or other geographic
- region. Each name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
-
-
-
-
-Sciberras Standards Track [Page 10]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.4.7 NAME 'l'
- SUP name )
-
- Examples: "Geneva", "Paris", and "Edinburgh".
-
-2.17. 'member'
-
- The 'member' attribute type contains the distinguished names of
- objects that are on a list or in a group. Each name is one value of
- this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.31 NAME 'member'
- SUP distinguishedName )
-
- Examples: "cn=James Clarke,ou=Finance,o=Widget\, Inc." and
- "cn=John Xerri,ou=Finance,o=Widget\, Inc." may
- be two members of the financial team (group) at Widget,
- Inc., in which case, both of these distinguished names
- would be present as individual values of the member
- attribute.
-
-2.18. 'name'
-
- The 'name' attribute type is the attribute supertype from which user
- attribute types with the name syntax inherit. Such attribute types
- are typically used for naming. The attribute type is multi-valued.
-
- It is unlikely that values of this type itself will occur in an
- entry. LDAP server implementations that do not support attribute
- subtyping need not recognize this attribute in requests. Client
- implementations MUST NOT assume that LDAP servers are capable of
- performing attribute subtyping.
- (Source: X.520 [X.520])
-
- ( 2.5.4.41 NAME 'name'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
-2.19. 'o'
-
- The 'o' ('organizationName' in X.500) attribute type contains the
- names of an organization. Each name is one value of this
- multi-valued attribute.
-
-
-
-Sciberras Standards Track [Page 11]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- (Source: X.520 [X.520])
-
- ( 2.5.4.10 NAME 'o'
- SUP name )
-
- Examples: "Widget", "Widget, Inc.", and "Widget, Incorporated.".
-
-2.20. 'ou'
-
- The 'ou' ('organizationalUnitName' in X.500) attribute type contains
- the names of an organizational unit. Each name is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.11 NAME 'ou'
- SUP name )
-
- Examples: "Finance", "Human Resources", and "Research and
- Development".
-
-2.21. 'owner'
-
- The 'owner' attribute type contains the distinguished names of
- objects that have an ownership responsibility for the object that is
- owned. Each owner's name is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.32 NAME 'owner'
- SUP distinguishedName )
-
- Example: The mailing list object, whose DN is "cn=All Employees,
- ou=Mailing List,o=Widget\, Inc.", is owned by the Human
- Resources Director.
-
- Therefore, the value of the 'owner' attribute within the
- mailing list object, would be the DN of the director (role):
- "cn=Human Resources Director,ou=employee,o=Widget\, Inc.".
-
-2.22. 'physicalDeliveryOfficeName'
-
- The 'physicalDeliveryOfficeName' attribute type contains names that a
- Postal Service uses to identify a post office.
- (Source: X.520 [X.520])
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 12]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.4.19 NAME 'physicalDeliveryOfficeName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Examples: "Bremerhaven, Main" and "Bremerhaven, Bonnstrasse".
-
-2.23. 'postalAddress'
-
- The 'postalAddress' attribute type contains addresses used by a
- Postal Service to perform services for the object. Each address is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.16 NAME 'postalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [RFC4517].
-
- Example: "15 Main St.$Ottawa$Canada".
-
-2.24. 'postalCode'
-
- The 'postalCode' attribute type contains codes used by a Postal
- Service to identify postal service zones. Each code is one value of
- this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.17 NAME 'postalCode'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Example: "22180", to identify Vienna, VA, in the USA.
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 13]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.25. 'postOfficeBox'
-
- The 'postOfficeBox' attribute type contains postal box identifiers
- that a Postal Service uses when a customer arranges to receive mail
- at a box on the premises of the Postal Service. Each postal box
- identifier is a single value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.18 NAME 'postOfficeBox'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Example: "Box 45".
-
-2.26. 'preferredDeliveryMethod'
-
- The 'preferredDeliveryMethod' attribute type contains an indication
- of the preferred method of getting a message to the object.
- (Source: X.520 [X.520])
-
- ( 2.5.4.28 NAME 'preferredDeliveryMethod'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.14
- SINGLE-VALUE )
-
- 1.3.6.1.4.1.1466.115.121.1.14 refers to the Delivery Method syntax
- [RFC4517].
-
- Example: If the mhs-delivery Delivery Method is preferred over
- telephone-delivery, which is preferred over all other
- methods, the value would be: "mhs $ telephone".
-
-2.27. 'registeredAddress'
-
- The 'registeredAddress' attribute type contains postal addresses
- suitable for reception of telegrams or expedited documents, where it
- is necessary to have the recipient accept delivery. Each address is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.26 NAME 'registeredAddress'
- SUP postalAddress
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
-
-
-
-
-Sciberras Standards Track [Page 14]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- 1.3.6.1.4.1.1466.115.121.1.41 refers to the Postal Address syntax
- [RFC4517].
-
- Example: "Receptionist$Widget, Inc.$15 Main St.$Ottawa$Canada".
-
-2.28. 'roleOccupant'
-
- The 'roleOccupant' attribute type contains the distinguished names of
- objects (normally people) that fulfill the responsibilities of a role
- object. Each distinguished name is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.33 NAME 'roleOccupant'
- SUP distinguishedName )
-
- Example: The role object, "cn=Human Resources
- Director,ou=Position,o=Widget\, Inc.", is fulfilled by two
- people whose object names are "cn=Mary
- Smith,ou=employee,o=Widget\, Inc." and "cn=James
- Brown,ou=employee,o=Widget\, Inc.". The 'roleOccupant'
- attribute will contain both of these distinguished names,
- since they are the occupants of this role.
-
-2.29. 'searchGuide'
-
- The 'searchGuide' attribute type contains sets of information for use
- by clients in constructing search filters. It is superseded by
- 'enhancedSearchGuide', described above in Section 2.9. Each set is
- one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.14 NAME 'searchGuide'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.25 )
-
- 1.3.6.1.4.1.1466.115.121.1.25 refers to the Guide syntax [RFC4517].
-
- Example: "person#sn$EQ".
-
-2.30. 'seeAlso'
-
- The 'seeAlso' attribute type contains the distinguished names of
- objects that are related to the subject object. Each related object
- name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.34 NAME 'seeAlso'
- SUP distinguishedName )
-
-
-
-Sciberras Standards Track [Page 15]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- Example: The person object "cn=James Brown,ou=employee,o=Widget\,
- Inc." is related to the role objects "cn=Football Team
- Captain,ou=sponsored activities,o=Widget\, Inc." and
- "cn=Chess Team,ou=sponsored activities,o=Widget\, Inc.".
- Since the role objects are related to the person object, the
- 'seeAlso' attribute will contain the distinguished name of
- each role object as separate values.
-
-2.31. 'serialNumber'
-
- The 'serialNumber' attribute type contains the serial numbers of
- devices. Each serial number is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.5 NAME 'serialNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
-
- 1.3.6.1.4.1.1466.115.121.1.44 refers to the Printable String syntax
- [RFC4517].
-
- Examples: "WI-3005" and "XF551426".
-
-2.32. 'sn'
-
- The 'sn' ('surname' in X.500) attribute type contains name strings
- for the family names of a person. Each string is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.4 NAME 'sn'
- SUP name )
-
- Example: "Smith".
-
-2.33. 'st'
-
- The 'st' ('stateOrProvinceName' in X.500) attribute type contains the
- full names of states or provinces. Each name is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.8 NAME 'st'
- SUP name )
-
- Example: "California".
-
-
-
-Sciberras Standards Track [Page 16]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.34. 'street'
-
- The 'street' ('streetAddress' in X.500) attribute type contains site
- information from a postal address (i.e., the street name, place,
- avenue, and the house number). Each street is one value of this
- multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.9 NAME 'street'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Example: "15 Main St.".
-
-2.35. 'telephoneNumber'
-
- The 'telephoneNumber' attribute type contains telephone numbers that
- comply with the ITU Recommendation E.123 [E.123]. Each number is one
- value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.20 NAME 'telephoneNumber'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- 1.3.6.1.4.1.1466.115.121.1.50 refers to the Telephone Number syntax
- [RFC4517].
-
- Example: "+1 234 567 8901".
-
-2.36. 'teletexTerminalIdentifier'
-
- The withdrawal of Recommendation F.200 has resulted in the withdrawal
- of this attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.22 NAME 'teletexTerminalIdentifier'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.51 )
-
- 1.3.6.1.4.1.1466.115.121.1.51 refers to the Teletex Terminal
- Identifier syntax [RFC4517].
-
-
-
-
-
-Sciberras Standards Track [Page 17]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.37. 'telexNumber'
-
- The 'telexNumber' attribute type contains sets of strings that are a
- telex number, country code, and answerback code of a telex terminal.
- Each set is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.21 NAME 'telexNumber'
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.52 )
-
- 1.3.6.1.4.1.1466.115.121.1.52 refers to the Telex Number syntax
- [RFC4517].
-
- Example: "12345$023$ABCDE".
-
-2.38. 'title'
-
- The 'title' attribute type contains the title of a person in their
- organizational context. Each title is one value of this multi-valued
- attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.12 NAME 'title'
- SUP name )
- Examples: "Vice President", "Software Engineer", and "CEO".
-
-2.39. 'uid'
-
- The 'uid' ('userid' in RFC 1274) attribute type contains computer
- system login names associated with the object. Each name is one
- value of this multi-valued attribute.
- (Source: RFC 2798 [RFC2798] and RFC 1274 [RFC1274])
-
- ( 0.9.2342.19200300.100.1.1 NAME 'uid'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- 1.3.6.1.4.1.1466.115.121.1.15 refers to the Directory String syntax
- [RFC4517].
-
- Examples: "s9709015", "admin", and "Administrator".
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 18]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-2.40. 'uniqueMember'
-
- The 'uniqueMember' attribute type contains the distinguished names of
- an object that is on a list or in a group, where the relative
- distinguished names of the object include a value that distinguishes
- between objects when a distinguished name has been reused. Each
- distinguished name is one value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.50 NAME 'uniqueMember'
- EQUALITY uniqueMemberMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
-
- 1.3.6.1.4.1.1466.115.121.1.34 refers to the Name and Optional UID
- syntax [RFC4517].
-
- Example: If "ou=1st Battalion,o=Defense,c=US" is a battalion that was
- disbanded, establishing a new battalion with the "same" name
- would have a unique identifier value added, resulting in
- "ou=1st Battalion, o=Defense,c=US#'010101'B".
-
-2.41. 'userPassword'
-
- The 'userPassword' attribute contains octet strings that are known
- only to the user and the system to which the user has access. Each
- string is one value of this multi-valued attribute.
-
- The application SHOULD prepare textual strings used as passwords by
- transcoding them to Unicode, applying SASLprep [RFC4013], and
- encoding as UTF-8. The determination of whether a password is
- textual is a local client matter.
- (Source: X.509 [X.509])
-
- ( 2.5.4.35 NAME 'userPassword'
- EQUALITY octetStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
-
- 1.3.6.1.4.1.1466.115.121.1.40 refers to the Octet String syntax
- [RFC4517].
-
- Passwords are stored using an Octet String syntax and are not
- encrypted. Transfer of cleartext passwords is strongly discouraged
- where the underlying transport service cannot guarantee
- confidentiality and may result in disclosure of the password to
- unauthorized parties.
-
- An example of a need for multiple values in the 'userPassword'
- attribute is an environment where every month the user is expected to
-
-
-
-Sciberras Standards Track [Page 19]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- use a different password generated by some automated system. During
- transitional periods, like the last and first day of the periods, it
- may be necessary to allow two passwords for the two consecutive
- periods to be valid in the system.
-
-2.42. 'x121Address'
-
- The 'x121Address' attribute type contains data network addresses as
- defined by ITU Recommendation X.121 [X.121]. Each address is one
- value of this multi-valued attribute.
- (Source: X.520 [X.520])
-
- ( 2.5.4.24 NAME 'x121Address'
- EQUALITY numericStringMatch
- SUBSTR numericStringSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
-
- 1.3.6.1.4.1.1466.115.121.1.36 refers to the Numeric String syntax
- [RFC4517].
-
- Example: "36111222333444555".
-
-2.43. 'x500UniqueIdentifier'
-
- The 'x500UniqueIdentifier' attribute type contains binary strings
- that are used to distinguish between objects when a distinguished
- name has been reused. Each string is one value of this multi-valued
- attribute.
-
- In X.520 [X.520], this attribute type is called 'uniqueIdentifier'.
- This is a different attribute type from both the 'uid' and
- 'uniqueIdentifier' LDAP attribute types. The 'uniqueIdentifier'
- attribute type is defined in [RFC4524].
- (Source: X.520 [X.520])
-
- ( 2.5.4.45 NAME 'x500UniqueIdentifier'
- EQUALITY bitStringMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
-
- 1.3.6.1.4.1.1466.115.121.1.6 refers to the Bit String syntax
- [RFC4517].
-
-3. Object Classes
-
- LDAP servers SHOULD recognize all the Object Classes listed here as
- values of the 'objectClass' attribute (see [RFC4512]).
-
-
-
-
-
-Sciberras Standards Track [Page 20]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-3.1. 'applicationProcess'
-
- The 'applicationProcess' object class definition is the basis of an
- entry that represents an application executing in a computer system.
- (Source: X.521 [X.521])
-
- ( 2.5.6.11 NAME 'applicationProcess'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( seeAlso $
- ou $
- l $
- description ) )
-
-3.2. 'country'
-
- The 'country' object class definition is the basis of an entry that
- represents a country.
- (Source: X.521 [X.521])
-
- ( 2.5.6.2 NAME 'country'
- SUP top
- STRUCTURAL
- MUST c
- MAY ( searchGuide $
- description ) )
-
-3.3. 'dcObject'
-
- The 'dcObject' object class permits an entry to contains domain
- component information. This object class is defined as auxiliary,
- because it will be used in conjunction with an existing structural
- object class.
- (Source: RFC 2247 [RFC2247])
-
- ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'
- SUP top
- AUXILIARY
- MUST dc )
-
-3.4. 'device'
-
- The 'device' object class is the basis of an entry that represents an
- appliance, computer, or network element.
- (Source: X.521 [X.521])
-
-
-
-
-
-Sciberras Standards Track [Page 21]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.6.14 NAME 'device'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( serialNumber $
- seeAlso $
- owner $
- ou $
- o $
- l $
- description ) )
-
-3.5. 'groupOfNames'
-
- The 'groupOfNames' object class is the basis of an entry that
- represents a set of named objects including information related to
- the purpose or maintenance of the set.
- (Source: X.521 [X.521])
-
- ( 2.5.6.9 NAME 'groupOfNames'
- SUP top
- STRUCTURAL
- MUST ( member $
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
-
-3.6. 'groupOfUniqueNames'
-
- The 'groupOfUniqueNames' object class is the same as the
- 'groupOfNames' object class except that the object names are not
- repeated or reassigned within a set scope.
- (Source: X.521 [X.521])
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 22]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.6.17 NAME 'groupOfUniqueNames'
- SUP top
- STRUCTURAL
- MUST ( uniqueMember $
- cn )
- MAY ( businessCategory $
- seeAlso $
- owner $
- ou $
- o $
- description ) )
-
-3.7. 'locality'
-
- The 'locality' object class is the basis of an entry that represents
- a place in the physical world.
- (Source: X.521 [X.521])
-
- ( 2.5.6.3 NAME 'locality'
- SUP top
- STRUCTURAL
- MAY ( street $
- seeAlso $
- searchGuide $
- st $
- l $
- description ) )
-
-3.8. 'organization'
-
- The 'organization' object class is the basis of an entry that
- represents a structured group of people.
- (Source: X.521 [X.521])
-
- ( 2.5.6.4 NAME 'organization'
- SUP top
- STRUCTURAL
- MUST o
- MAY ( userPassword $ searchGuide $ seeAlso $
- businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationalISDNNumber $
- facsimileTelephoneNumber $ street $ postOfficeBox $
- postalCode $ postalAddress $ physicalDeliveryOfficeName $
- st $ l $ description ) )
-
-
-
-
-
-Sciberras Standards Track [Page 23]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-3.9. 'organizationalPerson'
-
- The 'organizationalPerson' object class is the basis of an entry that
- represents a person in relation to an organization.
- (Source: X.521 [X.521])
-
- ( 2.5.6.7 NAME 'organizationalPerson'
- SUP person
- STRUCTURAL
- MAY ( title $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationalISDNNumber $
- facsimileTelephoneNumber $ street $ postOfficeBox $
- postalCode $ postalAddress $ physicalDeliveryOfficeName $
- ou $ st $ l ) )
-
-3.10. 'organizationalRole'
-
- The 'organizationalRole' object class is the basis of an entry that
- represents a job, function, or position in an organization.
- (Source: X.521 [X.521])
-
- ( 2.5.6.8 NAME 'organizationalRole'
- SUP top
- STRUCTURAL
- MUST cn
- MAY ( x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationalISDNNumber $ facsimileTelephoneNumber $
- seeAlso $ roleOccupant $ preferredDeliveryMethod $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ ou $ st $ l $
- description ) )
-
-3.11. 'organizationalUnit'
-
- The 'organizationalUnit' object class is the basis of an entry that
- represents a piece of an organization.
- (Source: X.521 [X.521])
-
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 24]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- ( 2.5.6.5 NAME 'organizationalUnit'
- SUP top
- STRUCTURAL
- MUST ou
- MAY ( businessCategory $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationalISDNNumber $ l $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $
- registeredAddress $ searchGuide $ seeAlso $ st $ street $
- telephoneNumber $ teletexTerminalIdentifier $
- telexNumber $ userPassword $ x121Address ) )
-
-3.12 'person'
-
- The 'person' object class is the basis of an entry that represents a
- human being.
- (Source: X.521 [X.521])
-
- ( 2.5.6.6 NAME 'person'
- SUP top
- STRUCTURAL
- MUST ( sn $
- cn )
- MAY ( userPassword $
- telephoneNumber $
- seeAlso $ description ) )
-
-3.13. 'residentialPerson'
-
- The 'residentialPerson' object class is the basis of an entry that
- includes a person's residence in the representation of the person.
- (Source: X.521 [X.521])
-
- ( 2.5.6.10 NAME 'residentialPerson'
- SUP person
- STRUCTURAL
- MUST l
- MAY ( businessCategory $ x121Address $ registeredAddress $
- destinationIndicator $ preferredDeliveryMethod $
- telexNumber $ teletexTerminalIdentifier $
- telephoneNumber $ internationalISDNNumber $
- facsimileTelephoneNumber $ preferredDeliveryMethod $
- street $ postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l ) )
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 25]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-3.14. 'uidObject'
-
- The 'uidObject' object class permits an entry to contains user
- identification information. This object class is defined as
- auxiliary, because it will be used in conjunction with an existing
- structural object class.
- (Source: RFC 2377 [RFC2377])
-
- ( 1.3.6.1.1.3.1 NAME 'uidObject'
- SUP top
- AUXILIARY
- MUST uid )
-
-4. 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 comments
- Object Identifier: see comments
- Person & email address to contact for further information:
- Andrew Sciberras <andrew.sciberras at eb2bcom.com>
- Usage: (A = attribute type, O = Object Class) see comment
- Specification: RFC 4519
- Author/Change Controller: IESG
-
- Comments
-
- In the LDAP descriptors registry, the following descriptors (short
- names) have been updated to refer to RFC 4519. Names that need to
- be reserved, rather than assigned to an Object Identifier, will
- contain an Object Identifier value of RESERVED.
-
- NAME Type OID
- ------------------------ ---- ----------------------------
- applicationProcess O 2.5.6.11
- businessCategory A 2.5.4.15
- c A 2.5.4.6
- cn A 2.5.4.3
- commonName A 2.5.4.3
- country O 2.5.6.2
- countryName A 2.5.4.6
- dc A 0.9.2342.19200300.100.1.25
- dcObject O 1.3.6.1.4.1.1466.344
- description A 2.5.4.13
- destinationIndicator A 2.5.4.27
- device O 2.5.6.14
-
-
-
-Sciberras Standards Track [Page 26]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- NAME Type OID
- ------------------------ ---- ----------------------------
- distinguishedName A 2.5.4.49
- dnQualifier A 2.5.4.46
- domainComponent A 0.9.2342.19200300.100.1.25
- enhancedSearchGuide A 2.5.4.47
- facsimileTelephoneNumber A 2.5.4.23
- generationQualifier A 2.5.4.44
- givenName A 2.5.4.42
- gn A RESERVED
- groupOfNames O 2.5.6.9
- groupOfUniqueNames O 2.5.6.17
- houseIdentifier A 2.5.4.51
- initials A 2.5.4.43
- internationalISDNNumber A 2.5.4.25
- l A 2.5.4.7
- locality O 2.5.6.3
- localityName A 2.5.4.7
- member A 2.5.4.31
- name A 2.5.4.41
- o A 2.5.4.10
- organization O 2.5.6.4
- organizationName A 2.5.4.10
- organizationalPerson O 2.5.6.7
- organizationalRole O 2.5.6.8
- organizationalUnit O 2.5.6.5
- organizationalUnitName A 2.5.4.11
- ou A 2.5.4.11
- owner A 2.5.4.32
- person O 2.5.6.6
- physicalDeliveryOfficeName A 2.5.4.19
- postalAddress A 2.5.4.16
- postalCode A 2.5.4.17
- postOfficeBox A 2.5.4.18
- preferredDeliveryMethod A 2.5.4.28
- registeredAddress A 2.5.4.26
- residentialPerson O 2.5.6.10
- roleOccupant A 2.5.4.33
- searchGuide A 2.5.4.14
- seeAlso A 2.5.4.34
- serialNumber A 2.5.4.5
- sn A 2.5.4.4
- st A 2.5.4.8
- street A 2.5.4.9
- surname A 2.5.4.4
- telephoneNumber A 2.5.4.20
- teletexTerminalIdentifier A 2.5.4.22
- telexNumber A 2.5.4.21
-
-
-
-Sciberras Standards Track [Page 27]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- NAME Type OID
- ------------------------ ---- ----------------------------
- title A 2.5.4.12
- uid A 0.9.2342.19200300.100.1.1
- uidObject O 1.3.6.1.1.3.1
- uniqueMember A 2.5.4.50
- userid A 0.9.2342.19200300.100.1.1
- userPassword A 2.5.4.35
- x121Address A 2.5.4.24
- x500UniqueIdentifier A 2.5.4.45
-
-5. 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.
-
- Transfer of cleartext passwords is strongly discouraged where the
- underlying transport service cannot guarantee confidentiality and
- integrity, since this may result in disclosure of the password to
- unauthorized parties.
-
- Multiple attribute values for the 'userPassword' attribute need to be
- used with care. Especially reset/deletion of a password by an
- administrator without knowing the old user password gets tricky or
- impossible if multiple values for different applications are present.
-
- Certainly, applications that intend to replace the 'userPassword'
- value(s) with new value(s) should use modify/replaceValues (or
- modify/deleteAttribute+addAttribute). In addition, server
- implementations are encouraged to provide administrative controls
- that, if enabled, restrict the 'userPassword' attribute to one value.
-
- Note that when used for authentication purposes [RFC4513], the user
- need only prove knowledge of one of the values, not all of the
- values.
-
-6. Acknowledgements
-
- The definitions, on which this document is based, have been developed
- by committees for telecommunications and international standards.
-
- This document is an update of RFC 2256 by Mark Wahl. RFC 2256 was a
- product of the IETF ASID Working Group.
-
-
-
-
-
-
-Sciberras Standards Track [Page 28]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- The 'dc' attribute type definition and the 'dcObject' object class
- definition in this document supersede the specification in RFC 2247
- by S. Kille, M. Wahl, A. Grimstad, R. Huber, and S. Sataluri.
-
- The 'uid' attribute type definition in this document supersedes the
- specification of the 'userid' in RFC 1274 by P. Barker and S. Kille
- and of the uid in RFC 2798 by M. Smith.
-
- The 'uidObject' object class definition in this document supersedes
- the specification of the 'uidObject' in RFC 2377 by A. Grimstad, R.
- Huber, S. Sataluri, and M. Wahl.
-
- This document is based upon input of the IETF LDAPBIS working group.
- The author wishes to thank S. Legg and K. Zeilenga for their
- significant contribution to this update. The author would also like
- to thank Kathy Dally, who edited early versions of this document.
-
-7. References
-
-7.1. Normative References
-
- [E.123] Notation for national and international telephone numbers,
- ITU-T Recommendation E.123, 1988
-
- [E.164] The international public telecommunication numbering plan,
- ITU-T Recommendation E.164, 1997
-
- [F.1] Operational Provisions For The International Public
- Telegram Service Transmission System, CCITT Recommendation
- F.1, 1992
-
- [F.31] Telegram Retransmission System, CCITT Recommendation F.31,
- 1988
-
- [ISO3166] ISO 3166, "Codes for the representation of names of
- countries".
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
- STD 13, RFC 1034, November 1987.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
- and Support", STD 3, RFC 1123, October 1989.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
-
-
-Sciberras Standards Track [Page 29]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications (IDNA)",
- RFC 3490, March 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.
-
- [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.
-
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
- (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
-
- [X.121] International numbering plan for public data networks,
- ITU-T Recommendation X.121, 1996
-
- [X.509] The Directory: Authentication Framework, ITU-T
- Recommendation X.509, 1993
-
- [X.520] The Directory: Selected Attribute Types, ITU-T
- Recommendation X.520, 1993
-
- [X.521] The Directory: Selected Object Classes. ITU-T
- Recommendation X.521, 1993
-
-7.2. Informative References
-
- [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
- Schema", RFC 1274, November 1991.
-
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
- Sataluri, "Using Domains in LDAP/X.500 Distinguished
- Names", RFC 2247, January 1998.
-
- [RFC2377] Grimstad, A., Huber, R., Sataluri, S., and M. Wahl,
- "Naming Plan for Internet Directory-Enabled Applications",
- RFC 2377, September 1998.
-
- [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
- Class", RFC 2798, April 2000.
-
-
-
-Sciberras Standards Track [Page 30]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- [RFC4513] Harrison R., Ed., "Lightweight Directory Access Protocol
- (LDAP): Authentication Methods and Security Mechanisms",
- RFC 4513, June 2006.
-
- [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Schema Definitions for X.509 Certificates", RFC
- 4523, June 2006.
-
- [RFC4524] Zeilenga, E., Ed., "COSINE LDAP/X.500 Schema", RFC 4524,
- June 2006.
-
- [X.500] ITU-T Recommendations X.500 (1993) | ISO/IEC 9594-1:1994,
- Information Technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 31]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
-Appendix A. Changes Made Since RFC 2256
-
- This appendix lists the changes that have been made from RFC 2256 to
- RFC 4519.
-
- This appendix is not a normative part of this specification, which
- has been provided for informational purposes only.
-
- 1. Replaced the document title.
-
- 2. Removed the IESG Note.
-
- 3. Dependencies on RFC 1274 have been eliminated.
-
- 4. Added a Security Considerations section and an IANA
- Considerations section.
-
- 5. Deleted the conformance requirement for subschema object
- classes in favor of a statement in [RFC4517].
-
- 6. Added explanation to attribute types and to each object class.
-
- 7. Removed Section 4, Syntaxes, and Section 6, Matching Rules,
- (moved to [RFC4517]).
-
- 8. Removed the certificate-related attribute types:
- authorityRevocationList, cACertificate,
- certificateRevocationList, crossCertificatePair,
- deltaRevocationList, supportedAlgorithms, and userCertificate.
-
- Removed the certificate-related Object Classes:
- certificationAuthority, certificationAuthority-V2,
- cRLDistributionPoint, strongAuthenticationUser, and
- userSecurityInformation
-
- LDAP PKI is now discussed in [RFC4523].
-
- 9. Removed the dmdName, knowledgeInformation,
- presentationAddress, protocolInformation, and
- supportedApplicationContext attribute types and the dmd,
- applicationEntity, and dSA object classes.
-
- 10. Deleted the aliasedObjectName and objectClass attribute type
- definitions. Deleted the alias and top object class
- definitions. They are included in [RFC4512].
-
-
-
-
-
-
-Sciberras Standards Track [Page 32]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- 11. Added the 'dc' attribute type from RFC 2247, making the
- distinction between 'stored' and 'query' values when preparing
- IDN strings.
-
- 12. Numerous editorial changes.
-
- 13. Removed upper bound after the SYNTAX oid in all attribute
- definitions where it appeared.
-
- 14. Added text about Unicode, SASLprep [RFC4013], and UTF-8 for
- userPassword.
-
- 15. Included definitions, comments and references for 'dcObject'
- and 'uidObject'.
-
- 16. Replaced PKI schema references to use RFC 4523.
-
- 17. Spelt out and referenced ABNF on first usage.
-
- 18. Removed Section 2.4 (Source). Replaced the source table with
- explicit references for each definition.
-
- 19. All references to an attribute type or object class are
- enclosed in single quotes.
-
- 20. The layout of attribute type definitions has been changed to
- provide consistency throughout the document:
- > Section Heading
- > Description of Attribute type
- > Multivalued description
- > Source Information
- > Definition
- > Example
- > Additional Comments
-
- Adding this consistent output included the addition of
- examples to some definitions.
-
- 21. References to alternate names for attributes types are
- provided with a reference to where they were originally
- specified.
-
- 22. Clarification of the description of 'distinguishedName' and
- 'name', in regards to these attribute types being supertypes.
-
- 23. Spelt out ISDN on first usage.
-
-
-
-
-
-Sciberras Standards Track [Page 33]
-
-RFC 4519 LDAP: Schema for User Applications June 2006
-
-
- 24. Inserted a reference to [RFC4517] for the
- 'teletexTerminalIdentifier' definition's SYNTAX OID.
-
- 25. Additional names were added to the IANA Considerations. Names
- include 'commonName', 'dcObject', 'domainComponent', 'GN',
- 'localityName', 'organizationName', 'organizationUnitName',
- 'surname', 'uidObject' and 'userid'.
-
- 26. Renamed all instances of supercede to supersede.
-
- 27. Moved [F.1], [F.31] and [RFC4013] from informative to
- normative references.
-
- 28. Changed the 'c' definition to be consistent with X.500.
-
-Author's Address
-
- Andrew Sciberras
- eB2Bcom
- Suite 3, Woodhouse Corporate Centre,
- 935 Station Street,
- Box Hill North, Victoria 3129
- AUSTRALIA
-
- Phone: +61 3 9896 7833
- EMail: andrew.sciberras at eb2bcom.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 34]
-
-RFC 4519 LDAP: Schema for User Applications 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).
-
-
-
-
-
-
-
-Sciberras Standards Track [Page 35]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4520.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4520.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4520.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4520 OpenLDAP Foundation
-BCP: 64 June 2006
-Obsoletes: 3383
-Category: Best Current Practice
-
-
- Internet Assigned Numbers Authority (IANA) Considerations for
- the Lightweight Directory Access Protocol (LDAP)
-
-Status of This Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document provides procedures for registering extensible elements
- of the Lightweight Directory Access Protocol (LDAP). The document
- also provides guidelines to the Internet Assigned Numbers Authority
- (IANA) describing conditions under which new values can be assigned.
-
-1. Introduction
-
- The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
- extensible protocol. LDAP supports:
-
- - the addition of new operations,
- - the extension of existing operations, and
- - the extensible schema.
-
- This document details procedures for registering values used to
- unambiguously identify extensible elements of the protocol, including
- the following:
-
- - LDAP message types
- - LDAP extended operations and controls
- - LDAP result codes
- - LDAP authentication methods
- - LDAP attribute description options
- - Object Identifier descriptors
-
-
-
-
-
-Zeilenga Best Current Practice [Page 1]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- These registries are maintained by the Internet Assigned Numbers
- Authority (IANA).
-
- In addition, this document provides guidelines to IANA describing the
- conditions under which new values can be assigned.
-
- This document replaces RFC 3383.
-
-2. Terminology and Conventions
-
- This section details terms and conventions used in this document.
-
-2.1. Policy Terminology
-
- The terms "IESG Approval", "Standards Action", "IETF Consensus",
- "Specification Required", "First Come First Served", "Expert Review",
- and "Private Use" are used as defined in BCP 26 [RFC2434].
-
- The term "registration owner" (or "owner") refers to the party
- authorized to change a value's registration.
-
-2.2. Requirement 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 [RFC2119]. In
- this case, "the specification", as used by BCP 14, refers to the
- processing of protocols being submitted to the IETF standards
- process.
-
-2.3. Common ABNF Productions
-
- A number of syntaxes in this document are described using ABNF
- [RFC4234]. These syntaxes rely on the following common productions:
-
- ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
- LDIGIT = %x31-39 ; "1"-"9"
- DIGIT = %x30 / LDIGIT ; "0"-"9"
- HYPHEN = %x2D ; "-"
- DOT = %x2E ; "."
- number = DIGIT / ( LDIGIT 1*DIGIT )
- keychar = ALPHA / DIGIT / HYPHEN
- leadkeychar = ALPHA
- keystring = leadkeychar *keychar
- keyword = keystring
-
- Keywords are case insensitive.
-
-
-
-
-Zeilenga Best Current Practice [Page 2]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-3. IANA Considerations for LDAP
-
- This section details each kind of protocol value that can be
- registered and provides IANA guidelines on how to assign new values.
-
- IANA may reject obviously bogus registrations.
-
- LDAP values specified in RFCs MUST be registered. Other LDAP values,
- except those in private-use name spaces, SHOULD be registered. RFCs
- SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
- values.
-
-3.1. Object Identifiers
-
- Numerous LDAP schema and protocol elements are identified by Object
- Identifiers (OIDs) [X.680]. Specifications that assign OIDs to
- elements SHOULD state who delegated the OIDs for their use.
-
- For IETF-developed elements, specifications SHOULD use OIDs under
- "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed
- by others, any properly delegated OID can be used, including those
- under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
- Enterprise Numbers" (1.3.6.1.4.1.x).
-
- Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
- Review with Specification Required. Only one OID per specification
- will be assigned. The specification MAY then assign any number of
- OIDs within this arc without further coordination with IANA.
-
- Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
- IANA <http://www.iana.org/cgi-bin/enterprise.pl>. Practices for IANA
- assignment of Internet Private Enterprise Numbers are detailed in RFC
- 2578 [RFC2578].
-
- To avoid interoperability problems between early implementations of a
- "work in progress" and implementations of the published specification
- (e.g., the RFC), experimental OIDs SHOULD be used in "works in
- progress" and early implementations. OIDs under the Internet
- Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
- Practices for IANA assignment of these Internet Experimental numbers
- are detailed in RFC 2578 [RFC2578].
-
-3.2. Protocol Mechanisms
-
- LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
- for discovery of protocol mechanisms identified by OIDs, including
- the supportedControl, supportedExtension, and supportedFeatures
- attributes [RFC4512].
-
-
-
-Zeilenga Best Current Practice [Page 3]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- A registry of OIDs used for discovery of protocol mechanisms is
- provided to allow implementors and others to locate the technical
- specification for these protocol mechanisms. Future specifications
- of additional Root DSE attributes holding values identifying protocol
- mechanisms MAY extend this registry for their values.
-
- Protocol mechanisms are registered on a First Come First Served
- basis.
-
-3.3. LDAP Syntaxes
-
- This registry provides a listing of LDAP syntaxes [RFC4512]. Each
- LDAP syntax is identified by an OID. This registry is provided to
- allow implementors and others to locate the technical specification
- describing a particular LDAP Syntax.
-
- LDAP Syntaxes are registered on a First Come First Served with
- Specification Required basis.
-
- Note: Unlike object classes, attribute types, and various other kinds
- of schema elements, descriptors are not used in LDAP to
- identify LDAP Syntaxes.
-
-3.4. Object Identifier Descriptors
-
- LDAP allows short descriptive names (or descriptors) to be used
- instead of a numeric Object Identifier to identify select protocol
- extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
- extensions, and other objects.
-
- Although the protocol allows the same descriptor to refer to
- different object identifiers in certain cases and the registry
- supports multiple registrations of the same descriptor (each
- indicating a different kind of schema element and different object
- identifier), multiple registrations of the same descriptor are to be
- avoided. All such multiple registration requests require Expert
- Review.
-
- Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
- Unicode characters restricted by the following ABNF:
-
- name = keystring
-
- Descriptors are case insensitive.
-
- Multiple names may be assigned to a given OID. For purposes of
- registration, an OID is to be represented in numeric OID form (e.g.,
- 1.1.0.23.40) conforming to the following ABNF:
-
-
-
-Zeilenga Best Current Practice [Page 4]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- numericoid = number 1*( DOT number )
-
- While the protocol places no maximum length restriction upon
- descriptors, they should be short. Descriptors longer than 48
- characters may be viewed as too long to register.
-
- A value ending with a hyphen ("-") reserves all descriptors that
- start with that value. For example, the registration of the option
- "descrFamily-" reserves all options that start with "descrFamily-"
- for some related purpose.
-
- Descriptors beginning with "x-" are for Private Use and cannot be
- registered.
-
- Descriptors beginning with "e-" are reserved for experiments and will
- be registered on a First Come First Served basis.
-
- All other descriptors require Expert Review to be registered.
-
- The registrant need not "own" the OID being named.
-
- The OID name space is managed by the ISO/IEC Joint Technical
- Committee 1 - Subcommittee 6.
-
-3.5. AttributeDescription Options
-
- An AttributeDescription [RFC4512] can contain zero or more options
- specifying additional semantics. An option SHALL be restricted to a
- string of UTF-8 encoded Unicode characters limited by the following
- ABNF:
-
- option = keystring
-
- Options are case insensitive.
-
- While the protocol places no maximum length restriction upon option
- strings, they should be short. Options longer than 24 characters may
- be viewed as too long to register.
-
- Values ending with a hyphen ("-") reserve all option names that start
- with the name. For example, the registration of the option
- "optionFamily-" reserves all options that start with "optionFamily-"
- for some related purpose.
-
- Options beginning with "x-" are for Private Use and cannot be
- registered.
-
-
-
-
-
-Zeilenga Best Current Practice [Page 5]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- Options beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other options require Standards Action or Expert Review with
- Specification Required to be registered.
-
-3.6. LDAP Message Types
-
- Each protocol message is encapsulated in an LDAPMessage envelope
- [RFC4511. The protocolOp CHOICE indicates the type of message
- encapsulated. Each message type consists of an ASN.1 identifier in
- the form of a keyword and a non-negative choice number. The choice
- number is combined with the class (APPLICATION) and data type
- (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
- encoding. The choice numbers for existing protocol messages are
- implicit in the protocol's ASN.1 defined in [RFC4511].
-
- New values will be registered upon Standards Action.
-
- Note: LDAP provides extensible messages that reduce but do not
- eliminate the need to add new message types.
-
-3.7. LDAP Authentication Method
-
- The LDAP Bind operation supports multiple authentication methods
- [RFC4511]. Each authentication choice consists of an ASN.1
- identifier in the form of a keyword and a non-negative integer.
-
- The registrant SHALL classify the authentication method usage using
- one of the following terms:
-
- COMMON - method is appropriate for common use on the
- Internet.
- LIMITED USE - method is appropriate for limited use.
- OBSOLETE - method has been deprecated or otherwise found to
- be inappropriate for any use.
-
- Methods without publicly available specifications SHALL NOT be
- classified as COMMON. New registrations of the class OBSOLETE cannot
- be registered.
-
- New authentication method integers in the range 0-1023 require
- Standards Action to be registered. New authentication method
- integers in the range 1024-4095 require Expert Review with
- Specification Required. New authentication method integers in the
- range 4096-16383 will be registered on a First Come First Served
- basis. Keywords associated with integers in the range 0-4095 SHALL
- NOT start with "e-" or "x-". Keywords associated with integers in
-
-
-
-Zeilenga Best Current Practice [Page 6]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- the range 4096-16383 SHALL start with "e-". Values greater than or
- equal to 16384 and keywords starting with "x-" are for Private Use
- and cannot be registered.
-
- Note: LDAP supports Simple Authentication and Security Layers
- [RFC4422] as an authentication choice. SASL is an extensible
- authentication framework.
-
-3.8. LDAP Result Codes
-
- LDAP result messages carry a resultCode enumerated value to indicate
- the outcome of the operation [RFC4511]. Each result code consists of
- an ASN.1 identifier in the form of a keyword and a non-negative
- integer.
-
- New resultCodes integers in the range 0-1023 require Standards Action
- to be registered. New resultCode integers in the range 1024-4095
- require Expert Review with Specification Required. New resultCode
- integers in the range 4096-16383 will be registered on a First Come
- First Served basis. Keywords associated with integers in the range
- 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with
- integers in the range 4096-16383 SHALL start with "e-". Values
- greater than or equal to 16384 and keywords starting with "x-" are
- for Private Use and cannot be registered.
-
-3.9. LDAP Search Scope
-
- LDAP SearchRequest messages carry a scope-enumerated value to
- indicate the extent of search within the DIT [RFC4511]. Each search
- value consists of an ASN.1 identifier in the form of a keyword and a
- non-negative integer.
-
- New scope integers in the range 0-1023 require Standards Action to be
- registered. New scope integers in the range 1024-4095 require Expert
- Review with Specification Required. New scope integers in the range
- 4096-16383 will be registered on a First Come First Served basis.
- Keywords associated with integers in the range 0-4095 SHALL NOT start
- with "e-" or "x-". Keywords associated with integers in the range
- 4096-16383 SHALL start with "e-". Values greater than or equal to
- 16384 and keywords starting with "x-" are for Private Use and cannot
- be registered.
-
-3.10. LDAP Filter Choice
-
- LDAP filters are used in making assertions against an object
- represented in the directory [RFC4511]. The Filter CHOICE indicates
- a type of assertion. Each Filter CHOICE consists of an ASN.1
- identifier in the form of a keyword and a non-negative choice number.
-
-
-
-Zeilenga Best Current Practice [Page 7]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- The choice number is combined with the class (APPLICATION) and data
- type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
- message's encoding.
-
- Note: LDAP provides the extensibleMatching choice, which reduces but
- does not eliminate the need to add new filter choices.
-
-3.11. LDAP ModifyRequest Operation Type
-
- The LDAP ModifyRequest carries a sequence of modification operations
- [RFC4511]. Each kind (e.g., add, delete, replace) of operation
- consists of an ASN.1 identifier in the form of a keyword and a non-
- negative integer.
-
- New operation type integers in the range 0-1023 require Standards
- Action to be registered. New operation type integers in the range
- 1024-4095 require Expert Review with Specification Required. New
- operation type integers in the range 4096-16383 will be registered on
- a First Come First Served basis. Keywords associated with integers
- in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords
- associated with integers in the range 4096-16383 SHALL start with
- "e-". Values greater than or equal to 16384 and keywords starting
- with "x-" are for Private Use and cannot be registered.
-
-3.12. LDAP authzId Prefixes
-
- Authorization Identities in LDAP are strings conforming to the
- <authzId> production [RFC4513]. This production is extensible. Each
- new specific authorization form is identified by a prefix string
- conforming to the following ABNF:
-
- prefix = keystring COLON
- COLON = %x3A ; COLON (":" U+003A)
-
- Prefixes are case insensitive.
-
- While the protocol places no maximum length restriction upon prefix
- strings, they should be short. Prefixes longer than 12 characters
- may be viewed as too long to register.
-
- Prefixes beginning with "x-" are for Private Use and cannot be
- registered.
-
- Prefixes beginning with "e-" are reserved for experiments and will be
- registered on a First Come First Served basis.
-
- All other prefixes require Standards Action or Expert Review with
- Specification Required to be registered.
-
-
-
-Zeilenga Best Current Practice [Page 8]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-3.13. Directory Systems Names
-
- The IANA-maintained "Directory Systems Names" registry [IANADSN] of
- valid keywords for well-known attributes was used in the LDAPv2
- string representation of a distinguished name [RFC1779]. LDAPv2 is
- now Historic [RFC3494].
-
- Directory systems names are not known to be used in any other
- context. LDAPv3 [RFC4514] uses Object Identifier Descriptors
- [Section 3.2] (which have a different syntax than directory system
- names).
-
- New Directory System Names will no longer be accepted. For
- historical purposes, the current list of registered names should
- remain publicly available.
-
-4. Registration Procedure
-
- The procedure given here MUST be used by anyone who wishes to use a
- new value of a type described in Section 3 of this document.
-
- The first step is for the requester to fill out the appropriate form.
- Templates are provided in Appendix A.
-
- If the policy is Standards Action, the completed form SHOULD be
- provided to the IESG with the request for Standards Action. Upon
- approval of the Standards Action, the IESG SHALL forward the request
- (possibly revised) to IANA. The IESG SHALL be regarded as the
- registration owner of all values requiring Standards Action.
-
- If the policy is Expert Review, the requester SHALL post the
- completed form to the <directory at apps.ietf.org> mailing list for
- public review. The review period is two (2) weeks. If a revised
- form is later submitted, the review period is restarted. Anyone may
- subscribe to this list by sending a request to <directory-
- request at apps.ietf.org>. During the review, objections may be raised
- by anyone (including the Expert) on the list. After completion of
- the review, the Expert, based on public comments, SHALL either
- approve the request and forward it to the IANA OR deny the request.
- In either case, the Expert SHALL promptly notify the requester of the
- action. Actions of the Expert may be appealed [RFC2026]. The Expert
- is appointed by Applications Area Directors. The requester is viewed
- as the registration owner of values registered under Expert Review.
-
- If the policy is First Come First Served, the requester SHALL submit
- the completed form directly to the IANA: <iana at iana.org>. The
- requester is viewed as the registration owner of values registered
- under First Come First Served.
-
-
-
-Zeilenga Best Current Practice [Page 9]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- Neither the Expert nor IANA will take position on the claims of
- copyright or trademark issues regarding completed forms.
-
- Prior to submission of the Internet Draft (I-D) to the RFC Editor but
- after IESG review and tentative approval, the document editor SHOULD
- revise the I-D to use registered values.
-
-5. Registration Maintenance
-
- This section discusses maintenance of registrations.
-
-5.1. Lists of Registered Values
-
- IANA makes lists of registered values readily available to the
- Internet community on its web site: <http://www.iana.org/>.
-
-5.2. Change Control
-
- The registration owner MAY update the registration subject to the
- same constraints and review as with new registrations. In cases
- where the registration owner is unable or is unwilling to make
- necessary updates, the IESG MAY assume ownership of the registration
- in order to update the registration.
-
-5.3. Comments
-
- For cases where others (anyone other than the registration owner)
- have significant objections to the claims in a registration and the
- registration owner does not agree to change the registration,
- comments MAY be attached to a registration upon Expert Review. For
- registrations owned by the IESG, the objections SHOULD be addressed
- by initiating a request for Expert Review.
-
- The form of these requests is ad hoc, but MUST include the specific
- objections to be reviewed and SHOULD contain (directly or by
- reference) materials supporting the objections.
-
-6. Security Considerations
-
- The security considerations detailed in BCP 26 [RFC2434] are
- generally applicable to this document. Additional security
- considerations specific to each name space are discussed in Section
- 3, where appropriate.
-
- Security considerations for LDAP are discussed in documents
- comprising the technical specification [RFC4510].
-
-
-
-
-
-Zeilenga Best Current Practice [Page 10]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-7. Acknowledgement
-
- This document is a product of the IETF LDAP Revision (LDAPBIS)
- Working Group (WG). This document is a revision of RFC 3383, also a
- product of the LDAPBIS WG.
-
- This document includes text borrowed from "Guidelines for Writing an
- IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
- Harald Alvestrand.
-
-8. References
-
-8.1. Normative References
-
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
- 3", BCP 9, RFC 2026, October 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
- "Structure of Management Information Version 2 (SMIv2)",
- STD 58, RFC 2578, April 1999.
-
- [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.
-
-
-
-Zeilenga Best Current Practice [Page 11]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory Access
- Protocol (LDAP): Uniform Resource Locator", RFC 4516, 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.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).
-
-8.2. Informative References
-
- [RFC1779] Kille, S., "A String Representation of Distinguished
- Names", RFC 1779, March 1995.
-
- [RFC3494] Zeilenga, K.,"Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
- (LDAP): String Representation of Distinguished Names", RFC
- 4514, June 2006.
-
- [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
- Authentication and Security Layer (SASL)", RFC 4422, June
- 2006.
-
- [IANADSN] IANA, "Directory Systems Names",
- http://www.iana.org/assignments/directory-system-names.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 12]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-Appendix A. Registration Templates
-
- This appendix provides registration templates for registering new
- LDAP values. Note that more than one value may be requested by
- extending the template by listing multiple values, or through use of
- tables.
-
-A.1. LDAP Object Identifier Registration Template
-
- Subject: Request for LDAP OID Registration
-
- Person & email address to contact for further information:
-
- Specification: (I-D)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.2. LDAP Protocol Mechanism Registration Template
-
- Subject: Request for LDAP Protocol Mechanism Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Usage: (One of Control or Extension or Feature or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 13]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-A.3. LDAP Syntax Registration Template
-
- Subject: Request for LDAP Syntax Registration
-
- Object Identifier:
-
- Description:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.4. LDAP Descriptor Registration Template
-
- Subject: Request for LDAP Descriptor Registration
-
- Descriptor (short name):
-
- Object Identifier:
-
- Person & email address to contact for further information:
-
- Usage: (One of administrative role, attribute type, matching rule,
- name form, object class, URL extension, or other)
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 14]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-A.5. LDAP Attribute Description Option Registration Template
-
- Subject: Request for LDAP Attribute Description Option Registration
- Option Name:
-
- Family of Options: (YES or NO)
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.6. LDAP Message Type Registration Template
-
- Subject: Request for LDAP Message Type Registration
-
- LDAP Message Name:
-
- Person & email address to contact for further information:
-
- Specification: (Approved I-D)
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.7. LDAP Authentication Method Registration Template
-
- Subject: Request for LDAP Authentication Method Registration
-
- Authentication Method Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-
-
-Zeilenga Best Current Practice [Page 15]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-A.8. LDAP Result Code Registration Template
-
- Subject: Request for LDAP Result Code Registration
-
- Result Code Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.8. LDAP Search Scope Registration Template
-
- Subject: Request for LDAP Search Scope Registration
-
- Search Scope Name:
-
- Filter Scope String:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 16]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
-A.9. LDAP Filter Choice Registration Template
-
- Subject: Request for LDAP Filter Choice Registration
-
- Filter Choice Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-A.10. LDAP ModifyRequest Operation Registration Template
-
- Subject: Request for LDAP ModifyRequest Operation Registration
-
- ModifyRequest Operation Name:
-
- Person & email address to contact for further information:
-
- Specification: (RFC, I-D, URI)
-
- Author/Change Controller:
-
- Comments:
-
- (Any comments that the requester deems relevant to the request.)
-
-Appendix B. Changes since RFC 3383
-
- This informative appendix provides a summary of changes made since
- RFC 3383.
-
- - Object Identifier Descriptors practices were updated to require
- all descriptors defined in RFCs to be registered and
- recommending all other descriptors (excepting those in
- private-use name space) be registered. Additionally, all
- requests for multiple registrations of the same descriptor are
- now subject to Expert Review.
-
- - Protocol Mechanisms practices were updated to include values of
- the 'supportedFeatures' attribute type.
-
-
-
-
-
-Zeilenga Best Current Practice [Page 17]
-
-RFC 4520 IANA Considerations for LDAP June 2006
-
-
- - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
- operation, and authzId prefixes registries were added.
-
- - References to RFCs comprising the LDAP technical specifications
- have been updated to latest revisions.
-
- - References to ISO 10646 have been replaced with [Unicode].
-
- - The "Assigned Values" appendix providing initial registry
- values was removed.
-
- - Numerous editorial changes were made.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 18]
-
-RFC 4520 IANA Considerations for LDAP 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 Best Current Practice [Page 19]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4521.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4521.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4521.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4521 OpenLDAP Foundation
-BCP: 118 June 2006
-Category: Best Current Practice
-
-
- Considerations for
- Lightweight Directory Access Protocol (LDAP) Extensions
-
-Status of This Memo
-
- This document specifies an Internet Best Current Practices for the
- Internet Community, and requests discussion and suggestions for
- improvements. Distribution of this memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) is extensible. It
- provides mechanisms for adding new operations, extending existing
- operations, and expanding user and system schemas. This document
- discusses considerations for designers of LDAP extensions.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 1]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Terminology ................................................3
- 2. General Considerations ..........................................4
- 2.1. Scope of Extension .........................................4
- 2.2. Interaction between extensions .............................4
- 2.3. Discovery Mechanism ........................................4
- 2.4. Internationalization Considerations ........................5
- 2.5. Use of the Basic Encoding Rules ............................5
- 2.6. Use of Formal Languages ....................................5
- 2.7. Examples ...................................................5
- 2.8. Registration of Protocol Values ............................5
- 3. LDAP Operation Extensions .......................................6
- 3.1. Controls ...................................................6
- 3.1.1. Extending Bind Operation with Controls ..............6
- 3.1.2. Extending the Start TLS Operation with Controls .....7
- 3.1.3. Extending the Search Operation with Controls ........7
- 3.1.4. Extending the Update Operations with Controls .......8
- 3.1.5. Extending the Responseless Operations with Controls..8
- 3.2. Extended Operations ........................................8
- 3.3. Intermediate Responses .....................................8
- 3.4. Unsolicited Notifications ..................................9
- 4. Extending the LDAP ASN.1 Definition .............................9
- 4.1. Result Codes ...............................................9
- 4.2. LDAP Message Types .........................................9
- 4.3. Authentication Methods ....................................10
- 4.4. General ASN.1 Extensibility ...............................10
- 5. Schema Extensions ..............................................10
- 5.1. LDAP Syntaxes .............................................11
- 5.2. Matching Rules ............................................11
- 5.3. Attribute Types ...........................................12
- 5.4. Object Classes ............................................12
- 6. Other Extension Mechanisms .....................................12
- 6.1. Attribute Description Options .............................12
- 6.2. Authorization Identities ..................................12
- 6.3. LDAP URL Extensions .......................................12
- 7. Security Considerations ........................................12
- 8. Acknowledgements ...............................................13
- 9. References .....................................................13
- 9.1. Normative References ......................................13
- 9.2. Informative References ....................................15
-
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 2]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC4510] is an
- extensible protocol.
-
- LDAP allows for new operations to be added and for existing
- operations to be enhanced [RFC4511].
-
- LDAP allows additional schema to be defined [RFC4512][RFC4517]. This
- can include additional object classes, attribute types, matching
- rules, additional syntaxes, and other elements of schema. LDAP
- provides an ability to extend attribute types with options [RFC4512].
-
- LDAP supports a Simple Authentication and Security Layer (SASL)
- authentication method [RFC4511][RFC4513]. SASL [RFC4422] is
- extensible. LDAP may be extended to support additional
- authentication methods [RFC4511].
-
- LDAP supports establishment of Transport Layer Security (TLS)
- [RFC4511][RFC4513]. TLS [RFC4346] is extensible.
-
- LDAP has an extensible Uniform Resource Locator (URL) format
- [RFC4516].
-
- Lastly, LDAP allows for certain extensions to the protocol's Abstract
- Syntax Notation - One (ASN.1) [X.680] definition to be made. This
- facilitates a wide range of protocol enhancements, for example, new
- result codes needed to support extensions to be added through
- extension of the protocol's ASN.1 definition.
-
- This document describes practices that engineers should consider when
- designing extensions to LDAP.
-
-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 [RFC2119]. In
- this document, "the specification", as used by BCP 14, RFC 2119,
- refers to the engineering of LDAP extensions.
-
- The term "Request Control" refers to a control attached to a client-
- generated message sent to a server. The term "Response Control"
- refers to a control attached to a server-generated message sent to a
- client.
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 3]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- DIT stands for Directory Information Tree.
- DSA stands for Directory System Agent, a server.
- DSE stands for DSA-Specific Entry.
- DUA stands for Directory User Agent, a client.
- DN stands for Distinguished Name.
-
-2. General Considerations
-
-2.1. Scope of Extension
-
- Mutually agreeing peers may, within the confines of an extension,
- agree to significant changes in protocol semantics. However,
- designers MUST consider the impact of an extension upon protocol
- peers that have not agreed to implement or otherwise recognize and
- support the extension. Extensions MUST be "truly optional"
- [RFC2119].
-
-2.2. Interaction between extensions
-
- Designers SHOULD consider how extensions they engineer interact with
- other extensions.
-
- Designers SHOULD consider the extensibility of extensions they
- specify. Extensions to LDAP SHOULD themselves be extensible.
-
- Except where it is stated otherwise, extensibility is implied.
-
-2.3. Discovery Mechanism
-
- Extensions SHOULD provide adequate discovery mechanisms.
-
- As LDAP design is based upon the client-request/server-response
- paradigm, the general discovery approach is for the client to
- discover the capabilities of the server before utilizing a particular
- extension. Commonly, this discovery involves querying the root DSE
- and/or other DSEs for operational information associated with the
- extension. LDAP provides no mechanism for a server to discover the
- capabilities of a client.
-
- The 'supportedControl' attribute [RFC4512] is used to advertise
- supported controls. The 'supportedExtension' attribute [RFC4512] is
- used to advertise supported extended operations. The
- 'supportedFeatures' attribute [RFC4512] is used to advertise
- features. Other root DSE attributes MAY be defined to advertise
- other capabilities.
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 4]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-2.4. Internationalization Considerations
-
- LDAP is designed to support the full Unicode [Unicode] repertory of
- characters. Extensions SHOULD avoid unnecessarily restricting
- applications to subsets of Unicode (e.g., Basic Multilingual Plane,
- ISO 8859-1, ASCII, Printable String).
-
- LDAP Language Tag options [RFC3866] provide a mechanism for tagging
- text (and other) values with language information. Extensions that
- define attribute types SHOULD allow use of language tags with these
- attributes.
-
-2.5. Use of the Basic Encoding Rules
-
- Numerous elements of LDAP are described using ASN.1 [X.680] and are
- encoded using a particular subset [Protocol, Section 5.2] of the
- Basic Encoding Rules (BER) [X.690]. To allow reuse of
- parsers/generators used in implementing the LDAP "core" technical
- specification [RFC4510], it is RECOMMENDED that extension elements
- (e.g., extension specific contents of controlValue, requestValue,
- responseValue fields) described by ASN.1 and encoded using BER be
- subjected to the restrictions of [Protocol, Section 5.2].
-
-2.6. Use of Formal Languages
-
- Formal languages SHOULD be used in specifications in accordance with
- IESG guidelines [FORMAL].
-
-2.7. Examples
-
- Example DN strings SHOULD conform to the syntax defined in [RFC4518].
- Example LDAP filter strings SHOULD conform to the syntax defined in
- [RFC4515]. Example LDAP URLs SHOULD conform to the syntax defined in
- [RFC4516]. Entries SHOULD be represented using LDIF [RFC2849].
-
-2.8. Registration of Protocol Values
-
- Designers SHALL register protocol values of their LDAP extensions in
- accordance with BCP 64, RFC 4520 [RFC4520]. Specifications that
- create new extensible protocol elements SHALL extend existing
- registries or establish new registries for values of these elements
- in accordance with BCP 64, RFC 4520 [RFC4520] and BCP 26, RFC 2434
- [RFC2434].
-
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 5]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-3. LDAP Operation Extensions
-
- Extensions SHOULD use controls in defining extensions that complement
- existing operations. Where the extension to be defined does not
- complement an existing operation, designers SHOULD consider defining
- an extended operation instead.
-
- For example, a subtree delete operation could be designed as either
- an extension of the delete operation or as a new operation. As the
- feature complements the existing delete operation, use of the control
- mechanism to extend the delete operation is likely more appropriate.
-
- As a counter (and contrived) example, a locate services operation (an
- operation that would return for a DN a set of LDAP URLs to services
- that may hold the entry named by this DN) could be designed as either
- a search operation or a new operation. As the feature doesn't
- complement the search operation (e.g., the operation is not contrived
- to search for entries held in the Directory Information Tree), it is
- likely more appropriate to define a new operation using the extended
- operation mechanism.
-
-3.1. Controls
-
- Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for
- extending existing operations. The existing operation can be a base
- operation defined in [RFC4511] (e.g., search, modify) , an extended
- operation (e.g., Start TLS [RFC4511], Password Modify [RFC3062]), or
- an operation defined as an extension to a base or extended operation.
-
- Extensions SHOULD NOT return Response controls unless the server has
- specific knowledge that the client can make use of the control.
- Generally, the client requests the return of a particular response
- control by providing a related request control.
-
- An existing operation MAY be extended to return IntermediateResponse
- messages [Protocol, Section 4.13].
-
- Specifications of controls SHALL NOT attach additional semantics to
- the criticality of controls beyond those defined in [Protocol,
- Section 4.1.11]. A specification MAY mandate the criticality take on
- a particular value (e.g., TRUE or FALSE), where appropriate.
-
-3.1.1. Extending Bind Operation with Controls
-
- Controls attached to the request and response messages of a Bind
- Operation [RFC4511] are not protected by any security layers
- established by that Bind operation.
-
-
-
-
-Zeilenga Best Current Practice [Page 6]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- Specifications detailing controls extending the Bind operation SHALL
- detail that the Bind negotiated security layers do not protect the
- information contained in these controls and SHALL detail how the
- information in these controls is protected or why the information
- does not need protection.
-
- It is RECOMMENDED that designers consider alternative mechanisms for
- providing the function. For example, an extended operation issued
- subsequent to the Bind operation (hence, protected by the security
- layers negotiated by the Bind operation) might be used to provide the
- desired function.
-
- Additionally, designers of Bind control extensions MUST also consider
- how the controls' semantics interact with individual steps of a
- multi-step Bind operation. Note that some steps are optional and
- thus may require special attention in the design.
-
-3.1.2. Extending the Start TLS Operation with Controls
-
- Controls attached to the request and response messages of a Start TLS
- Operation [RFC4511] are not protected by the security layers
- established by the Start TLS operation.
-
- Specifications detailing controls extending the Start TLS operation
- SHALL detail that the Start TLS negotiated security layers do not
- protect the information contained in these controls and SHALL detail
- how the information in these controls is protected or why the
- information does not need protection.
-
- It is RECOMMENDED that designers consider alternative mechanisms for
- providing the function. For example, an extended operation issued
- subsequent to the Start TLS operation (hence, protected by the
- security layers negotiated by the Start TLS operation) might be used
- to provided the desired function.
-
-3.1.3. Extending the Search Operation with Controls
-
- The Search operation processing has two distinct phases:
-
- - finding the base object; and
-
- - searching for objects at or under that base object.
-
- Specifications of controls extending the Search Operation should
- clearly state in which phase(s) the control's semantics apply.
- Semantics of controls that are not specific to the Search Operation
- SHOULD apply in the finding phase.
-
-
-
-
-Zeilenga Best Current Practice [Page 7]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-3.1.4. Extending the Update Operations with Controls
-
- Update operations have properties of atomicity, consistency,
- isolation, and durability ([ACID]).
-
- - atomicity: All or none of the DIT changes requested are made.
-
- - consistency: The resulting DIT state must be conform to schema
- and other constraints.
-
- - isolation: Intermediate states are not exposed.
-
- - durability: The resulting DIT state is preserved until
- subsequently updated.
-
- When defining a control that requests additional (or other) DIT
- changes be made to the DIT, these additional changes SHOULD NOT be
- treated as part of a separate transaction. The specification MUST be
- clear as to whether the additional DIT changes are part of the same
- or a separate transaction as the DIT changes expressed in the request
- of the base operation.
-
- When defining a control that requests additional (or other) DIT
- changes be made to the DIT, the specification MUST be clear as to the
- order in which these and the base changes are to be applied to the
- DIT.
-
-3.1.5. Extending the Responseless Operations with Controls
-
- The Abandon and Unbind operations do not include a response message.
- For this reason, specifications for controls designed to be attached
- to Abandon and Unbind requests SHOULD mandate that the control's
- criticality be FALSE.
-
-3.2. Extended Operations
-
- Extended Operations [Protocol, Section 4.12] are the RECOMMENDED
- mechanism for defining new operations. An extended operation
- consists of an ExtendedRequest message, zero or more
- IntermediateResponse messages, and an ExtendedResponse message.
-
-3.3. Intermediate Responses
-
- Extensions SHALL use IntermediateResponse messages instead of
- ExtendedResponse messages to return intermediate results.
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 8]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-3.4. Unsolicited Notifications
-
- Unsolicited notifications [Protocol, Section 4.4] offer a capability
- for the server to notify the client of events not associated with the
- operation currently being processed.
-
- Extensions SHOULD be designed such that unsolicited notifications are
- not returned unless the server has specific knowledge that the client
- can make use of the notification. Generally, the client requests the
- return of a particular unsolicited notification by performing a
- related extended operation.
-
- For example, a time hack extension could be designed to return
- unsolicited notifications at regular intervals that were enabled by
- an extended operation (which possibly specified the desired
- interval).
-
-4. Extending the LDAP ASN.1 Definition
-
- LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1
- definition [Protocol, Appendix B] to be made.
-
-4.1. Result Codes
-
- Extensions that specify new operations or enhance existing operations
- often need to define new result codes. The extension SHOULD be
- designed such that a client has a reasonably clear indication of the
- nature of the successful or non-successful result.
-
- Extensions SHOULD use existing result codes to indicate conditions
- that are consistent with the intended meaning [RFC4511][X.511] of
- these codes. Extensions MAY introduce new result codes [RFC4520]
- where no existing result code provides an adequate indication of the
- nature of the result.
-
- Extensions SHALL NOT disallow or otherwise restrict the return of
- general service result codes, especially those reporting a protocol,
- service, or security problem, or indicating that the server is unable
- or unwilling to complete the operation.
-
-4.2. LDAP Message Types
-
- While extensions can specify new types of LDAP messages by extending
- the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally
- unnecessary and inappropriate. Existing operation extension
- mechanisms (e.g., extended operations, unsolicited notifications, and
- intermediate responses) SHOULD be used instead. However, there may
- be cases where an extension does not fit well into these mechanisms.
-
-
-
-Zeilenga Best Current Practice [Page 9]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- In such cases, a new extension mechanism SHOULD be defined that can
- be used by multiple extensions that have similar needs.
-
-4.3. Authentication Methods
-
- The Bind operation currently supports two authentication methods,
- simple and SASL. SASL [RFC4422] is an extensible authentication
- framework used by multiple application-level protocols (e.g., BEEP,
- IMAP, SMTP). It is RECOMMENDED that new authentication processes be
- defined as SASL mechanisms. New LDAP authentication methods MAY be
- added to support new authentication frameworks.
-
- The Bind operation's primary function is to establish the LDAP
- association [RFC4513]. No other operation SHALL be defined (or
- extended) to establish the LDAP association. However, other
- operations MAY be defined to establish other security associations
- (e.g., IPsec).
-
-4.4. General ASN.1 Extensibility
-
- Section 4 of [RFC4511] states the following:
-
- 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.
-
- Designers SHOULD avoid introducing extensions that rely on
- unsuspecting implementations to ignore trailing components of
- SEQUENCE whose tags they do not recognize.
-
-5. Schema Extensions
-
- Extensions defining LDAP schema elements SHALL provide schema
- definitions conforming with syntaxes defined in [Models, Section
- 4.1]. While provided definitions MAY be reformatted (line wrapped)
- for readability, this SHALL be noted in the specification.
-
- For definitions that allow a NAME field, new schema elements SHOULD
- provide one and only one name. The name SHOULD be short.
-
- Each schema definition allows a DESC field. The DESC field, if
- provided, SHOULD contain a short descriptive phrase. The DESC field
- MUST be regarded as informational. That is, the specification MUST
-
-
-
-Zeilenga Best Current Practice [Page 10]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- be written such that its interpretation is the same with and without
- the provided DESC fields.
-
- The extension SHALL NOT mandate that implementations provide the same
- DESC field in the schema they publish. Implementors MAY replace or
- remove the DESC field.
-
- Published schema elements SHALL NOT be redefined. Replacement schema
- elements (new OIDs, new NAMEs) SHOULD be defined as needed.
-
- Schema designers SHOULD reuse existing schema elements, where
- appropriate. However, any reuse MUST not alter the semantics of the
- element.
-
-5.1. LDAP Syntaxes
-
- Each LDAP syntax [RFC4517] is defined in terms of ASN.1 [X.680].
- Each extension detailing an LDAP syntax MUST specify the ASN.1 data
- definition associated with the syntax. A distinct LDAP syntax SHOULD
- be created for each distinct ASN.1 data definition (including
- constraints).
-
- Each LDAP syntax SHOULD have a string encoding defined for it. It is
- RECOMMENDED that this string encoding be restricted to UTF-8
- [RFC3629] encoded Unicode [Unicode] characters. Use of Generic
- String Encoding Rules (GSER) [RFC3641][RFC3642] or other generic
- string encoding rules to provide string encodings for complex ASN.1
- data definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that
- the string encoding be described using a formal language (e.g., ABNF
- [RFC4234]). Formal languages SHOULD be used in specifications in
- accordance with IESG guidelines [FORMAL].
-
- If no string encoding is defined, the extension SHALL specify how the
- transfer encoding is to be indicated. Generally, the extension
- SHOULD mandate use of binary or other transfer encoding option.
-
-5.2. Matching Rules
-
- Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
- SUBSTRING) may be associated with an attribute type. In addition,
- LDAP provides an extensible matching rule mechanism.
-
- The matching rule specification SHOULD detail which kind of matching
- rule it is and SHOULD describe which kinds of values it can be used
- with.
-
- In addition to requirements stated in the LDAP technical
- specification, equality matching rules SHOULD be commutative.
-
-
-
-Zeilenga Best Current Practice [Page 11]
-
-RFC 4521 LDAP Extensions June 2006
-
-
-5.3. Attribute Types
-
- Designers SHOULD carefully consider how the structure of values is to
- be restricted. Designers SHOULD consider that servers will only
- enforce constraints of the attribute's syntax. That is, an attribute
- intended to hold URIs, but that has directoryString syntax, is not
- restricted to values that are URIs.
-
- Designers SHOULD carefully consider which matching rules, if any, are
- appropriate for the attribute type. Matching rules specified for an
- attribute type MUST be compatible with the attribute type's syntax.
-
- Extensions specifying operational attributes MUST detail how servers
- are to maintain and/or utilize values of each operational attribute.
-
-5.4. Object Classes
-
- Designers SHOULD carefully consider whether each attribute of an
- object class is required ("MUST") or allowed ("MAY").
-
- Extensions specifying object classes that allow (or require)
- operational attributes MUST specify how servers are to maintain
- and/or utilize entries belonging to these object classes.
-
-6. Other Extension Mechanisms
-
-6.1. Attribute Description Options
-
- Each option is identified by a string of letters, numbers, and
- hyphens. This string SHOULD be short.
-
-6.2. Authorization Identities
-
- Extensions interacting with authorization identities SHALL support
- the LDAP authzId format [RFC4513]. The authzId format is extensible.
-
-6.3. LDAP URL Extensions
-
- LDAP URL extensions are identified by a short string, a descriptor.
- Like other descriptors, the string SHOULD be short.
-
-7. Security Considerations
-
- LDAP does not place undue restrictions on the kinds of extensions
- that can be implemented. While this document attempts to outline
- some specific issues that designers need to consider, it is not (and
-
-
-
-
-
-Zeilenga Best Current Practice [Page 12]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- cannot be) all encompassing. Designers MUST do their own evaluations
- of the security considerations applicable to their extensions.
-
- Designers MUST NOT assume that the LDAP "core" technical
- specification [RFC4510] adequately addresses the specific concerns
- surrounding their extensions or assume that their extensions have no
- specific concerns.
-
- Extension specifications, however, SHOULD note whether security
- considerations specific to the feature they are extending, as well as
- general LDAP security considerations, apply to the extension.
-
-8. Acknowledgements
-
- The author thanks the IETF LDAP community for their thoughtful
- comments.
-
- This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
- Greenblatt.
-
-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.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
- [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
- Types", RFC 3641, October 2003.
-
- [RFC3642] Legg, S., "Common Elements of Generic String Encoding
- Rules (GSER) Encodings", RFC 3642, October 2003.
-
- [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP): Directory Information Models", RFC 4512, June
- 2006.
-
-
-
-
-
-Zeilenga Best Current Practice [Page 13]
-
-RFC 4521 LDAP Extensions June 2006
-
-
- [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the
- Lightweight Directory Access Protocol (LDAP)", RFC 3866,
- July 2004.
-
- [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.
-
- [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): String Representation of Distinguished Names", 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.
-
- [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
- Authentication and Security Layer (SASL)", RFC 4422, June
- 2006.
-
-
-
-
-
-
-
-Zeilenga Best Current Practice [Page 14]
-
-RFC 4521 LDAP Extensions 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/).
-
- [FORMAL] IESG, "Guidelines for the use of formal languages in IETF
- specifications",
- <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
- specs.txt>, 2001.
-
- [X.511] International Telecommunication Union - Telecommunication
- Standardization Sector, "The Directory: Abstract Service
- Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
-
- [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).
-
- [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(2002) (also ISO/IEC 8825-1:2002).
-
-9.2. Informative References
-
- [ACID] Section 4 of ISO/IEC 10026-1:1992.
-
- [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", Work in
- Progress.
-
- [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
- RFC 3062, February 2001.
-
- [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
- (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-Zeilenga Best Current Practice [Page 15]
-
-RFC 4521 LDAP Extensions 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 Best Current Practice [Page 16]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4522.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4522.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4522.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group S. Legg
-Request for Comments: 4522 eB2Bcom
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP):
- The Binary Encoding Option
-
-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 has a defined syntax (i.e., data type). A syntax
- definition specifies how attribute values conforming to the syntax
- are normally represented when transferred in LDAP operations. This
- representation is referred to as the LDAP-specific encoding to
- distinguish it from other methods of encoding attribute values. This
- document defines an attribute option, the binary option, that can be
- used to specify that the associated attribute values are instead
- encoded according to the Basic Encoding Rules (BER) used by X.500
- directories.
-
-Table of Contents
-
- 1. Introduction ....................................................2
- 2. Conventions .....................................................2
- 3. The Binary Option ...............................................2
- 4. Syntaxes Requiring Binary Transfer ..............................3
- 5. Attributes Returned in a Search .................................4
- 6. All User Attributes .............................................4
- 7. Conflicting Requests ............................................5
- 8. Security Considerations .........................................5
- 9. IANA Considerations .............................................5
- 10. References .....................................................5
- 10.1. Normative References ......................................5
- 10.2. Informative References ....................................6
-
-
-
-
-Legg Standards Track [Page 1]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
-1. Introduction
-
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory [RFC4510] has a defined syntax (i.e., data type)
- which constrains the structure and format of its values.
-
- The description of each syntax [RFC4517] specifies how attribute or
- assertion values [RFC4512] conforming to the syntax are normally
- represented when transferred in LDAP operations [RFC4511]. This
- representation is referred to as the LDAP-specific encoding to
- distinguish it from other methods of encoding attribute values.
-
- This document defines an attribute option, the binary option, which
- can be used in an attribute description [RFC4512] in an LDAP
- operation to specify that the associated attribute values or
- assertion values are, or are requested to be, encoded according to
- the Basic Encoding Rules (BER) [BER] as used by X.500 [X.500]
- directories, instead of the usual LDAP-specific encoding.
-
- The binary option was originally defined in RFC 2251 [RFC2251]. The
- LDAP technical specification [RFC4510] has obsoleted the previously
- defined LDAP technical specification [RFC3377], which included RFC
- 2251. The binary option was not included in the revised LDAP
- technical specification for a variety of reasons including
- implementation inconsistencies. No attempt is made here to resolve
- the known inconsistencies.
-
- This document reintroduces the binary option for use with certain
- attribute syntaxes, such as certificate syntax [RFC4523], that
- specifically require it. No attempt has been made to address use of
- the binary option with attributes of syntaxes that do not require its
- use. Unless addressed in a future specification, this use is to be
- avoided.
-
-2. 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, RFC 2119
- [BCP14].
-
-3. The Binary Option
-
- The binary option is indicated with the attribute option string
- "binary" in an attribute description. Note that, like all attribute
- options, the string representing the binary option is case
- insensitive.
-
-
-
-
-Legg Standards Track [Page 2]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
- Where the binary option is present in an attribute description, the
- associated attribute values or assertion values MUST be BER encoded
- (otherwise the values are encoded according to the LDAP-specific
- encoding [RFC4517] for the attribute's syntax). Note that it is
- possible for a syntax to be defined such that its LDAP-specific
- encoding is exactly the same as its BER encoding.
-
- In terms of the protocol [RFC4511], the binary option specifies that
- the contents octets of the associated AttributeValue or
- AssertionValue OCTET STRING are a complete BER encoding of the
- relevant value.
-
- The binary option is not a tagging option [RFC4512], so the presence
- of the binary option does not specify an attribute subtype. An
- attribute description containing the binary option references exactly
- the same attribute as the attribute description without the binary
- option. The supertype/subtype relationships of attributes with
- tagging options are not altered in any way by the presence or absence
- of the binary option.
-
- An attribute description SHALL be treated as unrecognized if it
- contains the binary option and the syntax of the attribute does not
- have an associated ASN.1 type [RFC4517], or the BER encoding of
- values of that type is not supported.
-
- The presence or absence of the binary option only affects the
- transfer of attribute and assertion values in the protocol; servers
- store any particular attribute value in a format of their choosing.
-
-4. Syntaxes Requiring Binary Transfer
-
- The attribute values of certain attribute syntaxes are defined
- without an LDAP-specific encoding and are required to be transferred
- in the BER-encoded form. For the purposes of this document, these
- syntaxes are said to have a binary transfer requirement. The
- certificate, certificate list, certificate pair, and supported
- algorithm syntaxes [RFC4523] are examples of syntaxes with a binary
- transfer requirement. These syntaxes also have an additional
- requirement that the exact BER encoding must be preserved. Note that
- this is a property of the syntaxes themselves, and not a property of
- the binary option. In the absence of this requirement, LDAP clients
- would need to re-encode values using the Distinguished Encoding Rules
- (DER).
-
-
-
-
-
-
-
-
-Legg Standards Track [Page 3]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
-5. Attributes Returned in a Search
-
- An LDAP search request [RFC4511] contains a list of the attributes
- (the requested attributes list) to be returned from each entry
- matching the search filter. An attribute description in the
- requested attributes list also implicitly requests all subtypes of
- the attribute type in the attribute description, whether through
- attribute subtyping or attribute tagging option subtyping [RFC4512].
-
- The requested attributes list MAY contain attribute descriptions with
- the binary option, but MUST NOT contain two attribute descriptions
- with the same attribute type and the same tagging options (even if
- only one of them has the binary option). The binary option in an
- attribute description in the requested attributes list implicitly
- applies to all the subtypes of the attribute type in the attribute
- description (however, see Section 7).
-
- Attributes of a syntax with the binary transfer requirement, if
- returned, SHALL be returned in the binary form (i.e., with the binary
- option in the attribute description and the associated attribute
- values BER encoded) regardless of whether the binary option was
- present in the request (for the attribute or for one of its
- supertypes).
-
- Attributes of a syntax without the binary transfer requirement, if
- returned, SHOULD be returned in the form explicitly requested. That
- is, if the attribute description in the requested attributes list
- contains the binary option, then the corresponding attribute in the
- result SHOULD be in the binary form. If the attribute description in
- the request does not contain the binary option, then the
- corresponding attribute in the result SHOULD NOT be in the binary
- form. A server MAY omit an attribute from the result if it does not
- support the requested encoding.
-
- Regardless of the encoding chosen, a particular attribute value is
- returned at most once.
-
-6. All User Attributes
-
- If the list of attributes in a search request is empty or contains
- the special attribute description string "*", then all user
- attributes are requested to be returned.
-
- Attributes of a syntax with the binary transfer requirement, if
- returned, SHALL be returned in the binary form.
-
-
-
-
-
-
-Legg Standards Track [Page 4]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
- Attributes of a syntax without the binary transfer requirement and
- having a defined LDAP-specific encoding SHOULD NOT be returned in the
- binary form.
-
- Attributes of a syntax without the binary transfer requirement and
- without a defined LDAP-specific encoding may be returned in the
- binary form or omitted from the result.
-
-7. Conflicting Requests
-
- A particular attribute could be explicitly requested by an attribute
- description and/or implicitly requested by the attribute descriptions
- of one or more of its supertypes, or by the special attribute
- description string "*". If the binary option is present in at least
- one, but not all, of these attribute descriptions then the effect of
- the request with respect to binary transfer is implementation
- defined.
-
-8. Security Considerations
-
- When interpreting security-sensitive fields, and 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.
-
-9. IANA Considerations
-
- The Internet Assigned Numbers Authority (IANA) has updated the LDAP
- attribute description option registry [BCP64] as indicated by the
- following template:
-
- Subject:
- Request for LDAP Attribute Description Option Registration
- Option Name: binary
- Family of Options: NO
- Person & email address to contact for further information:
- Steven Legg <steven.legg at eb2bcom.com>
- Specification: RFC 4522
- Author/Change Controller: IESG
-
-10. References
-
-10.1. Normative References
-
- [BCP14] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Legg Standards Track [Page 5]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
- [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
- (LDAP): Technical Specification Road Map", RFC RFC 4510,
- June 2006.
-
- [RFC4511] Sermersheim, J., "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.
-
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
- (LDAP): Syntaxes and Matching Rules", RFC 4517, June
- 2006.
-
- [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Schema Definitions for X.509 Certificates", RFC
- 4523, June 2006.
-
- [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1,
- Information Technology - ASN.1 encoding rules:
- Specification of Basic Encoding Rules (BER), Canonical
- Encoding Rules (CER) and Distinguished Encoding Rules
- (DER).
-
-10.2. Informative References
-
- [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [X.500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001,
- Information technology - Open Systems Interconnection -
- The Directory: Overview of concepts, models and services
-
-
-
-
-
-
-
-
-
-
-Legg Standards Track [Page 6]
-
-RFC 4522 LDAP: The Binary Encoding Option June 2006
-
-
-Author's Address
-
- Dr. Steven Legg
- eB2Bcom
- Suite 3, 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 7]
-
-RFC 4522 LDAP: The Binary Encoding Option 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).
-
-
-
-
-
-
-
-Legg Standards Track [Page 8]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4523.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4523.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4523.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1347 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4523 OpenLDAP Foundation
-Obsoletes: 2252, 2256, 2587 June 2006
-Category: Standards Track
-
-
- Lightweight Directory Access Protocol (LDAP)
- Schema Definitions for X.509 Certificates
-
-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 schema for representing X.509 certificates,
- X.521 security information, and related elements in directories
- accessible using the Lightweight Directory Access Protocol (LDAP).
- The LDAP definitions for these X.509 and X.521 schema elements
- replace those provided in RFCs 2252 and 2256.
-
-1. Introduction
-
- This document provides LDAP [RFC4510] schema definitions [RFC4512]
- for a subset of elements specified in X.509 [X.509] and X.521
- [X.521], including attribute types for certificates, cross
- certificate pairs, and certificate revocation lists; matching rules
- to be used with these attribute types; and related object classes.
- LDAP syntax definitions are also provided for associated assertion
- and attribute values.
-
- As the semantics of these elements are as defined in X.509 and X.521,
- knowledge of X.509 and X.521 is necessary to make use of the LDAP
- schema definitions provided herein.
-
- This document, together with [RFC4510], obsoletes RFCs 2252 and 2256
- in their entirety. The changes (in this document) made since RFC
- 2252 and RFC 2256 include:
-
- - addition of pkiUser, pkiCA, and deltaCRL classes;
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- - update of attribute types to include equality matching rules in
- accordance with their X.500 specifications;
-
- - addition of certificate, certificate pair, certificate list,
- and algorithm identifier matching rules; and
-
- - addition of LDAP syntax for assertion syntaxes for these
- matching rules.
-
- This document obsoletes RFC 2587. The X.509 schema descriptions for
- LDAPv2 [RFC1777] are Historic, as is LDAPv2 [RFC3494].
-
- 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
- [RFC4512]. Definitions provided here are formatted (line wrapped)
- for readability.
-
-2. Syntaxes
-
- This section describes various syntaxes used in LDAP to transfer
- certificates and related data types.
-
-2.1. Certificate
-
- ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'X.509 Certificate' )
-
- A value of this syntax is an X.509 Certificate [X.509, clause 7].
-
- Due to changes made to the definition of a Certificate through time,
- no LDAP-specific encoding is defined for this syntax. Values of this
- syntax SHOULD be encoded using Distinguished Encoding Rules (DER)
- [X.690] and MUST only be transferred using the ;binary transfer
- option [RFC4522]; that is, by requesting and returning values using
- attribute descriptions such as "userCertificate;binary".
-
- As values of this syntax contain digitally signed data, values of
- this syntax and the form of each value MUST be preserved as
- presented.
-
-2.2. CertificateList
-
- ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'X.509 Certificate List' )
-
- A value of this syntax is an X.509 CertificateList [X.509, clause
- 7.3].
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- Due to changes made to the definition of a CertificateList through
- time, no LDAP-specific encoding is defined for this syntax. Values
- of this syntax SHOULD be encoded using DER [X.690] and MUST only be
- transferred using the ;binary transfer option [RFC4522]; that is, by
- requesting and returning values using attribute descriptions such as
- "certificateRevocationList;binary".
-
- As values of this syntax contain digitally signed data, values of
- this syntax and the form of each value MUST be preserved as
- presented.
-
-2.3. CertificatePair
-
- ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'X.509 Certificate Pair' )
-
- A value of this syntax is an X.509 CertificatePair [X.509, clause
- 11.2.3].
-
- Due to changes made to the definition of an X.509 CertificatePair
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [RFC4522]; that
- is, by requesting and returning values using attribute descriptions
- such as "crossCertificatePair;binary".
-
- As values of this syntax contain digitally signed data, values of
- this syntax and the form of each value MUST be preserved as
- presented.
-
-2.4. SupportedAlgorithm
-
- ( 1.3.6.1.4.1.1466.115.121.1.49
- DESC 'X.509 Supported Algorithm' )
-
- A value of this syntax is an X.509 SupportedAlgorithm [X.509, clause
- 11.2.7].
-
- Due to changes made to the definition of an X.509 SupportedAlgorithm
- through time, no LDAP-specific encoding is defined for this syntax.
- Values of this syntax SHOULD be encoded using DER [X.690] and MUST
- only be transferred using the ;binary transfer option [RFC4522]; that
- is, by requesting and returning values using attribute descriptions
- such as "supportedAlgorithms;binary".
-
- As values of this syntax contain digitally signed data, values of
- this syntax and the form of the value MUST be preserved as presented.
-
-
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-2.5. CertificateExactAssertion
-
- ( 1.3.6.1.1.15.1 DESC 'X.509 Certificate Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateExactAssertion [X.509,
- clause 11.3.1]. Values of this syntax MUST be encoded using the
- Generic String Encoding Rules (GSER) [RFC3641]. Appendix A.1
- provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC4234]
- grammar for this syntax.
-
-2.6. CertificateAssertion
-
- ( 1.3.6.1.1.15.2 DESC 'X.509 Certificate Assertion' )
-
- A value of this syntax is an X.509 CertificateAssertion [X.509,
- clause 11.3.2]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.2 provides an equivalent ABNF [RFC4234]
- grammar for this syntax.
-
-2.7. CertificatePairExactAssertion
-
- ( 1.3.6.1.1.15.3
- DESC 'X.509 Certificate Pair Exact Assertion' )
-
- A value of this syntax is an X.509 CertificatePairExactAssertion
- [X.509, clause 11.3.3]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.3 provides an equivalent ABNF [RFC4234]
- grammar for this syntax.
-
-2.8. CertificatePairAssertion
-
- ( 1.3.6.1.1.15.4 DESC 'X.509 Certificate Pair Assertion' )
-
- A value of this syntax is an X.509 CertificatePairAssertion [X.509,
- clause 11.3.4]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.4 provides an equivalent ABNF [RFC4234]
- grammar for this syntax.
-
-2.9. CertificateListExactAssertion
-
- ( 1.3.6.1.1.15.5
- DESC 'X.509 Certificate List Exact Assertion' )
-
- A value of this syntax is an X.509 CertificateListExactAssertion
- [X.509, clause 11.3.5]. Values of this syntax MUST be encoded using
- GSER [RFC3641]. Appendix A.5 provides an equivalent ABNF grammar for
- this syntax.
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-2.10. CertificateListAssertion
-
- ( 1.3.6.1.1.15.6 DESC 'X.509 Certificate List Assertion' )
-
- A value of this syntax is an X.509 CertificateListAssertion [X.509,
- clause 11.3.6]. Values of this syntax MUST be encoded using GSER
- [RFC3641]. Appendix A.6 provides an equivalent ABNF [RFC4234]
- grammar for this syntax.
-
-2.11. AlgorithmIdentifier
-
- ( 1.3.6.1.1.15.7 DESC 'X.509 Algorithm Identifier' )
-
- A value of this syntax is an X.509 AlgorithmIdentifier [X.509, Clause
- 7]. Values of this syntax MUST be encoded using GSER [RFC3641].
-
- Appendix A.7 provides an equivalent ABNF [RFC4234] grammar for this
- syntax.
-
-3. Matching Rules
-
- This section introduces a set of certificate and related matching
- rules for use in LDAP. These rules are intended to act in accordance
- with their X.500 counterparts.
-
-3.1. certificateExactMatch
-
- The certificateExactMatch matching rule compares the presented
- certificate exact assertion value with an attribute value of the
- certificate syntax as described in clause 11.3.1 of [X.509].
-
- ( 2.5.13.34 NAME 'certificateExactMatch'
- DESC 'X.509 Certificate Exact Match'
- SYNTAX 1.3.6.1.1.15.1 )
-
-3.2. certificateMatch
-
- The certificateMatch matching rule compares the presented certificate
- assertion value with an attribute value of the certificate syntax as
- described in clause 11.3.2 of [X.509].
-
- ( 2.5.13.35 NAME 'certificateMatch'
- DESC 'X.509 Certificate Match'
- SYNTAX 1.3.6.1.1.15.2 )
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-3.3. certificatePairExactMatch
-
- The certificatePairExactMatch matching rule compares the presented
- certificate pair exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.3 of [X.509].
-
- ( 2.5.13.36 NAME 'certificatePairExactMatch'
- DESC 'X.509 Certificate Pair Exact Match'
- SYNTAX 1.3.6.1.1.15.3 )
-
-3.4. certificatePairMatch
-
- The certificatePairMatch matching rule compares the presented
- certificate pair assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.4 of [X.509].
-
- ( 2.5.13.37 NAME 'certificatePairMatch'
- DESC 'X.509 Certificate Pair Match'
- SYNTAX 1.3.6.1.1.15.4 )
-
-3.5. certificateListExactMatch
-
- The certificateListExactMatch matching rule compares the presented
- certificate list exact assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.5 of [X.509].
-
- ( 2.5.13.38 NAME 'certificateListExactMatch'
- DESC 'X.509 Certificate List Exact Match'
- SYNTAX 1.3.6.1.1.15.5 )
-
-3.6. certificateListMatch
-
- The certificateListMatch matching rule compares the presented
- certificate list assertion value with an attribute value of the
- certificate pair syntax as described in clause 11.3.6 of [X.509].
-
- ( 2.5.13.39 NAME 'certificateListMatch'
- DESC 'X.509 Certificate List Match'
- SYNTAX 1.3.6.1.1.15.6 )
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 6]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-3.7. algorithmIdentifierMatch
-
- The algorithmIdentifierMatch mating rule compares a presented
- algorithm identifier with an attribute value of the supported
- algorithm as described in clause 11.3.7 of [X.509].
-
- ( 2.5.13.40 NAME 'algorithmIdentifier'
- DESC 'X.509 Algorithm Identifier Match'
- SYNTAX 1.3.6.1.1.15.7 )
-
-4. Attribute Types
-
- This section details a set of certificate and related attribute types
- for use in LDAP.
-
-4.1. userCertificate
-
- The userCertificate attribute holds the X.509 certificates issued to
- the user by one or more certificate authorities, as discussed in
- clause 11.2.1 of [X.509].
-
- ( 2.5.4.36 NAME 'userCertificate'
- DESC 'X.509 user certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "userCertificate;binary".
-
-4.2. cACertificate
-
- The cACertificate attribute holds the X.509 certificates issued to
- the certificate authority (CA), as discussed in clause 11.2.2 of
- [X.509].
-
- ( 2.5.4.37 NAME 'cACertificate'
- DESC 'X.509 CA certificate'
- EQUALITY certificateExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "cACertificate;binary".
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 7]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-4.3. crossCertificatePair
-
- The crossCertificatePair attribute holds an X.509 certificate pair,
- as discussed in clause 11.2.3 of [X.509].
-
- ( 2.5.4.40 NAME 'crossCertificatePair'
- DESC 'X.509 cross certificate pair'
- EQUALITY certificatePairExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "crossCertificatePair;binary".
-
-4.4. certificateRevocationList
-
- The certificateRevocationList attribute holds certificate lists, as
- discussed in 11.2.4 of [X.509].
-
- ( 2.5.4.39 NAME 'certificateRevocationList'
- DESC 'X.509 certificate revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "certificateRevocationList;binary".
-
-4.5. authorityRevocationList
-
- The authorityRevocationList attribute holds certificate lists, as
- discussed in 11.2.5 of [X.509].
-
- ( 2.5.4.38 NAME 'authorityRevocationList'
- DESC 'X.509 authority revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- are requested and transferred using the attribute description
- "authorityRevocationList;binary".
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 8]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-4.6. deltaRevocationList
-
- The deltaRevocationList attribute holds certificate lists, as
- discussed in 11.2.6 of [X.509].
-
- ( 2.5.4.53 NAME 'deltaRevocationList'
- DESC 'X.509 delta revocation list'
- EQUALITY certificateListExactMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "deltaRevocationList;binary".
-
-4.7. supportedAlgorithms
-
- The supportedAlgorithms attribute holds supported algorithms, as
- discussed in 11.2.7 of [X.509].
-
- ( 2.5.4.52 NAME 'supportedAlgorithms'
- DESC 'X.509 supported algorithms'
- EQUALITY algorithmIdentifierMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.49 )
-
- As required by this attribute type's syntax, values of this attribute
- MUST be requested and transferred using the attribute description
- "supportedAlgorithms;binary".
-
-5. Object Classes
-
- This section details a set of certificate-related object classes for
- use in LDAP.
-
-5.1. pkiUser
-
- This object class is used in augment entries for objects that may be
- subject to certificates, as defined in clause 11.1.1 of [X.509].
-
- ( 2.5.6.21 NAME 'pkiUser'
- DESC 'X.509 PKI User'
- SUP top AUXILIARY
- MAY userCertificate )
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 9]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-5.2. pkiCA
-
- This object class is used to augment entries for objects that act as
- certificate authorities, as defined in clause 11.1.2 of [X.509]
-
- ( 2.5.6.22 NAME 'pkiCA'
- DESC 'X.509 PKI Certificate Authority'
- SUP top AUXILIARY
- MAY ( cACertificate $ certificateRevocationList $
- authorityRevocationList $ crossCertificatePair ) )
-
-5.3. cRLDistributionPoint
-
- This class is used to represent objects that act as CRL distribution
- points, as discussed in clause 11.1.3 of [X.509].
-
- ( 2.5.6.19 NAME 'cRLDistributionPoint'
- DESC 'X.509 CRL distribution point'
- SUP top STRUCTURAL
- MUST cn
- MAY ( certificateRevocationList $
- authorityRevocationList $ deltaRevocationList ) )
-
-5.4. deltaCRL
-
- The deltaCRL object class is used to augment entries to hold delta
- revocation lists, as discussed in clause 11.1.4 of [X.509].
-
- ( 2.5.6.23 NAME 'deltaCRL'
- DESC 'X.509 delta CRL'
- SUP top AUXILIARY
- MAY deltaRevocationList )
-
-5.5. strongAuthenticationUser
-
- This object class is used to augment entries for objects
- participating in certificate-based authentication, as defined in
- clause 6.15 of [X.521]. This object class is deprecated in favor of
- pkiUser.
-
- ( 2.5.6.15 NAME 'strongAuthenticationUser'
- DESC 'X.521 strong authentication user'
- SUP top AUXILIARY
- MUST userCertificate )
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 10]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-5.6. userSecurityInformation
-
- This object class is used to augment entries with needed additional
- associated security information, as defined in clause 6.16 of
- [X.521].
-
- ( 2.5.6.18 NAME 'userSecurityInformation'
- DESC 'X.521 user security information'
- SUP top AUXILIARY
- MAY ( supportedAlgorithms ) )
-
-5.7. certificationAuthority
-
- This object class is used to augment entries for objects that act as
- certificate authorities, as defined in clause 6.17 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16 NAME 'certificationAuthority'
- DESC 'X.509 certificate authority'
- SUP top AUXILIARY
- MUST ( authorityRevocationList $
- certificateRevocationList $ cACertificate )
- MAY crossCertificatePair )
-
-5.8. certificationAuthority-V2
-
- This object class is used to augment entries for objects that act as
- certificate authorities, as defined in clause 6.18 of [X.521]. This
- object class is deprecated in favor of pkiCA.
-
- ( 2.5.6.16.2 NAME 'certificationAuthority-V2'
- DESC 'X.509 certificate authority, version 2'
- SUP certificationAuthority AUXILIARY
- MAY deltaRevocationList )
-
-6. Security Considerations
-
- General certificate considerations [RFC3280] apply to LDAP-aware
- certificate applications. General LDAP security considerations
- [RFC4510] apply as well.
-
- While elements of certificate information are commonly signed, these
- signatures only protect the integrity of the signed information. In
- the absence of data integrity protections in LDAP (or lower layer,
- e.g., IPsec), a server is not assured that client certificate request
- (or other request) was unaltered in transit. Likewise, a client
- cannot be assured that the results of the query were unaltered in
-
-
-
-
-Zeilenga Standards Track [Page 11]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- transit. Hence, it is generally recommended that implementations
- make use of authentication and data integrity services in LDAP
- [RFC4513][RFC4511].
-
-7. IANA Considerations
-
-7.1. Object Identifier Registration
-
- The IANA has registered an LDAP Object Identifier [RFC4520] for use
- in this technical specification.
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4523
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP X.509 Certificate schema elements
- introduced in this document.
-
-7.2. Descriptor Registration
-
- The IANA has updated the LDAP
- Descriptor registry [RFC44520] as indicated below.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): see table
- Object Identifier: see table
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Usage: see table
- Specification: RFC 4523
- Author/Change Controller: IESG
-
- algorithmIdentifierMatch M 2.5.13.40
- authorityRevocationList A 2.5.4.38 *
- cACertificate A 2.5.4.37 *
- cRLDistributionPoint O 2.5.6.19 *
- certificateExactMatch M 2.5.13.34
- certificateListExactMatch M 2.5.13.38
- certificateListMatch M 2.5.13.39
- certificateMatch M 2.5.13.35
- certificatePairExactMatch M 2.5.13.36
- certificatePairMatch M 2.5.13.37
- certificateRevocationList A 2.5.4.39 *
- certificationAuthority O 2.5.6.16 *
- certificationAuthority-V2 O 2.5.6.16.2 *
- crossCertificatePair A 2.5.4.40 *
-
-
-
-Zeilenga Standards Track [Page 12]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- deltaCRL O 2.5.6.23 *
- deltaRevocationList A 2.5.4.53 *
- pkiCA O 2.5.6.22 *
- pkiUser O 2.5.6.21 *
- strongAuthenticationUser O 2.5.6.15 *
- supportedAlgorithms A 2.5.4.52 *
- userCertificate A 2.5.4.36 *
- userSecurityInformation O 2.5.6.18 *
-
- * Updates previous registration
-
-8. Acknowledgements
-
- This document is based on X.509, a product of the ITU-T. A number of
- LDAP schema definitions were based on those found in RFCs 2252 and
- 2256, both products of the IETF ASID WG. The ABNF productions in
- Appendix A were provided by Steven Legg. Additional material was
- borrowed from prior works by David Chadwick and Steven Legg to refine
- the LDAP X.509 schema.
-
-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.
-
- [RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
- Types", RFC 3641, October 2003.
-
- [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.
-
- [RFC4522] Legg, S., "Lightweight Directory Access Protocol (LDAP):
- The Binary Encoding Option", RFC 4522, June 2006.
-
- [X.509] International Telecommunication Union - Telecommunication
- Standardization Sector, "The Directory: Authentication
- Framework", X.509(2000).
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 13]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- [X.521] International Telecommunication Union - Telecommunication
- Standardization Sector, "The Directory: Selected Object
- Classes", X.521(2000).
-
- [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(2002) (also ISO/IEC 8825-1:2002).
-
-9.2. Informative References
-
- [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol", RFC 1777, March 1995.
-
- [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
- Mapping between X.400 and RFC 822/MIME", RFC 2156, January
- 1998.
-
- [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
- X.509 Public Key Infrastructure Certificate and
- Certificate Revocation List (CRL) Profile", RFC 3280,
- April 2002.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [RFC3642] Legg, S., "Common Elements of Generic String Encoding
- Rules (GSER) Encodings", RFC 3642, October 2003.
-
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [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.
-
- [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 14]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-Appendix A.
-
- This appendix is informative.
-
- This appendix provides ABNF [RFC4234] grammars for GSER-based
- [RFC3641] LDAP-specific encodings specified in this document. These
- grammars where produced using, and relying on, Common Elements for
- GSER Encodings [RFC3642].
-
-A.1. CertificateExactAssertion
-
- CertificateExactAssertion = "{" sp cea-serialNumber ","
- sp cea-issuer sp "}"
-
- cea-serialNumber = id-serialNumber msp CertificateSerialNumber
- cea-issuer = id-issuer msp Name
-
- id-serialNumber =
- %x73.65.72.69.61.6C.4E.75.6D.62.65.72 ; 'serialNumber'
- id-issuer = %x69.73.73.75.65.72 ; 'issuer'
-
- Name = id-rdnSequence ":" RDNSequence
- id-rdnSequence = %x72.64.6E.53.65.71.75.65.6E.63.65 ; 'rdnSequence'
-
- CertificateSerialNumber = INTEGER
-
-A.2. CertificateAssertion
-
-CertificateAssertion = "{" [ sp ca-serialNumber ]
- [ sep sp ca-issuer ]
- [ sep sp ca-subjectKeyIdentifier ]
- [ sep sp ca-authorityKeyIdentifier ]
- [ sep sp ca-certificateValid ]
- [ sep sp ca-privateKeyValid ]
- [ sep sp ca-subjectPublicKeyAlgID ]
- [ sep sp ca-keyUsage ]
- [ sep sp ca-subjectAltName ]
- [ sep sp ca-policy ]
- [ sep sp ca-pathToName ]
- [ sep sp ca-subject ]
- [ sep sp ca-nameConstraints ] sp "}"
-
-ca-serialNumber = id-serialNumber msp CertificateSerialNumber
-ca-issuer = id-issuer msp Name
-ca-subjectKeyIdentifier = id-subjectKeyIdentifier msp
- SubjectKeyIdentifier
-ca-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
-
-
-
-Zeilenga Standards Track [Page 15]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-ca-certificateValid = id-certificateValid msp Time
-ca-privateKeyValid = id-privateKeyValid msp GeneralizedTime
-ca-subjectPublicKeyAlgID = id-subjectPublicKeyAlgID msp
- OBJECT-IDENTIFIER
-ca-keyUsage = id-keyUsage msp KeyUsage
-ca-subjectAltName = id-subjectAltName msp AltNameType
-ca-policy = id-policy msp CertPolicySet
-ca-pathToName = id-pathToName msp Name
-ca-subject = id-subject msp Name
-ca-nameConstraints = id-nameConstraints msp NameConstraintsSyntax
-
-id-subjectKeyIdentifier =
- %x73.75.62.6A.65.63.74.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'subjectKeyIdentifier'
-id-authorityKeyIdentifier =
- %x61.75.74.68.6F.72.69.74.79.4B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'authorityKeyIdentifier'
-id-certificateValid = %x63.65.72.74.69.66.69.63.61.74.65.56.61.6C.69.64
- ; 'certificateValid'
-id-privateKeyValid = %x70.72.69.76.61.74.65.4B.65.79.56.61.6C.69.64
- ; 'privateKeyValid'
-id-subjectPublicKeyAlgID =
- %x73.75.62.6A.65.63.74.50.75.62.6C.69.63.4B.65.79.41.6C.67.49.44
- ; 'subjectPublicKeyAlgID'
-id-keyUsage = %x6B.65.79.55.73.61.67.65 ; 'keyUsage'
-id-subjectAltName = %x73.75.62.6A.65.63.74.41.6C.74.4E.61.6D.65
- ; 'subjectAltName'
-id-policy = %x70.6F.6C.69.63.79 ; 'policy'
-id-pathToName = %x70.61.74.68.54.6F.4E.61.6D.65 ; 'pathToName'
-id-subject = %x73.75.62.6A.65.63.74 ; 'subject'
-id-nameConstraints = %x6E.61.6D.65.43.6F.6E.73.74.72.61.69.6E.74.73
- ; 'nameConstraints'
-
-SubjectKeyIdentifier = KeyIdentifier
-
-KeyIdentifier = OCTET-STRING
-
-AuthorityKeyIdentifier = "{" [ sp aki-keyIdentifier ]
- [ sep sp aki-authorityCertIssuer ]
- [ sep sp aki-authorityCertSerialNumber ] sp "}"
-
-aki-keyIdentifier = id-keyIdentifier msp KeyIdentifier
-aki-authorityCertIssuer = id-authorityCertIssuer msp GeneralNames
-
-GeneralNames = "{" sp GeneralName *( "," sp GeneralName ) sp "}"
-GeneralName = gn-otherName
- / gn-rfc822Name
- / gn-dNSName
-
-
-
-Zeilenga Standards Track [Page 16]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- / gn-x400Address
- / gn-directoryName
- / gn-ediPartyName
- / gn-uniformResourceIdentifier
- / gn-iPAddress
- / gn-registeredID
-
-gn-otherName = id-otherName ":" OtherName
-gn-rfc822Name = id-rfc822Name ":" IA5String
-gn-dNSName = id-dNSName ":" IA5String
-gn-x400Address = id-x400Address ":" ORAddress
-gn-directoryName = id-directoryName ":" Name
-gn-ediPartyName = id-ediPartyName ":" EDIPartyName
-gn-iPAddress = id-iPAddress ":" OCTET-STRING
-gn-registeredID = gn-id-registeredID ":" OBJECT-IDENTIFIER
-
-gn-uniformResourceIdentifier = id-uniformResourceIdentifier
- ":" IA5String
-
-id-otherName = %x6F.74.68.65.72.4E.61.6D.65 ; 'otherName'
-gn-id-registeredID = %x72.65.67.69.73.74.65.72.65.64.49.44
- ; 'registeredID'
-
-OtherName = "{" sp on-type-id "," sp on-value sp "}"
-on-type-id = id-type-id msp OBJECT-IDENTIFIER
-on-value = id-value msp Value
- ;; <Value> as defined in Section 3 of [RFC3641]
-
-id-type-id = %x74.79.70.65.2D.69.64 ; 'type-id'
-id-value = %x76.61.6C.75.65 ; 'value'
-
-ORAddress = dquote *SafeIA5Character dquote
-SafeIA5Character = %x01-21 / %x23-7F / ; ASCII minus dquote
- dquote dquote ; escaped double quote
-dquote = %x22 ; '"' (double quote)
-
-;; Note: The <ORAddress> rule encodes the x400Address component
-;; of a GeneralName as a character string between double quotes.
-;; The character string is first derived according to Section 4.1
-;; of [RFC2156], and then any embedded double quotes are escaped
-;; by being repeated. This resulting string is output between
-;; double quotes.
-
-EDIPartyName = "{" [ sp nameAssigner "," ] sp partyName sp "}"
-nameAssigner = id-nameAssigner msp DirectoryString
-partyName = id-partyName msp DirectoryString
-id-nameAssigner = %x6E.61.6D.65.41.73.73.69.67.6E.65.72
- ; 'nameAssigner'
-
-
-
-Zeilenga Standards Track [Page 17]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-id-partyName = %x70.61.72.74.79.4E.61.6D.65 ; 'partyName'
-
-aki-authorityCertSerialNumber = id-authorityCertSerialNumber
- msp CertificateSerialNumber
-
-id-keyIdentifier = %x6B.65.79.49.64.65.6E.74.69.66.69.65.72
- ; 'keyIdentifier'
-id-authorityCertIssuer =
- %x61.75.74.68.6F.72.69.74.79.43.65.72.74.49.73.73.75.65.72
- ; 'authorityCertIssuer'
-
-id-authorityCertSerialNumber = %x61.75.74.68.6F.72.69.74.79.43
- %x65.72.74.53.65.72.69.61.6C.4E.75.6D.62.65.72
- ; 'authorityCertSerialNumber'
-
-Time = time-utcTime / time-generalizedTime
-time-utcTime = id-utcTime ":" UTCTime
-time-generalizedTime = id-generalizedTime ":" GeneralizedTime
-id-utcTime = %x75.74.63.54.69.6D.65 ; 'utcTime'
-id-generalizedTime = %x67.65.6E.65.72.61.6C.69.7A.65.64.54.69.6D.65
- ; 'generalizedTime'
-
-KeyUsage = BIT-STRING / key-usage-bit-list
-key-usage-bit-list = "{" [ sp key-usage *( "," sp key-usage ) ] sp "}"
-
-;; Note: The <key-usage-bit-list> rule encodes the one bits in
-;; a KeyUsage value as a comma separated list of identifiers.
-
-key-usage = id-digitalSignature
- / id-nonRepudiation
- / id-keyEncipherment
- / id-dataEncipherment
- / id-keyAgreement
- / id-keyCertSign
- / id-cRLSign
- / id-encipherOnly
- / id-decipherOnly
-
-id-digitalSignature = %x64.69.67.69.74.61.6C.53.69.67.6E.61.74
- %x75.72.65 ; 'digitalSignature'
-id-nonRepudiation = %x6E.6F.6E.52.65.70.75.64.69.61.74.69.6F.6E
- ; 'nonRepudiation'
-id-keyEncipherment = %x6B.65.79.45.6E.63.69.70.68.65.72.6D.65.6E.74
- ; 'keyEncipherment'
-id-dataEncipherment = %x64.61.74.61.45.6E.63.69.70.68.65.72.6D.65.6E
- %x74 ; "dataEncipherment'
-id-keyAgreement = %x6B.65.79.41.67.72.65.65.6D.65.6E.74
- ; 'keyAgreement'
-
-
-
-Zeilenga Standards Track [Page 18]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-id-keyCertSign = %x6B.65.79.43.65.72.74.53.69.67.6E
- ; 'keyCertSign'
-id-cRLSign = %x63.52.4C.53.69.67.6E ; "cRLSign"
-id-encipherOnly = %x65.6E.63.69.70.68.65.72.4F.6E.6C.79
- ; 'encipherOnly'
-id-decipherOnly = %x64.65.63.69.70.68.65.72.4F.6E.6C.79
- ; 'decipherOnly'
-
-AltNameType = ant-builtinNameForm / ant-otherNameForm
-
-ant-builtinNameForm = id-builtinNameForm ":" BuiltinNameForm
-ant-otherNameForm = id-otherNameForm ":" OBJECT-IDENTIFIER
-
-id-builtinNameForm = %x62.75.69.6C.74.69.6E.4E.61.6D.65.46.6F.72.6D
- ; 'builtinNameForm'
-id-otherNameForm = %x6F.74.68.65.72.4E.61.6D.65.46.6F.72.6D
- ; 'otherNameForm'
-
-BuiltinNameForm = id-rfc822Name
- / id-dNSName
- / id-x400Address
- / id-directoryName
- / id-ediPartyName
- / id-uniformResourceIdentifier
- / id-iPAddress
- / id-registeredId
-
-id-rfc822Name = %x72.66.63.38.32.32.4E.61.6D.65 ; 'rfc822Name'
-id-dNSName = %x64.4E.53.4E.61.6D.65 ; 'dNSName'
-id-x400Address = %x78.34.30.30.41.64.64.72.65.73.73 ; 'x400Address'
-id-directoryName = %x64.69.72.65.63.74.6F.72.79.4E.61.6D.65
- ; 'directoryName'
-id-ediPartyName = %x65.64.69.50.61.72.74.79.4E.61.6D.65
- ; 'ediPartyName'
-id-iPAddress = %x69.50.41.64.64.72.65.73.73 ; 'iPAddress'
-id-registeredId = %x72.65.67.69.73.74.65.72.65.64.49.64
- ; 'registeredId'
-
-id-uniformResourceIdentifier = %x75.6E.69.66.6F.72.6D.52.65.73.6F.75
- %x72.63.65.49.64.65.6E.74.69.66.69.65.72
- ; 'uniformResourceIdentifier'
-
-CertPolicySet = "{" sp CertPolicyId *( "," sp CertPolicyId ) sp "}"
-CertPolicyId = OBJECT-IDENTIFIER
-
-NameConstraintsSyntax = "{" [ sp ncs-permittedSubtrees ]
- [ sep sp ncs-excludedSubtrees ] sp "}"
-
-
-
-
-Zeilenga Standards Track [Page 19]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-ncs-permittedSubtrees = id-permittedSubtrees msp GeneralSubtrees
-ncs-excludedSubtrees = id-excludedSubtrees msp GeneralSubtrees
-
-id-permittedSubtrees =
- %x70.65.72.6D.69.74.74.65.64.53.75.62.74.72.65.65.73
- ; 'permittedSubtrees'
-id-excludedSubtrees =
- %x65.78.63.6C.75.64.65.64.53.75.62.74.72.65.65.73
- ; 'excludedSubtrees'
-
-GeneralSubtrees = "{" sp GeneralSubtree
- *( "," sp GeneralSubtree ) sp "}"
-GeneralSubtree = "{" sp gs-base
- [ "," sp gs-minimum ]
- [ "," sp gs-maximum ] sp "}"
-
-gs-base = id-base msp GeneralName
-gs-minimum = id-minimum msp BaseDistance
-gs-maximum = id-maximum msp BaseDistance
-
-id-base = %x62.61.73.65 ; 'base'
-id-minimum = %x6D.69.6E.69.6D.75.6D ; 'minimum'
-id-maximum = %x6D.61.78.69.6D.75.6D ; 'maximum'
-
-BaseDistance = INTEGER-0-MAX
-
-A.3. CertificatePairExactAssertion
-
- CertificatePairExactAssertion = "{" [ sp cpea-issuedTo ]
- [sep sp cpea-issuedBy ] sp "}"
- ;; At least one of <cpea-issuedTo> or <cpea-issuedBy> MUST be present.
-
- cpea-issuedTo = id-issuedToThisCAAssertion msp
- CertificateExactAssertion
- cpea-issuedBy = id-issuedByThisCAAssertion msp
- CertificateExactAssertion
-
- id-issuedToThisCAAssertion = %x69.73.73.75.65.64.54.6F.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedToThisCAAssertion'
- id-issuedByThisCAAssertion = %x69.73.73.75.65.64.42.79.54.68.69.73
- %x43.41.41.73.73.65.72.74.69.6F.6E ; 'issuedByThisCAAssertion'
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 20]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
-A.4. CertificatePairAssertion
-
- CertificatePairAssertion = "{" [ sp cpa-issuedTo ]
- [sep sp cpa-issuedBy ] sp "}"
- ;; At least one of <cpa-issuedTo> and <cpa-issuedBy> MUST be present.
-
- cpa-issuedTo = id-issuedToThisCAAssertion msp CertificateAssertion
- cpa-issuedBy = id-issuedByThisCAAssertion msp CertificateAssertion
-
-A.5. CertificateListExactAssertion
-
- CertificateListExactAssertion = "{" sp clea-issuer ","
- sp clea-thisUpdate
- [ "," sp clea-distributionPoint ] sp "}"
-
- clea-issuer = id-issuer msp Name
- clea-thisUpdate = id-thisUpdate msp Time
- clea-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
- id-thisUpdate = %x74.68.69.73.55.70.64.61.74.65 ; 'thisUpdate'
- id-distributionPoint =
- %x64.69.73.74.72.69.62.75.74.69.6F.6E.50.6F.69.6E.74
- ; 'distributionPoint'
-
- DistributionPointName = dpn-fullName / dpn-nameRelativeToCRLIssuer
-
- dpn-fullName = id-fullName ":" GeneralNames
- dpn-nameRelativeToCRLIssuer = id-nameRelativeToCRLIssuer ":"
- RelativeDistinguishedName
-
- id-fullName = %x66.75.6C.6C.4E.61.6D.65 ; 'fullName'
- id-nameRelativeToCRLIssuer = %x6E.61.6D.65.52.65.6C.61.74.69.76.65
- %x54.6F.43.52.4C.49.73.73.75.65.72 ; 'nameRelativeToCRLIssuer'
-
-A.6. CertificateListAssertion
-
- CertificateListAssertion = "{" [ sp cla-issuer ]
- [ sep sp cla-minCRLNumber ]
- [ sep sp cla-maxCRLNumber ]
- [ sep sp cla-reasonFlags ]
- [ sep sp cla-dateAndTime ]
- [ sep sp cla-distributionPoint ]
- [ sep sp cla-authorityKeyIdentifier ] sp "}"
-
- cla-issuer = id-issuer msp Name
- cla-minCRLNumber = id-minCRLNumber msp CRLNumber
- cla-maxCRLNumber = id-maxCRLNumber msp CRLNumber
-
-
-
-Zeilenga Standards Track [Page 21]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- cla-reasonFlags = id-reasonFlags msp ReasonFlags
- cla-dateAndTime = id-dateAndTime msp Time
-
- cla-distributionPoint = id-distributionPoint msp
- DistributionPointName
-
- cla-authorityKeyIdentifier = id-authorityKeyIdentifier msp
- AuthorityKeyIdentifier
-
- id-minCRLNumber = %x6D.69.6E.43.52.4C.4E.75.6D.62.65.72
- ; 'minCRLNumber'
- id-maxCRLNumber = %x6D.61.78.43.52.4C.4E.75.6D.62.65.72
- ; 'maxCRLNumber'
- id-reasonFlags = %x72.65.61.73.6F.6E.46.6C.61.67.73 ; 'reasonFlags'
- id-dateAndTime = %x64.61.74.65.41.6E.64.54.69.6D.65 ; 'dateAndTime'
-
- CRLNumber = INTEGER-0-MAX
-
- ReasonFlags = BIT-STRING
- / "{" [ sp reason-flag *( "," sp reason-flag ) ] sp "}"
-
- reason-flag = id-unused
- / id-keyCompromise
- / id-cACompromise
- / id-affiliationChanged
- / id-superseded
- / id-cessationOfOperation
- / id-certificateHold
- / id-privilegeWithdrawn
- / id-aACompromise
-
- id-unused = %x75.6E.75.73.65.64 ; 'unused'
- id-keyCompromise = %x6B.65.79.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'keyCompromise'
- id-cACompromise = %x63.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'cACompromise'
- id-affiliationChanged =
- %x61.66.66.69.6C.69.61.74.69.6F.6E.43.68.61.6E.67.65.64
- ; 'affiliationChanged'
- id-superseded = %x73.75.70.65.72.73.65.64.65.64 ; 'superseded'
- id-cessationOfOperation =
- %x63.65.73.73.61.74.69.6F.6E.4F.66.4F.70.65.72.61.74.69.6F.6E
- ; 'cessationOfOperation'
- id-certificateHold = %x63.65.72.74.69.66.69.63.61.74.65.48.6F.6C.64
- ; 'certificateHold'
- id-privilegeWithdrawn =
- %x70.72.69.76.69.6C.65.67.65.57.69.74.68.64.72.61.77.6E
- ; 'privilegeWithdrawn'
-
-
-
-Zeilenga Standards Track [Page 22]
-
-RFC 4523 LDAP X.509 Schema June 2006
-
-
- id-aACompromise = %x61.41.43.6F.6D.70.72.6F.6D.69.73.65
- ; 'aACompromise'
-
-A.7. AlgorithmIdentifier
-
- AlgorithmIdentifier = "{" sp ai-algorithm
- [ "," sp ai-parameters ] sp "}"
-
- ai-algorithm = id-algorithm msp OBJECT-IDENTIFIER
- ai-parameters = id-parameters msp Value
- id-algorithm = %x61.6C.67.6F.72.69.74.68.6D ; 'algorithm'
- id-parameters = %x70.61.72.61.6D.65.74.65.72.73 ; 'parameters'
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 23]
-
-RFC 4523 LDAP X.509 Schema 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 24]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4524.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4524.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4524.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1403 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga, Ed.
-Request for Comments: 4524 OpenLDAP Foundation
-Obsoletes: 1274 June 2006
-Updates: 2247, 2798
-Category: Standards Track
-
-
- COSINE LDAP/X.500 Schema
-
-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 provides a collection of schema elements for use with
- the Lightweight Directory Access Protocol (LDAP) from the COSINE and
- Internet X.500 pilot projects.
-
- This document obsoletes RFC 1274 and updates RFCs 2247 and 2798.
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Relationship to Other Documents ............................3
- 1.2. Terminology and Conventions ................................4
- 2. COSINE Attribute Types ..........................................4
- 2.1. associatedDomain ...........................................4
- 2.2. associatedName .............................................5
- 2.3. buildingName ...............................................5
- 2.4. co .........................................................5
- 2.5. documentAuthor .............................................6
- 2.6. documentIdentifier .........................................6
- 2.7. documentLocation ...........................................6
- 2.8. documentPublisher ..........................................7
- 2.9. documentTitle ..............................................7
- 2.10. documentVersion ...........................................7
- 2.11. drink .....................................................8
- 2.12. homePhone .................................................8
- 2.13. homePostalAddress .........................................8
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- 2.14. host ......................................................9
- 2.15. info ......................................................9
- 2.16. mail ......................................................9
- 2.17. manager ..................................................10
- 2.18. mobile ...................................................10
- 2.19. organizationalStatus .....................................11
- 2.20. pager ....................................................11
- 2.21. personalTitle ............................................11
- 2.22. roomNumber ...............................................12
- 2.23. secretary ................................................12
- 2.24. uniqueIdentifier .........................................12
- 2.25. userClass ................................................13
- 3. COSINE Object Classes ..........................................13
- 3.1. account ...................................................13
- 3.2. document ..................................................14
- 3.3. documentSeries ............................................14
- 3.4. domain ....................................................15
- 3.5. domainRelatedObject .......................................16
- 3.6. friendlyCountry ...........................................16
- 3.7. rFC822LocalPart ...........................................17
- 3.8. room ......................................................18
- 3.9. simpleSecurityObject ......................................18
- 4. Security Considerations ........................................18
- 5. IANA Considerations ............................................19
- 6. Acknowledgements ...............................................20
- 7. References .....................................................20
- 7.1. Normative References ......................................20
- 7.2. Informative References ....................................21
- Appendix A. Changes since RFC 1274 ...............................23
- A.1. LDAP Short Names .........................................23
- A.2. pilotObject ..............................................23
- A.3. pilotPerson ..............................................23
- A.4. dNSDomain ................................................24
- A.5. pilotDSA and qualityLabelledData .........................24
- A.6. Attribute Syntaxes .......................................24
- Appendix B. Changes since RFC 2247 ...............................24
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
-1. Introduction
-
- In the late 1980s, X.500 Directory Services were standardized by the
- CCITT (Commite' Consultatif International de Telegraphique et
- Telephonique), now a part of the ITU (International Telephone Union).
- This lead to Directory Service piloting activities in the early
- 1990s, including the COSINE (Co-operation and Open Systems
- Interconnection in Europe) PARADISE Project pilot [COSINEpilot] in
- Europe. Motivated by needs for large-scale directory pilots, RFC
- 1274 was published to standardize the directory schema and naming
- architecture for use in the COSINE and other Internet X.500 pilots
- [RFC1274].
-
- In the years that followed, X.500 Directory Services have evolved to
- incorporate new capabilities and even new protocols. In particular,
- the Lightweight Directory Access Protocol (LDAP) [RFC4510] was
- introduced in the early 1990s [RFC1487], with Version 3 of LDAP
- introduced in the late 1990s [RFC2251] and subsequently revised in
- 2005 [RFC4510].
-
- While much of the material in RFC 1274 has been superceded by
- subsequently published ITU-T Recommendations and IETF RFCs, many of
- the schema elements lack standardized schema descriptions for use in
- modern X.500 and LDAP directory services despite the fact that these
- schema elements are in wide use today. As the old schema
- descriptions cannot be used without adaptation, interoperability
- issues may arise due to lack of standardized modern schema
- descriptions.
-
- This document addresses these issues by offering standardized schema
- descriptions, where needed, for widely used COSINE schema elements.
-
-1.1. Relationship to Other Documents
-
- This document, together with [RFC4519] and [RFC4517], obsoletes RFC
- 1274 in its entirety. [RFC4519] replaces Sections 9.3.1 (Userid) and
- 9.3.21 (Domain Component) of RFC 1274. [RFC4517] replaces Section
- 9.4 (Generally useful syntaxes) of RFC 1274.
-
- This document replaces the remainder of RFC 1274. Appendix A
- discusses changes since RFC 1274, as well as why certain schema
- elements were not brought forward in this revision of the COSINE
- schema. All elements not brought are to be regarded as Historic.
-
- The description of the 'domain' object class provided in this
- document supercedes that found in RFC 2247. That is, Section 3.4 of
- this document replaces Section 5.2 of [RFC2247].
-
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- Some of the schema elements specified here were described in RFC 2798
- (inetOrgPerson schema). This document supersedes these descriptions.
- This document, together with [RFC4519], replaces Section 9.1.3 of RFC
- 2798.
-
-1.2. Terminology and 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].
-
- DIT stands for Directory Information Tree.
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent, a server.
- DSE stands for DSA-Specific Entry.
- DUA stands for Directory User Agent, a client.
-
- These terms are discussed in [RFC4512].
-
- Schema definitions are provided using LDAP description formats
- [RFC4512]. Definitions provided here are formatted (line wrapped)
- for readability.
-
-2. COSINE Attribute Types
-
- This section details COSINE attribute types for use in LDAP.
-
-2.1. associatedDomain
-
- The 'associatedDomain' attribute specifies DNS [RFC1034][RFC2181]
- host names [RFC1123] that are associated with an object. That is,
- values of this attribute should conform to the following ABNF:
-
- domain = root / label *( DOT label )
- root = SPACE
- label = LETDIG [ *61( LETDIG / HYPHEN ) LETDIG ]
- LETDIG = %x30-39 / %x41-5A / %x61-7A ; "0" - "9" / "A"-"Z" / "a"-"z"
- SPACE = %x20 ; space (" ")
- HYPHEN = %x2D ; hyphen ("-")
- DOT = %x2E ; period (".")
-
- For example, the entry in the DIT with a DN <DC=example,DC=com> might
- have an associated domain of "example.com".
-
- ( 0.9.2342.19200300.100.1.37 NAME 'associatedDomain'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [RFC4517].
-
- Note that the directory will not ensure that values of this attribute
- conform to the <domain> production provided above. It is the
- application's responsibility to ensure that domains it stores in this
- attribute are appropriately represented.
-
- Also note that applications supporting Internationalized Domain Names
- SHALL use the ToASCII method [RFC3490] to produce <label> components
- of the <domain> production.
-
-2.2. associatedName
-
- The 'associatedName' attribute specifies names of entries in the
- organizational DIT associated with a DNS domain [RFC1034][RFC2181].
-
- ( 0.9.2342.19200300.100.1.38 NAME 'associatedName'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [RFC4517].
-
-2.3. buildingName
-
- The 'buildingName' attribute specifies names of the buildings where
- an organization or organizational unit is based, for example, "The
- White House".
-
- ( 0.9.2342.19200300.100.1.48 NAME 'buildingName'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.4. co
-
- The 'co' (Friendly Country Name) attribute specifies names of
- countries in human-readable format, for example, "Germany" and
- "Federal Republic of Germany". It is commonly used in conjunction
- with the 'c' (Country Name) [RFC4519] attribute (whose values are
- restricted to the two-letter codes defined in [ISO3166]).
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- ( 0.9.2342.19200300.100.1.43 NAME 'co'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.5. documentAuthor
-
- The 'documentAuthor' attribute specifies the distinguished names of
- authors (or editors) of a document. For example,
-
- ( 0.9.2342.19200300.100.1.14 NAME 'documentAuthor'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [RFC4517].
-
-2.6. documentIdentifier
-
- The 'documentIdentifier' attribute specifies unique identifiers for a
- document. A document may be identified by more than one unique
- identifier. For example, RFC 3383 and BCP 64 are unique identifiers
- that (presently) refer to the same document.
-
- ( 0.9.2342.19200300.100.1.11 NAME 'documentIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.7. documentLocation
-
- The 'documentLocation' attribute specifies locations of the document
- original.
-
- ( 0.9.2342.19200300.100.1.15 NAME 'documentLocation'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-
-
-
-Zeilenga Standards Track [Page 6]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.8. documentPublisher
-
- The 'documentPublisher' attribute is the persons and/or organizations
- that published the document. Documents that are jointly published
- have one value for each publisher.
-
- ( 0.9.2342.19200300.100.1.56 NAME 'documentPublisher'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.9. documentTitle
-
- The 'documentTitle' attribute specifies the titles of a document.
- Multiple values are allowed to accommodate both long and short
- titles, or other situations where a document has multiple titles, for
- example, "The Lightweight Directory Access Protocol Technical
- Specification" and "The LDAP Technical Specification".
-
- ( 0.9.2342.19200300.100.1.12 NAME 'documentTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.10. documentVersion
-
- The 'documentVersion' attribute specifies the version information of
- a document.
-
- ( 0.9.2342.19200300.100.1.13 NAME 'documentVersion'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-
-
-
-
-Zeilenga Standards Track [Page 7]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.11. drink
-
- The 'drink' (favoriteDrink) attribute specifies the favorite drinks
- of an object (or person), for instance, "cola" and "beer".
-
- ( 0.9.2342.19200300.100.1.5 NAME 'drink'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.12. homePhone
-
- The 'homePhone' (Home Telephone Number) attribute specifies home
- telephone numbers (e.g., "+1 775 555 1234") associated with a person.
-
- ( 0.9.2342.19200300.100.1.20 NAME 'homePhone'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [RFC4517].
-
-2.13. homePostalAddress
-
- The 'homePostalAddress' attribute specifies home postal addresses for
- an object. Each value should be limited to up to 6 directory strings
- of 30 characters each. (Note: It is not intended that the directory
- service enforce these limits.)
-
- ( 0.9.2342.19200300.100.1.39 NAME 'homePostalAddress'
- EQUALITY caseIgnoreListMatch
- SUBSTR caseIgnoreListSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
-
- The PostalAddress (1.3.6.1.4.1.1466.115.121.1.41) syntax and the
- 'caseIgnoreListMatch' and 'caseIgnoreListSubstringsMatch' rules are
- described in [RFC4517].
-
-
-
-
-Zeilenga Standards Track [Page 8]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
-2.14. host
-
- The 'host' attribute specifies host computers, generally by their
- primary fully qualified domain name (e.g., my-host.example.com).
-
- ( 0.9.2342.19200300.100.1.9 NAME 'host'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.15. info
-
- The 'info' attribute specifies any general information pertinent to
- an object. This information is not necessarily descriptive of the
- object.
-
- Applications should not attach specific semantics to values of this
- attribute. The 'description' attribute [RFC4519] is available for
- specifying descriptive information pertinent to an object.
-
- ( 0.9.2342.19200300.100.1.4 NAME 'info'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{2048} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.16. mail
-
- The 'mail' (rfc822mailbox) attribute type holds Internet mail
- addresses in Mailbox [RFC2821] form (e.g., user at example.com).
-
- ( 0.9.2342.19200300.100.1.3 NAME 'mail'
- EQUALITY caseIgnoreIA5Match
- SUBSTR caseIgnoreIA5SubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
-
- The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax and the
- 'caseIgnoreIA5Match' and 'caseIgnoreIA5SubstringsMatch' rules are
- described in [RFC4517].
-
-
-
-
-
-Zeilenga Standards Track [Page 9]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- Note that the directory will not ensure that values of this attribute
- conform to the <Mailbox> production [RFC2821]. It is the
- application's responsibility to ensure that domains it stores in this
- attribute are appropriately represented.
-
- Additionally, the directory will compare values per the matching
- rules named in the above attribute type description. As these rules
- differ from rules that normally apply to <Mailbox> comparisons,
- operational issues may arise. For example, the assertion
- (mail=joe at example.com) will match "JOE at example.com" even though the
- <local-parts> differ. Also, where a user has two <Mailbox>es whose
- addresses differ only by case of the <local-part>, both cannot be
- listed as values of the user's mail attribute (as they are considered
- equal by the 'caseIgnoreIA5Match' rule).
-
- Also note that applications supporting internationalized domain names
- SHALL use the ToASCII method [RFC3490] to produce <sub-domain>
- components of the <Mailbox> production.
-
-2.17. manager
-
- The 'manager' attribute specifies managers, by distinguished name, of
- the person (or entity).
-
- ( 0.9.2342.19200300.100.1.10 NAME 'manager'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [RFC4517].
-
-2.18. mobile
-
- The 'mobile' (mobileTelephoneNumber) attribute specifies mobile
- telephone numbers (e.g., "+1 775 555 6789") associated with a person
- (or entity).
-
- ( 0.9.2342.19200300.100.1.41 NAME 'mobile'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [RFC4517].
-
-
-
-
-
-
-Zeilenga Standards Track [Page 10]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
-2.19. organizationalStatus
-
- The 'organizationalStatus' attribute specifies categories by which a
- person is often referred to in an organization. Examples of usage in
- academia might include "undergraduate student", "researcher",
- "professor", and "staff". Multiple values are allowed where the
- person is in multiple categories.
-
- Directory administrators and application designers SHOULD consider
- carefully the distinctions between this and the 'title' and
- 'userClass' attributes.
-
- ( 0.9.2342.19200300.100.1.45 NAME 'organizationalStatus'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.20. pager
-
- The 'pager' (pagerTelephoneNumber) attribute specifies pager
- telephone numbers (e.g., "+1 775 555 5555") for an object.
-
- ( 0.9.2342.19200300.100.1.42 NAME 'pager'
- EQUALITY telephoneNumberMatch
- SUBSTR telephoneNumberSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
-
- The telephoneNumber (1.3.6.1.4.1.1466.115.121.1.50) syntax and the
- 'telephoneNumberMatch' and 'telephoneNumberSubstringsMatch' rules are
- described in [RFC4517].
-
-2.21. personalTitle
-
- The 'personalTitle' attribute specifies personal titles for a person.
- Examples of personal titles are "Frau", "Dr.", "Herr", and
- "Professor".
-
- ( 0.9.2342.19200300.100.1.40 NAME 'personalTitle'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-
-
-
-
-Zeilenga Standards Track [Page 11]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.22. roomNumber
-
- The 'roomNumber' attribute specifies the room number of an object.
- During periods of renumbering, or in other circumstances where a room
- has multiple valid room numbers associated with it, multiple values
- may be provided. Note that the 'cn' (commonName) attribute type
- SHOULD be used for naming room objects.
-
- ( 0.9.2342.19200300.100.1.6 NAME 'roomNumber'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-2.23. secretary
-
- The 'secretary' attribute specifies secretaries and/or administrative
- assistants, by distinguished name.
-
- ( 0.9.2342.19200300.100.1.21 NAME 'secretary'
- EQUALITY distinguishedNameMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
-
- The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax and the
- 'distinguishedNameMatch' rule are described in [RFC4517].
-
-2.24. uniqueIdentifier
-
- The 'uniqueIdentifier' attribute specifies a unique identifier for an
- object represented in the Directory. The domain within which the
- identifier is unique and the exact semantics of the identifier are
- for local definition. For a person, this might be an institution-
- wide payroll number. For an organizational unit, it might be a
- department code.
-
- ( 0.9.2342.19200300.100.1.44 NAME 'uniqueIdentifier'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
-
-
-
-
-Zeilenga Standards Track [Page 12]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
- Note: X.520 also describes an attribute called 'uniqueIdentifier'
- (2.5.4.45), which is called 'x500UniqueIdentifier' in LDAP
- [RFC4519]. The attribute detailed here ought not be confused
- with 'x500UniqueIdentifier'.
-
-2.25. userClass
-
- The 'userClass' attribute specifies categories of computer or
- application user. The semantics placed on this attribute are for
- local interpretation. Examples of current usage of this attribute in
- academia are "student", "staff", and "faculty". Note that the
- 'organizationalStatus' attribute type is now often preferred, as it
- makes no distinction between persons as opposed to users.
-
- ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
- EQUALITY caseIgnoreMatch
- SUBSTR caseIgnoreSubstringsMatch
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
-
- The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
- 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
- in [RFC4517].
-
-3. COSINE Object Classes
-
- This section details COSINE object classes for use in LDAP.
-
-3.1. account
-
- The 'account' object class is used to define entries representing
- computer accounts. The 'uid' attribute SHOULD be used for naming
- entries of this object class.
-
- ( 0.9.2342.19200300.100.4.5 NAME 'account'
- SUP top STRUCTURAL
- MUST uid
- MAY ( description $ seeAlso $ l $ o $ ou $ host ) )
-
- The 'top' object class is described in [RFC4512]. The 'description',
- 'seeAlso', 'l', 'o', 'ou', and 'uid' attribute types are described in
- [RFC4519]. The 'host' attribute type is described in Section 2 of
- this document.
-
-
-
-
-
-Zeilenga Standards Track [Page 13]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- 3.3. documentSeriesExample:
-
- dn: uid=kdz,cn=Accounts,dc=Example,dc=COM
- objectClass: account
- uid: kdz
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-3.2. document
-
- The 'document' object class is used to define entries that represent
- documents.
-
- ( 0.9.2342.19200300.100.4.6 NAME 'document'
- SUP top STRUCTURAL
- MUST documentIdentifier
- MAY ( cn $ description $ seeAlso $ l $ o $ ou $
- documentTitle $ documentVersion $ documentAuthor $
- documentLocation $ documentPublisher ) )
-
- The 'top' object class is described in [RFC4512]. The 'cn',
- 'description', 'seeAlso', 'l', 'o', and 'ou' attribute types are
- described in [RFC4519]. The 'documentIdentifier', 'documentTitle',
- 'documentVersion', 'documentAuthor', 'documentLocation', and
- 'documentPublisher' attribute types are described in Section 2 of
- this document.
-
- Example:
-
- dn: documentIdentifier=RFC 4524,cn=RFC,dc=Example,dc=COM
- objectClass: document
- documentIdentifier: RFC 4524
- documentTitle: COSINE LDAP/X.500 Schema
- documentAuthor: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
- documentLocation: http://www.rfc-editor.org/rfc/rfc4524.txt
- documentPublisher: Internet Engineering Task Force
- description: A collection of schema elements for use in LDAP
- description: Obsoletes RFC 1274
- seeAlso: documentIdentifier=RFC 4510,cn=RFC,dc=Example,dc=COM
- seeAlso: documentIdentifier=RFC 1274,cn=RFC,dc=Example,dc=COM
-
-3.3. documentSeries
-
- The 'documentSeries' object class is used to define an entry that
- represents a series of documents (e.g., The Request For Comments
- memos).
-
-
-
-
-
-
-Zeilenga Standards Track [Page 14]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- ( 0.9.2342.19200300.100.4.9 NAME 'documentSeries'
- SUP top STRUCTURAL
- MUST cn
- MAY ( description $ l $ o $ ou $ seeAlso $
- telephonenumber ) )
-
- The 'top' object class is described in [RFC4512]. The 'description',
- 'l', 'o', 'ou', 'seeAlso', and 'telephoneNumber' attribute types are
- described in [RFC4519].
-
- Example:
-
- dn: cn=RFC,dc=Example,dc=COM
- objectClass: documentSeries
- cn: Request for Comments
- cn: RFC
- description: a series of memos about the Internet
-
-3.4. domain
-
- The 'domain' object class is used to define entries that represent
- DNS domains for objects that are not organizations, organizational
- units, or other kinds of objects more appropriately defined using an
- object class specific to the kind of object being defined (e.g.,
- 'organization', 'organizationUnit').
-
- The 'dc' attribute should be used for naming entries of the 'domain'
- object class.
-
- ( 0.9.2342.19200300.100.4.13 NAME 'domain'
- SUP top STRUCTURAL
- MUST dc
- MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
- x121Address $ registeredAddress $ destinationIndicator $
- preferredDeliveryMethod $ telexNumber $
- teletexTerminalIdentifier $ telephoneNumber $
- internationaliSDNNumber $ facsimileTelephoneNumber $ street $
- postOfficeBox $ postalCode $ postalAddress $
- physicalDeliveryOfficeName $ st $ l $ description $ o $
- associatedName ) )
-
- The 'top' object class and the 'dc', 'userPassword', 'searchGuide',
- 'seeAlso', 'businessCategory', 'x121Address', 'registeredAddress',
- 'destinationIndicator', 'preferredDeliveryMethod', 'telexNumber',
- 'teletexTerminalIdentifier', 'telephoneNumber',
- 'internationaliSDNNumber', 'facsimileTelephoneNumber', 'street',
- 'postOfficeBox', 'postalCode', 'postalAddress',
- 'physicalDeliveryOfficeName', 'st', 'l', 'description', and 'o' types
-
-
-
-Zeilenga Standards Track [Page 15]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- are described in [RFC4519]. The 'associatedName' attribute type is
- described in Section 2 of this document.
-
- Example:
-
- dn: dc=com
- objectClass: domain
- dc: com
- description: the .COM TLD
-
-3.5. domainRelatedObject
-
- The 'domainRelatedObject' object class is used to define entries that
- represent DNS domains that are "equivalent" to an X.500 domain, e.g.,
- an organization or organizational unit.
-
- ( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject'
- SUP top AUXILIARY
- MUST associatedDomain )
-
- The 'top' object class is described in [RFC4512]. The
- 'associatedDomain' attribute type is described in Section 2 of this
- document.
-
- Example:
-
- dn: dc=example,dc=com
- objectClass: organization
- objectClass: dcObject
- objectClass: domainRelatedObject
- dc: example
- associatedDomain: example.com
- o: Example Organization
-
- The 'organization' and 'dcObject' object classes and the 'dc' and 'o'
- attribute types are described in [RFC4519].
-
-3.6. friendlyCountry
-
- The 'friendlyCountry' object class is used to define entries
- representing countries in the DIT. The object class is used to allow
- friendlier naming of countries than that allowed by the object class
- 'country' [RFC4519].
-
- ( 0.9.2342.19200300.100.4.18 NAME 'friendlyCountry'
- SUP country STRUCTURAL
- MUST co )
-
-
-
-
-Zeilenga Standards Track [Page 16]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The 'country' object class is described in [RFC4519]. The 'co'
- attribute type is described in Section 2 of this document.
-
- Example:
-
- dn: c=DE
- objectClass: country
- objectClass: friendlyCountry
- c: DE
- co: Deutschland
- co: Germany
- co: Federal Republic of Germany
- co: FRG
-
- The 'c' attribute type is described in [RFC4519].
-
-3.7. rFC822LocalPart
-
- The 'rFC822LocalPart' object class is used to define entries that
- represent the local part of Internet mail addresses [RFC2822]. This
- treats the local part of the address as a 'domain' object.
-
- ( 0.9.2342.19200300.100.4.14 NAME 'rFC822localPart'
- SUP domain STRUCTURAL
- MAY ( cn $ description $ destinationIndicator $
- facsimileTelephoneNumber $ internationaliSDNNumber $
- physicalDeliveryOfficeName $ postalAddress $ postalCode $
- postOfficeBox $ preferredDeliveryMethod $ registeredAddress $
- seeAlso $ sn $ street $ telephoneNumber $
- teletexTerminalIdentifier $ telexNumber $ x121Address ) )
-
- The 'domain' object class is described in Section 3.4 of this
- document. The 'cn', 'description', 'destinationIndicator',
- 'facsimileTelephoneNumber', 'internationaliSDNNumber,
- 'physicalDeliveryOfficeName', 'postalAddress', 'postalCode',
- 'postOfficeBox', 'preferredDeliveryMethod', 'registeredAddress',
- 'seeAlso', 'sn, 'street', 'telephoneNumber',
- 'teletexTerminalIdentifier', 'telexNumber', and 'x121Address'
- attribute types are described in [RFC4519].
-
- Example:
-
- dn: dc=kdz,dc=example,dc=com
- objectClass: domain
- objectClass: rFC822LocalPart
- dc: kdz
- associatedName: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-
-
-
-Zeilenga Standards Track [Page 17]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- The 'dc' attribute type is described in [RFC4519].
-
-3.8. room
-
- The 'room' object class is used to define entries representing rooms.
- The 'cn' (commonName) attribute SHOULD be used for naming entries of
- this object class.
-
- ( 0.9.2342.19200300.100.4.7 NAME 'room'
- SUP top STRUCTURAL
- MUST cn
- MAY ( roomNumber $ description $ seeAlso $ telephoneNumber ) )
-
- The 'top' object class is described in [RFC4512]. The 'cn',
- 'description', 'seeAlso', and 'telephoneNumber' attribute types are
- described in [RFC4519]. The 'roomNumber' attribute type is described
- in Section 2 of this document.
-
- dn: cn=conference room,dc=example,dc=com
- objectClass: room
- cn: conference room
- telephoneNumber: +1 755 555 1111
-
-3.9. simpleSecurityObject
-
- The 'simpleSecurityObject' object class is used to require an entry
- to have a 'userPassword' attribute when the entry's structural object
- class does not require (or allow) the 'userPassword attribute'.
-
- ( 0.9.2342.19200300.100.4.19 NAME 'simpleSecurityObject'
- SUP top AUXILIARY
- MUST userPassword )
-
- The 'top' object class is described in [RFC4512]. The 'userPassword'
- attribute type is described in [RFC4519].
-
- dn: dc=kdz,dc=Example,dc=COM
- objectClass: account
- objectClass: simpleSecurityObject
- uid: kdz
- userPassword: My Password
- seeAlso: cn=Kurt D. Zeilenga,cn=Persons,dc=Example,dc=COM
-
-4. Security Considerations
-
- General LDAP security considerations [RFC4510] are applicable to the
- use of this schema. Additional considerations are noted above where
- appropriate.
-
-
-
-Zeilenga Standards Track [Page 18]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- Directories administrators should ensure that access to sensitive
- information be restricted to authorized entities and that appropriate
- data security services, including data integrity and data
- confidentiality, are used to protect against eavesdropping.
-
- Simple authentication (e.g., plain text passwords) mechanisms should
- only be used when adequate data security services are in place. LDAP
- offers reasonably strong authentication and data security services
- [RFC4513].
-
-5. IANA Considerations
-
- The Internet Assigned Numbers Authority (IANA) has updated the LDAP
- descriptors registry [RFC4520] as indicated in the following
- template:
-
- Subject: Request for LDAP Descriptor Registration Update
- Descriptor (short name): see comment
- Object Identifier: see comments
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Usage: see comments
- Specification: RFC 4524
- Author/Change Controller: IESG
- Comments:
-
- The following descriptors have been updated to refer to RFC 4524.
-
- NAME Type OID
- ------------------------ ---- --------------------------
- account O 0.9.2342.19200300.100.4.5
- associatedDomain A 0.9.2342.19200300.100.1.37
- associatedName A 0.9.2342.19200300.100.1.38
- buildingName A 0.9.2342.19200300.100.1.48
- co A 0.9.2342.19200300.100.1.43
- document O 0.9.2342.19200300.100.4.6
- documentAuthor A 0.9.2342.19200300.100.1.14
- documentIdentifier A 0.9.2342.19200300.100.1.11
- documentLocation A 0.9.2342.19200300.100.1.15
- documentPublisher A 0.9.2342.19200300.100.1.56
- documentSeries O 0.9.2342.19200300.100.4.8
- documentTitle A 0.9.2342.19200300.100.1.12
- documentVersion A 0.9.2342.19200300.100.1.13
- domain O 0.9.2342.19200300.100.4.13
- domainRelatedObject O 0.9.2342.19200300.100.4.17
- drink A 0.9.2342.19200300.100.1.5
- favouriteDrink A* 0.9.2342.19200300.100.1.5
- friendlyCountry O 0.9.2342.19200300.100.4.18
-
-
-
-Zeilenga Standards Track [Page 19]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- friendlyCountryName A* 0.9.2342.19200300.100.1.43
- homePhone A 0.9.2342.19200300.100.1.20
- homePostalAddress A 0.9.2342.19200300.100.1.39
- homeTelephone A* 0.9.2342.19200300.100.1.20
- host A 0.9.2342.19200300.100.1.9
- info A 0.9.2342.19200300.100.1.4
- mail A 0.9.2342.19200300.100.1.3
- manager A 0.9.2342.19200300.100.1.10
- mobile A 0.9.2342.19200300.100.1.41
- mobileTelephoneNumber A* 0.9.2342.19200300.100.1.41
- organizationalStatus A 0.9.2342.19200300.100.1.45
- pager A 0.9.2342.19200300.100.1.42
- pagerTelephoneNumber A* 0.9.2342.19200300.100.1.42
- personalTitle A 0.9.2342.19200300.100.1.40
- rFC822LocalPart O 0.9.2342.19200300.100.4.14
- rfc822Mailbox A* 0.9.2342.19200300.100.1.3
- room O 0.9.2342.19200300.100.4.7
- roomNumber A 0.9.2342.19200300.100.1.6
- secretary A 0.9.2342.19200300.100.1.21
- simpleSecurityObject O 0.9.2342.19200300.100.4.19
- singleLevelQuality A 0.9.2342.19200300.100.1.50
- uniqueIdentifier A 0.9.2342.19200300.100.1.44
- userClass A 0.9.2342.19200300.100.1.8
-
- where Type A is Attribute, Type O is ObjectClass, and *
- indicates that the registration is historic in nature.
-
-6. Acknowledgements
-
- This document is based on RFC 1274, by Paul Barker and Steve Kille,
- as well as on RFC 2247, by Steve Kill, Mark Wahl, Al Grimstad, Rick
- Huber, and Sri Satulari.
-
-7. References
-
-7.1. Normative References
-
- [RFC1034] Mockapetris, P., "Domain names - concepts and
- facilities", STD 13, RFC 1034, November 1987.
-
- [RFC1123] Braden, R., "Requirements for Internet Hosts -
- Application and Support", STD 3, RFC 1123, October
- 1989.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-
-Zeilenga Standards Track [Page 20]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
- Specification", RFC 2181, July 1997.
-
- [RFC2247] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S.
- Sataluri, "Using Domains in LDAP/X.500 Distinguished
- Names", RFC 2247, January 1998.
-
- [RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC
- 2821, April 2001.
-
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
- 2001.
-
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
- "Internationalizing Domain Names in Applications
- (IDNA)", RFC 3490, March 2003.
-
- [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., "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", RC 4517, June
- 2006.
-
- [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
- Protocol (LDAP): Schema for User Applications", RFC
- 4519, June 2006.
-
- [X.501] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory -- Models," X.501(1993) (also ISO/IEC 9594-
- 2:1994).
-
-7.2. Informative References
-
- [COSINEpilot] Goodman, D., "PARADISE" section of the March 1991
- INTERNET MONTHLY REPORTS (p. 28-29),
- http://www.iana.org/periodic-reports/imr-mar91.txt
-
-
-
-
-Zeilenga Standards Track [Page 21]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
- [ISO3166] International Organization for Standardization, "Codes
- for the representation of names of countries", ISO
- 3166.
-
- [RFC1274] Barker, P. and S. Kille, "The COSINE and Internet X.500
- Schema", RFC 1274, November 1991.
-
- [RFC1279] Hardcastle-Kille, S., "X.500 and Domains", RFC 1279,
- November 1991.
-
- [RFC1487] Yeong, W., Howes, T., and S. Kille, "X.500 Lightweight
- Directory Access Protocol", RFC 1487, July 1993.
-
- [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol (v3)", RFC 2251, December
- 1997.
-
- [RFC2798] Smith, M., "Definition of the inetOrgPerson LDAP Object
- Class", RFC 2798, April 2000.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 22]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
-Appendix A. Changes since RFC 1274
-
- This document represents a substantial rewrite of RFC 1274. The
- following sections summarize the substantive changes.
-
-A.1. LDAP Short Names
-
- A number of COSINE attribute types have short names in LDAP.
-
- X.500 Name LDAP Short Name
- ------------- ---------------
- domainComponent dc
- favoriteDrink drink
- friendCountryName co
- homeTelephoneNumber homePhone
- mobileTelephoneNumber mobile
- pagerTelephoneNumber pager
- rfc822Mailbox mail
- userid uid
-
- While the LDAP short names are generally used in LDAP, some
- implementations may (for legacy reasons [RFC3494]) recognize the
- attribute type by its X.500 name. Hence, the X.500 names have been
- reserved solely for this purpose.
-
- Note: 'uid' and 'dc' are described in [RFC4519].
-
-A.2. pilotObject
-
- The 'pilotObject' object class was not brought forward as its
- function is largely replaced by operational attributes introduced in
- X.500(93) [X.501] and version 3 of LDAP [RFC4512]. For instance, the
- function of the 'lastModifiedBy' and 'lastModifiedTime' attribute
- types is now served by the 'creatorsName', 'createTimestamp',
- 'modifiersName', and 'modifyTimestamp' operational attributes
- [RFC4512].
-
-A.3. pilotPerson
-
- The 'pilotPerson' object class was not brought forward as its
- function is largely replaced by the 'organizationalPerson' [RFC4512]
- object class and its subclasses, such as 'inetOrgPerson' [RFC2798].
-
- Most of the related attribute types (e.g., 'mail', 'manager') were
- brought forward as they are used in other object classes.
-
-
-
-
-
-
-Zeilenga Standards Track [Page 23]
-
-RFC 4524 COSINE LDAP/X.500 Schema June 2006
-
-
-A.4. dNSDomain
-
- The 'dNSDomain' object class and related attribute types were not
- brought forward as its use is primarily experimental [RFC1279].
-
-A.5. pilotDSA and qualityLabelledData
-
- The 'pilotDSA' and 'qualityLabelledData' object classes, as well as
- related attribute types, were not brought forward as its use is
- primarily experimental [QoS].
-
-A.6. Attribute Syntaxes
-
- RFC 1274 defined and used caseIgnoreIA5StringSyntax attribute syntax.
- This has been replaced with the IA5String syntax and appropriate
- matching rules in 'mail' and 'associatedDomain'.
-
- RFC 1274 restricted 'mail' to have non-zero length values. This
- restriction is not reflected in the IA5String syntax used in the
- definitions provided in this specification. However, as values are
- to conform to the <Mailbox> production, the 'mail' should not contain
- zero-length values. Unfortunately, the directory service will not
- enforce this restriction.
-
-Appendix B. Changes since RFC 2247
-
- The 'domainNameForm' name form was not brought forward as
- specification of name forms used in LDAP is left to a future
- specification.
-
-Editor's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 24]
-
-RFC 4524 COSINE LDAP/X.500 Schema 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 25]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4525.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4525.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4525.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4525 OpenLDAP Foundation
-Category: Informational June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- Modify-Increment Extension
-
-
-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 (2006).
-
-Abstract
-
- This document describes an extension to the Lightweight Directory
- Access Protocol (LDAP) Modify operation to support an increment
- capability. This extension is useful in provisioning applications,
- especially when combined with the assertion control and/or the pre-
- read or post-read control extension.
-
-Table of Contents
-
- 1. Background and Intended Use .....................................1
- 2. The Modify-Increment Extension ..................................2
- 3. LDIF Support ....................................................2
- 4. Security Considerations .........................................3
- 5. IANA Considerations .............................................3
- 5.1. Object Identifier ..........................................3
- 5.2. LDAP Protocol Mechanism ....................................3
- 5.3. LDAP Protocol Mechanism ....................................4
- 6. References ......................................................4
- 6.1. Normative References .......................................4
- 6.2. Informative References .....................................5
-
-1. Background and Intended Use
-
- The Lightweight Directory Access Protocol (LDAP) [RFC4510] does not
- currently provide an operation to increment values of an attribute.
- A client must read the values of the attribute and then modify those
- values to increment them by the desired amount. As the values may be
- updated by other clients between this add and modify, the client must
-
-
-
-Zeilenga Informational [Page 1]
-
-RFC 4525 LDAP Modify-Increment Extension June 2006
-
-
- be careful to construct the modify request so that it fails in this
- case, and upon failure, to re-read the values and construct a new
- modify request.
-
- This document extends the LDAP Modify Operation [RFC4511] to support
- an increment values capability. This feature is intended to be used
- with either the LDAP pre-read or post-read control extensions
- [RFC4527]. This feature may also be used with the LDAP assertion
- control extension [RFC4528] to provide test-and-increment
- functionality.
-
- In this document 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 [RFC2119].
-
-2. The Modify-Increment Extension
-
- This document extends the LDAP Modify request to support a increment
- values capability. Implementations of this extension SHALL support
- an additional ModifyRequest operation enumeration value increment
- (3), as described herein. Implementations not supporting this
- extension will treat this value as they would an unlisted value,
- e.g., as a protocol error.
-
- The increment (3) operation value specifies that an increment values
- modification is requested. All existing values of the modification
- attribute are to be incremented by the listed value. The
- modification attribute must be appropriate for the request (e.g., it
- must have INTEGER or other increment-able values), and the
- modification must provide one and only one value. If the attribute
- is not appropriate for the request, a constraintViolation or other
- appropriate error is to be returned. If multiple values are
- provided, a protocolError is to be returned.
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) 1.3.6.1.1.14 as a value of the 'supportedFeatures' [RFC4512]
- attribute in the root DSE. Clients supporting this feature SHOULD
- NOT use the feature unless they know the server supports it.
-
-3. LDIF Support
-
- To represent Modify-Increment requests in LDAP Data Interchange
- Format [RFC2849], the ABNF [RFC4234] production <mod-spec> is
- extended as follows:
-
- mod-spec =/ "increment:" FILL AttributeDescription SEP
- attrval-spec "-" SEP
-
-
-
-
-Zeilenga Informational [Page 2]
-
-RFC 4525 LDAP Modify-Increment Extension June 2006
-
-
- For example,
-
- # Increment uidNumber
- dn: cn=max-assigned uidNumber,dc=example,dc=com
- changetype: modify
- increment: uidNumber
- uidNumber: 1
- -
-
- This LDIF fragment represents a Modify request to increment the
- value(s) of uidNumber by 1.
-
-4. Security Considerations
-
- General LDAP security considerations [RFC4510], as well as those
- specific to the LDAP Modify [RFC4511], apply to this Modify-Increment
- extension. Beyond these considerations, it is noted that
- introduction of this extension should reduce application complexity
- (by providing one operation for what presently requires multiple
- operations) and, hence, it may aid in the production of correct and
- secure implementations.
-
-5. IANA Considerations
-
- Registration of the following values [RFC4520] have been completed.
-
-5.1. Object Identifier
-
- The IANA has assigned an LDAP Object Identifier to identify the LDAP
- Modify-Increment feature, as defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4525
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Modify-Increment feature
-
-5.2. LDAP Protocol Mechanism
-
- The following LDAP Protocol Mechanism has been registered.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.1.14
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
-
-
-
-Zeilenga Informational [Page 3]
-
-RFC 4525 LDAP Modify-Increment Extension June 2006
-
-
- Usage: Feature
- Specification: RFC 4525
- Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
- Comments: none
-
-5.3. LDAP Protocol Mechanism
-
- The IANA has assigned an LDAP ModifyRequest Operation Type (3)
- [RFC4520] for use in this document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- ModifyRequest Operation Name: increment
- Description: Modify-Increment
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Feature
- Specification: RFC 4525
- Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
- Comments: none
-
-6. References
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 4234, October 2005.
-
- [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) -
- Technical Specification", RFC 2849, June 2000.
-
- [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.
-
-
-
-
-
-
-
-
-Zeilenga Informational [Page 4]
-
-RFC 4525 LDAP Modify-Increment Extension June 2006
-
-
-6.2. Informative References
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [RFC4527] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Read Entry Controls", RFC 4527, June 2006.
-
- [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Assertion Control", RFC 4528, June 2006.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Informational [Page 5]
-
-RFC 4525 LDAP Modify-Increment Extension 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 Informational [Page 6]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4526.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4526.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4526.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4526 OpenLDAP Foundation
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- Absolute True and False 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
-
- This document extends the Lightweight Directory Access Protocol
- (LDAP) to support absolute True and False filters based upon similar
- capabilities found in X.500 directory systems. The document also
- extends the String Representation of LDAP Search Filters to support
- these filters.
-
-Table of Contents
-
- 1. Background ......................................................1
- 2. Absolute True and False Filters .................................2
- 3. Security Considerations .........................................2
- 4. IANA Considerations .............................................3
- 5. References ......................................................3
- 5.1. Normative References .......................................3
- 5.2. Informative References .....................................3
-
-1. Background
-
- The X.500 Directory Access Protocol (DAP) [X.511] supports absolute
- True and False assertions. An 'and' filter with zero elements always
- evaluates to True. An 'or' filter with zero elements always
- evaluates to False. These filters are commonly used when requesting
- DSA-specific Entries (DSEs) that do not necessarily have
- 'objectClass' attributes; that is, where "(objectClass=*)" may
- evaluate to False.
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4526 LDAP Absolute True and False Filters June 2006
-
-
- Although LDAPv2 [RFC1777][RFC3494] placed no restriction on the
- number of elements in 'and' and 'or' filter sets, the LDAPv2 string
- representation [RFC1960][RFC3494] could not represent empty 'and' and
- 'or' filter sets. Due to this, absolute True or False filters were
- (unfortunately) eliminated from LDAPv3 [RFC4510].
-
- This documents extends LDAPv3 to support absolute True and False
- assertions by allowing empty 'and' and 'or' in Search filters
- [RFC4511] and extends the filter string representation [RFC4515] to
- allow empty filter lists.
-
- It is noted that certain search operations, such as those used to
- retrieve subschema information [RFC4512], require use of particular
- filters. This document does not change these requirements.
-
- This feature is intended to allow a more direct mapping between DAP
- and LDAP (as needed to implement DAP-to-LDAP gateways).
-
- 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
- [RFC2119].
-
-2. Absolute True and False Filters
-
- Implementations of this extension SHALL allow 'and' and 'or' choices
- with zero filter elements.
-
- An 'and' filter consisting of an empty set of filters SHALL evaluate
- to True. This filter is represented by the string "(&)".
-
- An 'or' filter consisting of an empty set of filters SHALL evaluate
- to False. This filter is represented by the string "(|)".
-
- Servers supporting this feature SHOULD publish the Object Identifier
- 1.3.6.1.4.1.4203.1.5.3 as a value of the 'supportedFeatures'
- [RFC4512] attribute in the root DSE.
-
- Clients supporting this feature SHOULD NOT use the feature unless
- they know that the server supports it.
-
-3. Security Considerations
-
- The (re)introduction of absolute True and False filters is not
- believed to raise any new security considerations.
-
- Implementors of this (or any) LDAPv3 extension should be familiar
- with general LDAPv3 security considerations [RFC4510].
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4526 LDAP Absolute True and False Filters June 2006
-
-
-4. IANA Considerations
-
- Registration of this feature has been completed by the IANA
- [RFC4520].
-
- Subject: Request for LDAP Protocol Mechanism Registration Object
- Identifier: 1.3.6.1.4.1.4203.1.5.3 Description: True/False filters
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org> Usage: Feature Specification:
- RFC 4526 Author/Change Controller: IESG Comments: none
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in
- this specification.
-
-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.
-
- [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.
-
- [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
- Access Protocol (LDAP): String Representation of Search
- Filters", RFC 4515, June 2006.
-
-5.2. Informative References
-
- [RFC1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
- Directory Access Protocol", RFC 1777, March 1995.
-
- [RFC1960] Howes, T., "A String Representation of LDAP Search
- Filters", RFC 1960, June 1996.
-
- [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol
- version 2 (LDAPv2) to Historic Status", RFC 3494, March
- 2003.
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4526 LDAP Absolute True and False Filters June 2006
-
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, 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).
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4526 LDAP Absolute True and False 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).
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4527.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4527.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4527.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4527 OpenLDAP Foundation
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- Read Entry Controls
-
-
-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 specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) to allow the client to read the target entry
- of an update operation. The client may request to read the entry
- before and/or after the modifications are applied. These reads are
- done as an atomic part of the update operation.
-
-Table of Contents
-
- 1. Background and Intent of Use ....................................2
- 2. Terminology .....................................................2
- 3. Read Entry Controls .............................................3
- 3.1. The Pre-Read Controls ......................................3
- 3.2. The Post-Read Controls .....................................3
- 4. Interaction with Other Controls .................................4
- 5. Security Considerations .........................................4
- 6. IANA Considerations .............................................5
- 6.1. Object Identifier ..........................................5
- 6.2. LDAP Protocol Mechanisms ...................................5
- 7. Acknowledgement .................................................5
- 8. References ......................................................6
- 8.1. Normative References .......................................6
- 8.2. Informative References .....................................7
-
-
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
-1. Background and Intent of Use
-
- This document specifies an extension to the Lightweight Directory
- Access Protocol (LDAP) [RFC4510] to allow the client to read the
- target entry of an update operation (e.g., Add, Delete, Modify,
- ModifyDN). The extension utilizes controls [RFC4511] attached to
- update requests to request and return copies of the target entry.
- One request control, called the Pre-Read request control, indicates
- that a copy of the entry before application of update is to be
- returned. Another control, called the Post-Read request control,
- indicates that a copy of the entry after application of the update is
- to be returned. Each request control has a corresponding response
- control used to return the entry.
-
- To ensure proper isolation, the controls are processed as an atomic
- part of the update operation.
-
- The functionality offered by these controls is based upon similar
- functionality in the X.500 Directory Access Protocol (DAP) [X.511].
-
- The Pre-Read controls may be used to obtain replaced or deleted
- values of modified attributes or a copy of the entry being deleted.
-
- The Post-Read controls may be used to obtain values of operational
- attributes, such as the 'entryUUID' [RFC4530] and 'modifyTimestamp'
- [RFC4512] attributes, updated by the server as part of the update
- operation.
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded
- using the Basic Encoding Rules [X.690] under the restrictions
- detailed in Section 5.1 of [RFC4511].
-
- DN stands for Distinguished Name.
- DSA stands for Directory System Agent (i.e., a directory server).
- DSE stands for DSA-specific Entry.
-
- 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
- [RFC2119].
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
-3. Read Entry Controls
-
-3.1. The Pre-Read Controls
-
- The Pre-Read request and response controls are identified by the
- 1.3.6.1.1.13.1 object identifier. Servers implementing these
- controls SHOULD publish 1.3.6.1.1.13.1 as a value of the
- 'supportedControl' [RFC4512] in their root DSE.
-
- The Pre-Read request control is a LDAP Control [RFC4511] whose
- controlType is 1.3.6.1.1.13.1 and whose controlValue is a BER-encoded
- AttributeSelection [RFC4511], as extended by [RFC3673]. The
- criticality may be TRUE or FALSE. This control is appropriate for
- the modifyRequest, delRequest, and modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose
- controlType is 1.3.6.1.1.13.1 and whose the controlValue, an OCTET
- STRING, contains a BER-encoded SearchResultEntry. The criticality
- may be TRUE or FALSE. This control is appropriate for the
- modifyResponse, delResponse, and modDNResponse LDAP messages with a
- resultCode of success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of the target
- entry prior to the application of the update. The AttributeSelection
- indicates, as discussed in [RFC4511][RFC3673], which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no Pre-Read response control is provided.
-
-3.2. The Post-Read Controls
-
- The Post-Read request and response controls are identified by the
- 1.3.6.1.1.13.2 object identifier. Servers implementing these
- controls SHOULD publish 1.3.6.1.1.13.2 as a value of the
- 'supportedControl' [RFC4512] in their root DSE.
-
- The Post-Read request control is a LDAP Control [RFC4511] whose
- controlType is 1.3.6.1.1.13.2 and whose controlValue, an OCTET
- STRING, contains a BER-encoded AttributeSelection [RFC4511], as
- extended by [RFC3673]. The criticality may be TRUE or FALSE. This
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
- control is appropriate for the addRequest, modifyRequest, and
- modDNRequest LDAP messages.
-
- The corresponding response control is a LDAP Control whose
- controlType is 1.3.6.1.1.13.2 and whose controlValue is a BER-encoded
- SearchResultEntry. The criticality may be TRUE or FALSE. This
- control is appropriate for the addResponse, modifyResponse, and
- modDNResponse LDAP messages with a resultCode of success (0).
-
- When the request control is attached to an appropriate update LDAP
- request, the control requests the return of a copy of the target
- entry after the application of the update. The AttributeSelection
- indicates, as discussed in [RFC4511][RFC3673], which attributes are
- requested to appear in the copy. The server is to return a
- SearchResultEntry containing, subject to access controls and other
- constraints, values of the requested attributes.
-
- The normal processing of the update operation and the processing of
- this control MUST be performed as one atomic action isolated from
- other update operations.
-
- If the update operation fails (in either normal or control
- processing), no Post-Read response control is provided.
-
-4. Interaction with Other Controls
-
- The Pre-Read and Post-Read controls may be combined with each other
- and/or with a variety of other controls. When combined with the
- assertion control [RFC4528] and/or the manageDsaIT control [RFC3296],
- the semantics of each control included in the combination applies.
- The Pre-Read and Post-Read controls may be combined with other
- controls as detailed in other technical specifications.
-
-5. Security Considerations
-
- The controls defined in this document extend update operations to
- support read capabilities. Servers MUST ensure that the client is
- authorized for reading of the information provided in this control
- and that the client is authorized to perform the requested directory
- update.
-
- Security considerations for the update operations [RFC4511] extended
- by this control, as well as general LDAP security considerations
- [RFC4510], generally apply to implementation and use of this
- extension
-
-
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
-6. IANA Considerations
-
- Registration of the following protocol values [RFC4520] have been
- completed by the IANA.
-
-6.1. Object Identifier
-
- The IANA has registered an LDAP Object Identifier to identify LDAP
- protocol elements defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4527
- Author/Change Controller: IESG
- Comments: Identifies the LDAP Read Entry Controls
-
-6.2. LDAP Protocol Mechanisms
-
- The IANA has registered the LDAP Protocol Mechanism described in this
- document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.1.13.1
- Description: LDAP Pre-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Control
- Specification: RFC 4527
- Author/Change Controller: IESG
- Comments: none
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.1.13.2
- Description: LDAP Post-read Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Control
- Specification: RFC 4527
- Author/Change Controller: IESG
- Comments: none
-
-7. Acknowledgement
-
- The LDAP Pre-Read and Post-Read controls are modeled after similar
- capabilities offered in the DAP [X.511].
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
-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.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
- version 3 (LDAPv3): All Operational Attributes", RFC
- 3673, December 2003.
-
- [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.
-
- [RFC4528] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Assertion Control", RFC 4528, June 2006.
-
- [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).
-
- [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).
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 6]
-
-RFC 4527 LDAP Read Entry Controls June 2006
-
-
-8.2. Informative References
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) EntryUUID Operational Attribute", RFC 4530, June
- 2006.
-
- [X.511] International Telecommunication Union -
- Telecommunication Standardization Sector, "The
- Directory: Abstract Service Definition", X.511(1993)
- (also ISO/IEC 9594-3:1993).
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 7]
-
-RFC 4527 LDAP Read Entry Controls 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 8]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4528.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4528.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4528.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4528 OpenLDAP Foundation
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- Assertion Control
-
-
-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 defines the Lightweight Directory Access Protocol
- (LDAP) Assertion Control, which allows a client to specify that a
- directory operation should only be processed if an assertion applied
- to the target entry of the operation is true. It can be used to
- construct "test and set", "test and clear", and other conditional
- operations.
-
-Table of Contents
-
- 1. Overview ........................................................2
- 2. Terminology .....................................................2
- 3. The Assertion Control ...........................................2
- 4. Security Considerations .........................................3
- 5. IANA Considerations .............................................4
- 5.1. Object Identifier ..........................................4
- 5.2. LDAP Protocol Mechanism ....................................4
- 5.3. LDAP Result Code ...........................................4
- 6. Acknowledgements ................................................5
- 7. References ......................................................5
- 7.1. Normative References .......................................5
- 7.2. Informative References .....................................5
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4528 LDAP Assertion Control June 2006
-
-
-1. Overview
-
- This document defines the Lightweight Directory Access Protocol
- (LDAP) [RFC4510] assertion control. The assertion control allows the
- client to specify a condition that must be true for the operation to
- be processed normally. Otherwise, the operation is not performed.
- For instance, the control can be used with the Modify operation
- [RFC4511] to perform atomic "test and set" and "test and clear"
- operations.
-
- The control may be attached to any update operation to support
- conditional addition, deletion, modification, and renaming of the
- target object. The asserted condition is evaluated as an integral
- part the operation.
-
- The control may also be used with the search operation. Here, the
- assertion is applied to the base object of the search before
- searching for objects that match the search scope and filter.
-
- The control may also be used with the compare operation. Here, it
- extends the compare operation to allow a more complex assertion.
-
-2. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded
- using the Basic Encoding Rules [X.690] under the restrictions
- detailed in Section 5.1 of [RFC4511].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
- 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
- [RFC2119].
-
-3. The Assertion Control
-
- The assertion control is an LDAP Control [RFC4511] whose controlType
- is 1.3.6.1.1.12 and whose controlValue is a BER-encoded Filter
- [Protocol, Section 4.5.1]. The criticality may be TRUE or FALSE.
- There is no corresponding response control.
-
- The control is appropriate for both LDAP interrogation and update
- operations [RFC4511], including Add, Compare, Delete, Modify,
- ModifyDN (rename), and Search. It is inappropriate for Abandon,
- Bind, Unbind, and StartTLS operations.
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4528 LDAP Assertion Control June 2006
-
-
- When the control is attached to an LDAP request, the processing of
- the request is conditional on the evaluation of the Filter as applied
- against the target of the operation. If the Filter evaluates to
- TRUE, then the request is processed normally. If the Filter
- evaluates to FALSE or Undefined, then assertionFailed (122)
- resultCode is returned, and no further processing is performed.
-
- For Add, Compare, and ModifyDN operations, the target is indicated by
- the entry field in the request. For Modify operations, the target is
- indicated by the object field. For Delete operations, the target is
- indicated by the DelRequest type. For Compare operations and all
- update operations, the evaluation of the assertion MUST be performed
- as an integral part of the operation. That is, the evaluation of the
- assertion and the normal processing of the operation SHALL be done as
- one atomic action.
-
- For Search operations, the target is indicated by the baseObject
- field, and the evaluation is done after "finding" but before
- "searching" [RFC4511]. Hence, no entries or continuations references
- are returned if the assertion fails.
-
- Servers implementing this technical specification SHOULD publish the
- object identifier 1.3.6.1.1.12 as a value of the 'supportedControl'
- attribute [RFC4512] in their root DSE. A server MAY choose to
- advertise this extension only when the client is authorized to use
- it.
-
- Other documents may specify how this control applies to other LDAP
- operations. In doing so, they must state how the target entry is
- determined.
-
-4. Security Considerations
-
- The filter may, like other components of the request, contain
- sensitive information. When it does, this information should be
- appropriately protected.
-
- As with any general assertion mechanism, the mechanism can be used to
- determine directory content. Hence, this mechanism SHOULD be subject
- to appropriate access controls.
-
- Some assertions may be very complex, requiring significant time and
- resources to evaluate. Hence, this mechanism SHOULD be subject to
- appropriate administrative controls.
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4528 LDAP Assertion Control June 2006
-
-
- Security considerations for the base operations [RFC4511] extended by
- this control, as well as general LDAP security considerations
- [RFC4510], generally apply to implementation and use of this
- extension.
-
-5. IANA Considerations
-
-5.1. Object Identifier
-
- The IANA has assigned an LDAP Object Identifier [RFC4520] to identify
- the LDAP Assertion Control defined in this document.
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4528
- Author/Change Controller: IESG
- Comments:
- Identifies the LDAP Assertion Control
-
-5.2. LDAP Protocol Mechanism
-
- Registration of this protocol mechanism [RFC4520] is requested.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.1.12
- Description: Assertion Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Control
- Specification: RFC 4528
- Author/Change Controller: IESG
- Comments: none
-
-5.3. LDAP Result Code
-
- The IANA has assigned an LDAP Result Code [RFC4520] called
- 'assertionFailed' (122).
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Result Code Name: assertionFailed
- Specification: RFC 4528
- Author/Change Controller: IESG
- Comments: none
-
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4528 LDAP Assertion Control June 2006
-
-
-6. Acknowledgements
-
- The assertion control concept is attributed to Morteza Ansari.
-
-7. References
-
-7.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [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.
-
- [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).
-
- [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(2002) (also
- ISO/IEC 8825-1:2002).
-
-7.2. Informative References
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4528 LDAP Assertion Control 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 6]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4529.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4529.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4529.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4529 OpenLDAP Foundation
-Category: Informational June 2006
-
-
- Requesting Attributes by Object Class in the
- Lightweight Directory Access Protocol (LDAP)
-
-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 (2006).
-
-Abstract
-
- The Lightweight Directory Access Protocol (LDAP) search operation
- provides mechanisms for clients to request all user application
- attributes, all operational attributes, and/or attributes selected by
- their description. This document extends LDAP to support a mechanism
- that LDAP clients may use to request the return of all attributes of
- an object class.
-
-Table of Contents
-
- 1. Background and Intended Use .....................................1
- 2. Terminology .....................................................2
- 3. Return of all Attributes of an Object Class .....................2
- 4. Security Considerations .........................................3
- 5. IANA Considerations .............................................3
- 6. References ......................................................4
- 6.1. Normative References .......................................4
- 6.2. Informative References .....................................4
-
-1. Background and Intended Use
-
- In the Lightweight Directory Access Protocol (LDAP) [RFC4510], the
- search operation [RFC4511] supports requesting the return of a set of
- attributes. This set is determined by a list of attribute
- descriptions. Two special descriptors are defined to request all
- user attributes ("*") [RFC4511] and all operational attributes ("+")
- [RFC3673]. However, there is no convenient mechanism for requesting
- pre-defined sets of attributes such as the set of attributes used to
- represent a particular class of object.
-
-
-
-Zeilenga Informational [Page 1]
-
-RFC 4529 Requesting Attributes by Object Class June 2006
-
-
- This document extends LDAP to allow an object class identifier to be
- specified in attributes lists, such as in Search requests, to request
- the return of all attributes belonging to an object class. The
- COMMERCIAL AT ("@", U+0040) character is used to distinguish an
- object class identifier from an attribute descriptions.
-
- For example, the attribute list of "@country" is equivalent to the
- attribute list of 'c', 'searchGuide', 'description', and
- 'objectClass'. This object class is described in [RFC4519].
-
- This extension is intended primarily to be used where the user is in
- direct control of the parameters of the LDAP search operation, for
- instance when entering an LDAP URL [RFC4516] into a web browser, such
- as <ldap:///dc=example,dc=com?@organization?base>.
-
-2. Terminology
-
- 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
- [RFC2119].
-
- DSA stands for Directory System Agent (or server).
- DSE stands for DSA-specific Entry.
-
-3. Return of All Attributes of an Object Class
-
- This extension allows object class identifiers to be provided in the
- attributes field of the LDAP SearchRequest [RFC4511] or other request
- values of the AttributeSelection data type (e.g., attributes field in
- pre/post read controls [ReadEntry]) and/or <attributeSelector>
- production (e.g., attributes of an LDAP URL [RFC4516]). For each
- object class identified in the attributes field, the request is to be
- treated as if each attribute allowed by that class (by "MUST" or
- "MAY", directly or by "SUP"erior) [RFC4512] were itself listed.
-
- This extension extends the <attributeSelector> [RFC4511] production
- as indicated by the following ABNF [RFC4234]:
-
- attributeSelector =/ objectclassdescription
- objectclassdescription = ATSIGN oid options
- ATSIGN = %x40 ; COMMERCIAL AT ("@" U+0040)
-
- where <oid> and <options> productions are as defined in [RFC4512].
-
-
-
-
-
-
-
-Zeilenga Informational [Page 2]
-
-RFC 4529 Requesting Attributes by Object Class June 2006
-
-
- The <oid> component of an <objectclassdescription> production
- identifies the object class by short name (descr) or object
- identifier (numericoid). If the value of the <oid> component is
- unrecognized or does not refer to an object class, the object class
- description is to be treated as an unrecognized attribute
- description.
-
- The <options> production is included in the grammar for extensibility
- purposes. An object class description with an unrecognized or
- inappropriate option is to be treated as unrecognized.
-
- Although object class description options and attribute description
- options share the same syntax, they are not semantically related.
- This document does not define any object description option.
-
- Servers supporting this feature SHOULD publish the object identifier
- (OID) 1.3.6.1.4.1.4203.1.5.2 as a value of the 'supportedFeatures'
- [RFC4512] attribute in the root DSE. Clients supporting this feature
- SHOULD NOT use the feature unless they know that the server supports
- it.
-
-4. Security Considerations
-
- This extension provides a shorthand for requesting all attributes of
- an object class. Because these attributes could have been listed
- individually, introduction of this shorthand is not believed to raise
- additional security considerations.
-
- Implementors of this LDAP extension should be familiar with security
- considerations applicable to the LDAP search operation [RFC4511], as
- well as with general LDAP security considerations [RFC4510].
-
-5. IANA Considerations
-
- Registration of the LDAP Protocol Mechanism [RFC4520] defined in this
- document has been completed.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.5.2
- Description: OC AD Lists
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Feature
- Specification: RFC 4529
- Author/Change Controller: Kurt Zeilenga <kurt at openldap.org>
- Comments: none
-
-
-
-
-
-Zeilenga Informational [Page 3]
-
-RFC 4529 Requesting Attributes by Object Class June 2006
-
-
- This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its
- IANA-assigned private enterprise allocation [PRIVATE], for use in
- this specification.
-
-6. References
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [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.
-
- [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
- Access Protocol (LDAP): Uniform Resource Locator", RFC
- 4516, June 2006.
-
- [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).
-
-6.2. Informative References
-
- [RFC3673] Zeilenga, K., "Lightweight Directory Access Protocol
- version 3 (LDAPv3): All Operational Attributes", RFC
- 3673, December 2003.
-
- [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 Informational [Page 4]
-
-RFC 4529 Requesting Attributes by Object Class June 2006
-
-
- [ReadEntry] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Read Entry Controls", RFC 4527, June 2006.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Informational [Page 5]
-
-RFC 4529 Requesting Attributes by Object Class 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 Informational [Page 6]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4530.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4530.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4530.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4530 OpenLDAP Foundation
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- entryUUID Operational Attribute
-
-
-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 LDAP/X.500 'entryUUID' operational
- attribute and associated matching rules and syntax. The attribute
- holds a server-assigned Universally Unique Identifier (UUID) for the
- object. Directory clients may use this attribute to distinguish
- objects identified by a distinguished name or to locate an object
- after renaming.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
-Table of Contents
-
- 1. Background and Intended Use .....................................2
- 2. UUID Schema Elements ............................................3
- 2.1. UUID Syntax ................................................3
- 2.2. 'uuidMatch' Matching Rule ..................................3
- 2.3. 'uuidOrderingMatch' Matching Rule ..........................3
- 2.4. 'entryUUID' Attribute ......................................4
- 3. Security Considerations .........................................4
- 4. IANA Considerations .............................................5
- 4.1. Object Identifier Registration .............................5
- 4.2. UUID Syntax Registration ...................................5
- 4.3. 'uuidMatch' Descriptor Registration ........................5
- 4.4. 'uuidOrderingMatch' Descriptor Registration ................5
- 4.5. 'entryUUID' Descriptor Registration ........................6
- 5. Acknowledgements ................................................6
- 6. References ......................................................6
- 6.1. Normative References .......................................6
- 6.2. Informative References .....................................7
-
-1. Background and Intended Use
-
- In X.500 Directory Services [X.501], such as those accessible using
- the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object
- is identified by its distinguished name (DN). However, DNs are not
- stable identifiers. That is, a new object may be identified by a DN
- that previously identified another (now renamed or deleted) object.
-
- A Universally Unique Identifier (UUID) is "an identifier unique
- across both space and time, with respect to the space of all UUIDs"
- [RFC4122]. UUIDs are used in a wide range of systems.
-
- This document describes the 'entryUUID' operational attribute, which
- holds the UUID assigned to the object by the server. Clients may use
- this attribute to distinguish objects identified by a particular
- distinguished name or to locate a particular object after renaming.
-
- This document defines the UUID syntax, the 'uuidMatch' and
- 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute
- type.
-
- Schema definitions are provided using LDAP description formats
- [RFC4512]. Definitions provided here are formatted (line wrapped)
- for readability.
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
- 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
- [RFC2119].
-
-2. UUID Schema Elements
-
-2.1. UUID Syntax
-
- A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128-
- bit) value that identifies an object. The ASN.1 [X.680] type UUID is
- defined to represent UUIDs as follows:
-
- UUID ::= OCTET STRING (SIZE(16))
- -- constrained to an UUID [RFC4122]
-
- In LDAP, UUID values are encoded using the [ASCII] character string
- representation described in [RFC4122]. For example,
- "597ae2f6-16a6-1027-98f4-d28b5365dc14".
-
- The following is an LDAP syntax description suitable for publication
- in subschema subentries.
-
- ( 1.3.6.1.1.16.1 DESC 'UUID' )
-
-2.2. 'uuidMatch' Matching Rule
-
- The 'uuidMatch' matching rule compares an asserted UUID with a stored
- UUID for equality. Its semantics are the same as the
- 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs
- from 'octetStringMatch' in that the assertion value is encoded using
- the UUID string representation instead of the normal OCTET STRING
- string representation.
-
- The following is an LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( 1.3.6.1.1.16.2 NAME 'uuidMatch'
- SYNTAX 1.3.6.1.1.16.1 )
-
-2.3. 'uuidOrderingMatch' Matching Rule
-
- The 'uuidOrderingMatch' matching rule compares an asserted UUID with
- a stored UUID for ordering. Its semantics are the same as the
- 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule
- differs from 'octetStringOrderingMatch' in that the assertion value
- is encoded using the UUID string representation instead of the normal
- OCTET STRING string representation.
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
- The following is an LDAP matching rule description suitable for
- publication in subschema subentries.
-
- ( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
- SYNTAX 1.3.6.1.1.16.1 )
-
- Note that not all UUID variants have a defined ordering; and even
- where it does, servers are not obligated to assign UUIDs in any
- particular order. This matching rule is provided for completeness.
-
-2.4. 'entryUUID' Attribute
-
- The 'entryUUID' operational attribute provides the Universally Unique
- Identifier (UUID) assigned to the entry.
-
- The following is an LDAP attribute type description suitable for
- publication in subschema subentries.
-
- ( 1.3.6.1.1.16.4 NAME 'entryUUID'
- DESC 'UUID of the entry'
- EQUALITY uuidMatch
- ORDERING uuidOrderingMatch
- SYNTAX 1.3.6.1.1.16.1
- SINGLE-VALUE
- NO-USER-MODIFICATION
- USAGE directoryOperation )
-
- Servers SHALL generate and assign a new UUID to each entry upon its
- addition to the directory and provide that UUID as the value of the
- 'entryUUID' operational attribute. An entry's UUID is immutable.
-
- UUID are to be generated in accordance with Section 4 of [RFC4122].
- In particular, servers MUST ensure that each generated UUID is unique
- in space and time.
-
-3. Security Considerations
-
- An entry's relative distinguish name (RDN) is composed from attribute
- values of the entry, which are commonly descriptive of the object the
- entry represents. Although deployers are encouraged to use naming
- attributes whose values are widely disclosable [RFC4514], entries are
- often named using information that cannot be disclosed to all
- parties. As UUIDs do not contain any descriptive information of the
- object they identify, UUIDs may be used to identify a particular
- entry without disclosure of its contents.
-
- General UUID security considerations [RFC4122] apply.
-
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
- General LDAP security considerations [RFC4510] apply.
-
-4. IANA Considerations
-
- The IANA has registered the LDAP values [RFC4520] specified in this
- document.
-
-4.1. Object Identifier Registration
-
- Subject: Request for LDAP OID Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4530
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID schema elements
-
-4.2. UUID Syntax Registration
-
- Subject: Request for LDAP Syntax Registration
- Object Identifier: 1.3.6.1.1.16.1
- Description: UUID
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4530
- Author/Change Controller: IESG
- Comments:
- Identifies the UUID syntax
-
-4.3. 'uuidMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidMatch
- Object Identifier: 1.3.6.1.1.16.2
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Usage: Matching Rule
- Specification: RFC 4530
- Author/Change Controller: IESG
-
-4.4. 'uuidOrderingMatch' Descriptor Registration
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): uuidOrderingMatch
- Object Identifier: 1.3.6.1.1.16.3
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Usage: Matching Rule
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
- Specification: RFC 4530
- Author/Change Controller: IESG
-
-4.5. 'entryUUID' Descriptor Registration
-
- The IANA has registered the LDAP 'entryUUID' descriptor.
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): entryUUID
- Object Identifier: 1.3.6.1.1.16.4
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Usage: Attribute Type
- Specification: RFC 4530
- Author/Change Controller: IESG
-
-5. Acknowledgements
-
- This document is based upon discussions in the LDAP Update and
- Duplication Protocols (LDUP) WG. Members of the LDAP Directorate
- provided review.
-
-6. References
-
-6.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
- Unique IDentifier (UUID) URN Namespace", RFC 4122, July
- 2005.
-
- [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.
-
- [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
- (LDAP): Syntaxes and Matching Rules", RFC 4517, June
- 2006.
-
- [ASCII] Coded Character Set--7-bit American Standard Code for
- Information Interchange, ANSI X3.4-1986.
-
-
-
-
-Zeilenga Standards Track [Page 6]
-
-RFC 4530 LDAP entryUUID June 2006
-
-
- [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).
-
- [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).
-
-6.2. Informative References
-
- [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
- Protocol (LDAP): String Representation of Distinguished
- Names", RFC 4514, June 2006.
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 7]
-
-RFC 4530 LDAP entryUUID 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 8]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4531.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4531.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4531.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4531 OpenLDAP Foundation
-Category: Experimental June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- Turn Operation
-
-
-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 (2006).
-
-Abstract
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) extended operation to reverse (or "turn") the roles of client
- and server for subsequent protocol exchanges in the session, or to
- enable each peer to act as both client and server with respect to the
- other.
-
-Table of Contents
-
- 1. Background and Intent of Use ....................................2
- 1.1. Terminology ................................................2
- 2. Turn Operation ..................................................2
- 2.1. Turn Request ...............................................3
- 2.2. Turn Response ..............................................3
- 3. Authentication ..................................................3
- 3.1. Use with TLS and Simple Authentication .....................4
- 3.2. Use with TLS and SASL EXTERNAL .............................4
- 3.3. Use of Mutual Authentication and SASL EXTERNAL .............4
- 4. TLS and SASL Security Layers ....................................5
- 5. Security Considerations .........................................6
- 6. IANA Considerations .............................................6
- 6.1. Object Identifier ..........................................6
- 6.2. LDAP Protocol Mechanism ....................................7
- 7. References ......................................................7
- 7.1. Normative References .......................................7
- 7.2. Informative References .....................................8
-
-
-
-
-Zeilenga Experimental [Page 1]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
-1. Background and Intent of Use
-
- The Lightweight Directory Access Protocol (LDAP) [RFC4510][RFC4511]
- is a client-server protocol that typically operates over reliable
- octet-stream transports, such as the Transport Control Protocol
- (TCP). Generally, the client initiates the stream by connecting to
- the server's listener at some well-known address.
-
- There are cases where it is desirable for the server to initiate the
- stream. Although it certainly is possible to write a technical
- specification detailing how to implement server-initiated LDAP
- sessions, this would require the design of new authentication and
- other security mechanisms to support server-initiated LDAP sessions.
-
- Instead, this document introduces an operation, the Turn operation,
- which may be used to reverse the client-server roles of the protocol
- peers. This allows the initiating protocol peer to become the server
- (after the reversal).
-
- As an additional feature, the Turn operation may be used to allow
- both peers to act in both roles. This is useful where both peers are
- directory servers that desire to request, as LDAP clients, that
- operations be performed by the other. This may be useful in
- replicated and/or distributed environments.
-
- This operation is intended to be used between protocol peers that
- have established a mutual agreement, by means outside of the
- protocol, that requires reversal of client-server roles, or allows
- both peers to act both as client and server.
-
-1.1. Terminology
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded
- using the Basic Encoding Rules [X.690] under the restrictions
- detailed in Section 5.1 of [RFC4511].
-
-2. Turn Operation
-
- The Turn operation is defined as an LDAP-Extended Operation
- [Protocol, Section 4.12] identified by the 1.3.6.1.1.19 OID. The
- function of the Turn Operation is to request that the client-server
- roles be reversed, or, optionally, to request that both protocol
- peers be able to act both as client and server in respect to the
- other.
-
-
-
-
-
-
-Zeilenga Experimental [Page 2]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
-2.1. Turn Request
-
- The Turn request is an ExtendedRequest where the requestName field
- contains the 1.3.6.1.1.19 OID and the requestValue field is a BER-
- encoded turnValue:
-
- turnValue ::= SEQUENCE {
- mutual BOOLEAN DEFAULT FALSE,
- identifier LDAPString
- }
-
- A TRUE mutual field value indicates a request to allow both peers to
- act both as client and server. A FALSE mutual field value indicates
- a request to reserve the client and server roles.
-
- The value of the identifier field is a locally defined policy
- identifier (typically associated with a mutual agreement for which
- this turn is be executed as part of).
-
-2.2. Turn Response
-
- A Turn response is an ExtendedResponse where the responseName and
- responseValue fields are absent. A resultCode of success is returned
- if and only if the responder is willing and able to turn the session
- as requested. Otherwise, a different resultCode is returned.
-
-3. Authentication
-
- This extension's authentication model assumes separate authentication
- of the peers in each of their roles. A separate Bind exchange is
- expected between the peers in their new roles to establish identities
- in these roles.
-
- Upon completion of the Turn, the responding peer in its new client
- role has an anonymous association at the initiating peer in its new
- server role. If the turn was mutual, the authentication association
- of the initiating peer in its pre-existing client role is left intact
- at the responding peer in its pre-existing server role. If the turn
- was not mutual, this association is void.
-
- The responding peer may establish its identity in its client role by
- requesting and successfully completing a Bind operation.
-
- The remainder of this section discusses some authentication
- scenarios. In the protocol exchange illustrations, A refers to the
- initiating peer (the original client) and B refers to the responding
- peer (the original server).
-
-
-
-
-Zeilenga Experimental [Page 3]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
-3.1. Use with TLS and Simple Authentication
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(Simple(cn=B,dc=example,dc=net,B's secret)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(Simple(cn=A,dc=example,dc=net,A's secret)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS (Transport Layer Security) [RFC4346] is started
- and the initiating peer (the original client) establishes its
- identity with the responding peer prior to the Turn using the
- DN/password mechanism of the Simple method of the Bind operation.
- After the turn, the responding peer, in its new client role,
- establishes its identity with the initiating peer in its new server
- role.
-
-3.2. Use with TLS and SASL EXTERNAL
-
- A->B: StartTLS Request
- B->A: StartTLS(success) Response
- A->B: Bind(SASL(EXTERNAL)) Request
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, TLS is started (with each peer providing a valid
- certificate), and the initiating peer (the original client)
- establishes its identity through the use of the EXTERNAL mechanism of
- the SASL (Simple Authentication and Security Layer) [RFC4422] method
- of the Bind operation prior to the Turn. After the turn, the
- responding peer, in its new client role, establishes its identity
- with the initiating peer in its new server role.
-
-3.3. Use of Mutual Authentication and SASL EXTERNAL
-
- A number of SASL mechanisms, such as GSSAPI [SASL-K5], support mutual
- authentication. The initiating peer, in its new server role, may use
- the identity of the responding peer, established by a prior
- authentication exchange, as its source for "external" identity in
- subsequent EXTERNAL exchange.
-
- A->B: Bind(SASL(GSSAPI)) Request
- <intermediate messages>
-
-
-
-Zeilenga Experimental [Page 4]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
- B->A: Bind(success) Response
- A->B: Turn(TRUE,"XXYYZ") Request
- B->A: Turn(success) Response
- B->A: Bind(SASL(EXTERNAL)) Request
- A->B: Bind(success) Response
-
- In this scenario, a GSSAPI mutual-authentication exchange is
- completed between the initiating peer (the original client) and the
- responding server (the original server) prior to the turn. After the
- turn, the responding peer, in its new client role, requests that the
- initiating peer utilize an "external" identity to establish its LDAP
- authorization identity.
-
-4. TLS and SASL Security Layers
-
- As described in [RFC4511], LDAP supports both Transport Layer
- Security (TLS) [RFC4346] and Simple Authentication and Security Layer
- (SASL) [RFC4422] security frameworks. The following table
- illustrates the relationship between the LDAP message layer, SASL
- layer, TLS layer, and transport connection within an LDAP session.
-
- +----------------------+
- | LDAP message layer |
- +----------------------+ > LDAP PDUs
- +----------------------+ < data
- | SASL layer |
- +----------------------+ > SASL-protected data
- +----------------------+ < data
- | TLS layer |
- Application +----------------------+ > TLS-protected data
- ------------+----------------------+ < data
- Transport | transport connection |
- +----------------------+
-
- This extension does not alter this relationship, nor does it remove
- the general restriction against multiple TLS layers, nor does it
- remove the general restriction against multiple SASL layers.
-
- As specified in [RFC4511], the StartTLS operation is used to initiate
- negotiation of a TLS layer. If a TLS is already installed, the
- StartTLS operation must fail. Upon establishment of the TLS layer,
- regardless of which peer issued the request to start TLS, the peer
- that initiated the LDAP session (the original client) performs the
- "server identity check", as described in Section 3.1.5 of [RFC4513],
- treating itself as the "client" and its peer as the "server".
-
- As specified in [RFC4422], a newly negotiated SASL security layer
- replaces the installed SASL security layer. Though the client/server
-
-
-
-Zeilenga Experimental [Page 5]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
- roles in LDAP, and hence SASL, may be reversed in subsequent
- exchanges, only one SASL security layer may be installed at any
- instance.
-
-5. Security Considerations
-
- Implementors should be aware that the reversing of client/server
- roles and/or allowing both peers to act as client and server likely
- introduces security considerations not foreseen by the authors of
- this document. In particular, the security implications of the
- design choices made in the authentication and data security models
- for this extension (discussed in Sections 3 and 4, respectively) are
- not fully studied. It is hoped that experimentation with this
- extension will lead to better understanding of the security
- implications of these models and other aspects of this extension, and
- that appropriate considerations will be documented in a future
- document. The following security considerations are apparent at this
- time.
-
- Implementors should take special care to process LDAP, SASL, TLS, and
- other events in the appropriate roles for the peers. Note that while
- the Turn reverses the client/server roles with LDAP, and in SASL
- authentication exchanges, it does not reverse the roles within the
- TLS layer or the transport connection.
-
- The responding server (the original server) should restrict use of
- this operation to authorized clients. Client knowledge of a valid
- identifier should not be the sole factor in determining authorization
- to turn.
-
- Where the peers except to establish TLS, TLS should be started prior
- to the Turn and any request to authenticate via the Bind operation.
-
- LDAP security considerations [RFC4511][RFC4513] generally apply to
- this extension.
-
-6. IANA Considerations
-
- The following values [RFC4520] have been registered by the IANA.
-
-6.1. Object Identifier
-
- The IANA has assigned an LDAP Object Identifier to identify the LDAP
- Turn Operation, as defined in this document.
-
-
-
-
-
-
-
-Zeilenga Experimental [Page 6]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
- Subject: Request for LDAP Object Identifier Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Specification: RFC 4531
- Author/Change Controller: Author
- Comments:
- Identifies the LDAP Turn Operation
-
-6.2. LDAP Protocol Mechanism
-
- The IANA has registered the LDAP Protocol Mechanism described in this
- document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.1.19
- Description: LDAP Turn Operation
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Extended Operation
- Specification: RFC 4531
- Author/Change Controller: Author
- Comments: none
-
-7. References
-
-7.1. Normative References
-
- [RFC4346] Dierks, T. and, E. Rescorla, "The Transport Layer
- Security (TLS) Protocol Version 1.1", RFC 4346, April
- 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.
-
- [RFC4513] Harrison, R., Ed., "Lightweight Directory Access
- Protocol (LDAP): Authentication Methods and Security
- Mechanisms", RFC 4513, June 2006.
-
-
-
-
-
-
-Zeilenga Experimental [Page 7]
-
-RFC 4531 LDAP Turn Operation June 2006
-
-
- [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).
-
- [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(2002) (also
- ISO/IEC 8825-1:2002).
-
-7.2. Informative References
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
- (IANA) Considerations for the Lightweight Directory
- Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [SASL-K5] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") SASL
- Mechanism", Work in Progress, May 2006.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Experimental [Page 8]
-
-RFC 4531 LDAP Turn Operation 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 Experimental [Page 9]
-
Deleted: branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4532.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4532.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4532.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4532 OpenLDAP Foundation
-Category: Standards Track June 2006
-
-
- Lightweight Directory Access Protocol (LDAP)
- "Who am I?" Operation
-
-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 specification provides a mechanism for Lightweight Directory
- Access Protocol (LDAP) clients to obtain the authorization identity
- the server has associated with the user or application entity. This
- mechanism is specified as an LDAP extended operation called the LDAP
- "Who am I?" operation.
-
-1. Background and Intent of Use
-
- This specification describes a Lightweight Directory Access Protocol
- (LDAP) [RFC4510] operation that clients can use to obtain the primary
- authorization identity, in its primary form, that the server has
- associated with the user or application entity. The operation is
- called the "Who am I?" operation.
-
- This specification is intended to replace the existing Authorization
- Identity Controls [RFC3829] mechanism, which uses Bind request and
- response controls to request and return the authorization identity.
- Bind controls are not protected by security layers established by the
- Bind operation that includes them. While it is possible to establish
- security layers using StartTLS [RFC4511][RFC4513] prior to the Bind
- operation, it is often desirable to use security layers established
- by the Bind operation. An extended operation sent after a Bind
- operation is protected by the security layers established by the Bind
- operation.
-
-
-
-
-
-Zeilenga Standards Track [Page 1]
-
-RFC 4532 LDAP "Who am I?" Operation June 2006
-
-
- There are other cases where it is desirable to request the
- authorization identity that the server associated with the client
- separately from the Bind operation. For example, the "Who am I?"
- operation can be augmented with a Proxied Authorization Control
- [RFC4370] to determine the authorization identity that the server
- associates with the identity asserted in the Proxied Authorization
- Control. The "Who am I?" operation can also be used prior to the
- Bind operation.
-
- Servers often associate multiple authorization identities with the
- client, and each authorization identity may be represented by
- multiple authzId [RFC4513] strings. This operation requests and
- returns the authzId that the server considers primary. In the
- specification, the term "the authorization identity" and "the
- authzId" are generally to be read as "the primary authorization
- identity" and the "the primary authzId", respectively.
-
-1.1. Conventions Used in This Document
-
- 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. The "Who am I?" Operation
-
- The "Who am I?" operation is defined as an LDAP Extended Operation
- [RFC4511] identified by the whoamiOID Object Identifier (OID). This
- section details the syntax of the operation's whoami request and
- response messages.
-
- whoamiOID ::= "1.3.6.1.4.1.4203.1.11.3"
-
-2.1. The whoami Request
-
- The whoami request is an ExtendedRequest with a requestName field
- containing the whoamiOID OID and an absent requestValue field. For
- example, a whoami request could be encoded as the sequence of octets
- (in hex):
-
- 30 1e 02 01 02 77 19 80 17 31 2e 33 2e 36 2e 31
- 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 31 31 2e 33
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 2]
-
-RFC 4532 LDAP "Who am I?" Operation June 2006
-
-
-2.2. The whoami Response
-
- The whoami response is an ExtendedResponse where the responseName
- field is absent and the response field, if present, is empty or an
- authzId [RFC4513]. For example, a whoami response returning the
- authzId "u:xxyyz at EXAMPLE.NET" (in response to the example request)
- would be encoded as the sequence of octets (in hex):
-
- 30 21 02 01 02 78 1c 0a 01 00 04 00 04 00 8b 13
- 75 3a 78 78 79 79 7a 40 45 58 41 4d 50 4c 45 2e
- 4e 45 54
-
-3. Operational Semantics
-
- The "Who am I?" operation provides a mechanism, a whoami Request, for
- the client to request that the server return the authorization
- identity it currently associates with the client. It also provides a
- mechanism, a whoami Response, for the server to respond to that
- request.
-
- Servers indicate their support for this extended operation by
- providing a whoamiOID object identifier as a value of the
- 'supportedExtension' attribute type in their root DSE. The server
- SHOULD advertise this extension only when the client is willing and
- able to perform this operation.
-
- If the server is willing and able to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with a success resultCode. If the server is treating
- the client as an anonymous entity, the response field is present but
- empty. Otherwise, the server provides the authzId [RFC4513]
- representing the authorization identity it currently associates with
- the client in the response field.
-
- If the server is unwilling or unable to provide the authorization
- identity it associates with the client, the server SHALL return a
- whoami Response with an appropriate non-success resultCode (such as
- operationsError, protocolError, confidentialityRequired,
- insufficientAccessRights, busy, unavailable, unwillingToPerform, or
- other) and an absent response field.
-
- As described in [RFC4511] and [RFC4513], an LDAP session has an
- "anonymous" association until the client has been successfully
- authenticated using the Bind operation. Clients MUST NOT invoke the
- "Who am I?" operation while any Bind operation is in progress,
- including between two Bind requests made as part of a multi-stage
-
-
-
-
-
-Zeilenga Standards Track [Page 3]
-
-RFC 4532 LDAP "Who am I?" Operation June 2006
-
-
- Bind operation. Where a whoami Request is received in violation of
- this absolute prohibition, the server should return a whoami Response
- with an operationsError resultCode.
-
-4. Extending the "Who am I?" Operation with Controls
-
- Future specifications may extend the "Who am I?" operation using the
- control mechanism [RFC4511]. When extended by controls, the "Who am
- I?" operation requests and returns the authorization identity the
- server associates with the client in a particular context indicated
- by the controls.
-
-4.1. Proxied Authorization Control
-
- The Proxied Authorization Control [RFC4370] is used by clients to
- request that the operation it is attached to operate under the
- authorization of an assumed identity. The client provides the
- identity to assume in the Proxied Authorization request control. If
- the client is authorized to assume the requested identity, the server
- executes the operation as if the requested identity had issued the
- operation.
-
- As servers often map the asserted authzId to another identity
- [RFC4513], it is desirable to request that the server provide the
- authzId it associates with the assumed identity.
-
- When a Proxied Authorization Control is be attached to the "Who am
- I?" operation, the operation requests the return of the authzId the
- server associates with the identity asserted in the Proxied
- Authorization Control. The authorizationDenied (123) result code is
- used to indicate that the server does not allow the client to assume
- the asserted identity.
-
-5. Security Considerations
-
- Identities associated with users may be sensitive information. When
- they are, security layers [RFC4511][RFC4513] should be established to
- protect this information. This mechanism is specifically designed to
- allow security layers established by a Bind operation to protect the
- integrity and/or confidentiality of the authorization identity.
-
- Servers may place access control or other restrictions upon the use
- of this operation. As stated in Section 3, the server SHOULD
- advertise this extension when it is willing and able to perform the
- operation.
-
- As with any other extended operations, general LDAP security
- considerations [RFC4510] apply.
-
-
-
-Zeilenga Standards Track [Page 4]
-
-RFC 4532 LDAP "Who am I?" Operation June 2006
-
-
-6. IANA Considerations
-
- The OID 1.3.6.1.4.1.4203.1.11.3 is used to identify the LDAP "Who am
- I?" extended operation. This OID was assigned [ASSIGN] by the
- OpenLDAP Foundation, under its IANA-assigned private enterprise
- allocation [PRIVATE], for use in this specification.
-
- Registration of this protocol mechanism [RFC4520] has been completed
- by the IANA.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.11.3
- Description: Who am I?
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Extended Operation
- Specification: RFC 4532
- Author/Change Controller: IESG
- Comments: none
-
-7. Acknowledgement
-
- This document borrows from prior work in this area, including
- "Authentication Response Control" [RFC3829] by Rob Weltman, Mark
- Smith, and Mark Wahl.
-
- The LDAP "Who am I?" operation takes it's name from the UNIX
- whoami(1) command. The whoami(1) command displays the effective user
- ID.
-
-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.
-
- [RFC4370] Weltman, R., "Lightweight Directory Access Protocol (LDAP)
- Proxied Authorization Control", RFC 4370, February 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.
-
-
-
-
-
-Zeilenga Standards Track [Page 5]
-
-RFC 4532 LDAP "Who am I?" Operation June 2006
-
-
- [RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol
- (LDAP): Authentication Methods and Security Mechanisms",
- RFC 4513, June 2006.
-
-8.2. Informative References
-
- [RFC3829] Weltman, R., Smith, M., and M. Wahl, "Lightweight Directory
- Access Protocol (LDAP) Authorization Identity Request and
- Response Controls", RFC 3829, July 2004.
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
-Author's Address
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga Standards Track [Page 6]
-
-RFC 4532 LDAP "Who am I?" Operation 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/rfc4533.txt
===================================================================
--- branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4533.txt 2010-01-10 17:48:14 UTC (rev 3218)
+++ branches/samba/upstream-3.5/source4/ldap_server/devdocs/rfc4533.txt 2010-01-12 21:04:43 UTC (rev 3219)
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-Network Working Group K. Zeilenga
-Request for Comments: 4533 OpenLDAP Foundation
-Category: Experimental J.H. Choi
- IBM Corporation
- June 2006
-
-
- The Lightweight Directory Access Protocol (LDAP)
- Content Synchronization Operation
-
-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 (2006).
-
-IESG Note
-
- The IESG notes that this work was originally discussed in the LDUP
- working group. The group came to consensus on a different approach,
- documented in RFC 3928; that document is on the standards track and
- should be reviewed by those considering implementation of this
- proposal.
-
-Abstract
-
- This specification describes the Lightweight Directory Access
- Protocol (LDAP) Content Synchronization Operation. The operation
- allows a client to maintain a copy of a fragment of the Directory
- Information Tree (DIT). It supports both polling for changes and
- listening for changes. The operation is defined as an extension of
- the LDAP Search Operation.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 1]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Background .................................................3
- 1.2. Intended Usage .............................................4
- 1.3. Overview ...................................................5
- 1.4. Conventions ................................................8
- 2. Elements of the Sync Operation ..................................8
- 2.1. Common ASN.1 Elements ......................................9
- 2.2. Sync Request Control .......................................9
- 2.3. Sync State Control ........................................10
- 2.4. Sync Done Control .........................................10
- 2.5. Sync Info Message .........................................11
- 2.6. Sync Result Codes .........................................11
- 3. Content Synchronization ........................................11
- 3.1. Synchronization Session ...................................12
- 3.2. Content Determination .....................................12
- 3.3. refreshOnly Mode ..........................................13
- 3.4. refreshAndPersist Mode ....................................16
- 3.5. Search Request Parameters .................................17
- 3.6. objectName ................................................18
- 3.7. Canceling the Sync Operation ..............................19
- 3.8. Refresh Required ..........................................19
- 3.9. Chattiness Considerations .................................20
- 3.10. Operation Multiplexing ...................................21
- 4. Meta Information Considerations ................................22
- 4.1. Entry DN ..................................................22
- 4.2. Operational Attributes ....................................22
- 4.3. Collective Attributes .....................................23
- 4.4. Access and Other Administrative Controls ..................23
- 5. Interaction with Other Controls ................................23
- 5.1. ManageDsaIT Control .......................................24
- 5.2. Subentries Control ........................................24
- 6. Shadowing Considerations .......................................24
- 7. Security Considerations ........................................25
- 8. IANA Considerations ............................................26
- 8.1. Object Identifier .........................................26
- 8.2. LDAP Protocol Mechanism ...................................26
- 8.3. LDAP Result Codes .........................................26
- 9. Acknowledgements ...............................................26
- 10. Normative References ..........................................27
- 11. Informative References ........................................28
- Appendix A. CSN-based Implementation Considerations ..............29
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 2]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-1. Introduction
-
- The Lightweight Directory Access Protocol (LDAP) [RFC4510] provides a
- mechanism, the search operation [RFC4511], that allows a client to
- request directory content matching a complex set of assertions and to
- request that the server return this content, subject to access
- control and other restrictions, to the client. However, LDAP does
- not provide (despite the introduction of numerous extensions in this
- area) an effective and efficient mechanism for maintaining
- synchronized copies of directory content. This document introduces a
- new mechanism specifically designed to meet the content
- synchronization requirements of sophisticated directory applications.
-
- This document defines the LDAP Content Synchronization Operation, or
- Sync Operation for short, which allows a client to maintain a
- synchronized copy of a fragment of a Directory Information Tree
- (DIT). The Sync Operation is defined as a set of controls and other
- protocol elements that extend the Search Operation.
-
-1.1. Background
-
- Over the years, a number of content synchronization approaches have
- been suggested for use in LDAP directory services. These approaches
- are inadequate for one or more of the following reasons:
-
- - failure to ensure a reasonable level of convergence;
-
- - failure to detect that convergence cannot be achieved (without
- reload);
-
- - require pre-arranged synchronization agreements;
-
- - require the server to maintain histories of past changes to DIT
- content and/or meta information;
-
- - require the server to maintain synchronization state on a per-
- client basis; and/or
-
- - are overly chatty.
-
- The Sync Operation provides eventual convergence of synchronized
- content when possible and, when not, notification that a full reload
- is required.
-
- The Sync Operation does not require pre-arranged synchronization
- agreements.
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 3]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- The Sync Operation does not require that servers maintain or use any
- history of past changes to the DIT or to meta information. However,
- servers may maintain and use histories (e.g., change logs,
- tombstones, DIT snapshots) to reduce the number of messages generated
- and to reduce their size. As it is not always feasible to maintain
- and use histories, the operation may be implemented using purely
- (current) state-based approaches. The Sync Operation allows use of
- either the state-based approach or the history-based approach on an
- operation-by-operation basis to balance the size of history and the
- amount of traffic. The Sync Operation also allows the combined use
- of the state-based and the history-based approaches.
-
- The Sync Operation does not require that servers maintain
- synchronization state on a per-client basis. However, servers may
- maintain and use per-client state information to reduce the number of
- messages generated and the size of such messages.
-
- A synchronization mechanism can be considered overly chatty when
- synchronization traffic is not reasonably bounded. The Sync
- Operation traffic is bounded by the size of updated (or new) entries
- and the number of unchanged entries in the content. The operation is
- designed to avoid full content exchanges, even when the history
- information available to the server is insufficient to determine the
- client's state. The operation is also designed to avoid transmission
- of out-of-content history information, as its size is not bounded by
- the content and it is not always feasible to transmit such history
- information due to security reasons.
-
- This document includes a number of non-normative appendices providing
- additional information to server implementors.
-
-1.2. Intended Usage
-
- The Sync Operation is intended to be used in applications requiring
- eventually-convergent content synchronization. Upon completion of
- each synchronization stage of the operation, all information to
- construct a synchronized client copy of the content has been provided
- to the client or the client has been notified that a complete content
- reload is necessary. Except for transient inconsistencies due to
- concurrent operation (or other) processing at the server, the client
- copy is an accurate reflection of the content held by the server.
- Transient inconsistencies will be resolved by subsequent
- synchronization operations.
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 4]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Possible uses include the following:
-
- - White page service applications may use the Sync Operation to
- maintain a current copy of a DIT fragment, for example, a mail
- user agent that uses the sync operation to maintain a local
- copy of an enterprise address book.
-
- - Meta-information engines may use the Sync Operation to maintain
- a copy of a DIT fragment.
-
- - Caching proxy services may use the Sync Operation to maintain a
- coherent content cache.
-
- - Lightweight master-slave replication between heterogeneous
- directory servers. For example, the Sync Operation can be used
- by a slave server to maintain a shadow copy of a DIT fragment.
- (Note: The International Telephone Union (ITU) has defined the
- X.500 Directory [X.500] Information Shadowing Protocol (DISP)
- [X.525], which may be used for master-slave replication between
- directory servers. Other experimental LDAP replication
- protocols also exist.)
-
- This protocol is not intended to be used in applications requiring
- transactional data consistency.
-
- As this protocol transfers all visible values of entries belonging to
- the content upon change instead of change deltas, this protocol is
- not appropriate for bandwidth-challenged applications or deployments.
-
-1.3. Overview
-
- This section provides an overview of basic ways the Sync Operation
- can be used to maintain a synchronized client copy of a DIT fragment.
-
- - Polling for changes: refreshOnly mode
-
- - Listening for changes: refreshAndPersist mode
-
-1.3.1. Polling for Changes (refreshOnly)
-
- To obtain its initial client copy, the client issues a Sync request:
- a search request with the Sync Request Control with mode set to
- refreshOnly. The server, much like it would with a normal search
- operation, returns (subject to access controls and other
- restrictions) the content matching the search criteria (baseObject,
- scope, filter, attributes). Additionally, with each entry returned,
- the server provides a Sync State Control indicating state add. This
- control contains the Universally Unique Identifier (UUID) [UUID] of
-
-
-
-Zeilenga & Choi Experimental [Page 5]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- the entry [RFC4530]. Unlike the Distinguished Name (DN), which may
- change over time, an entry's UUID is stable. The initial content is
- followed by a SearchResultDone with a Sync Done Control. The Sync
- Done Control provides a syncCookie. The syncCookie represents
- session state.
-
- To poll for updates to the client copy, the client reissues the Sync
- Operation with the syncCookie previously returned. The server, much
- as it would with a normal search operation, determines which content
- would be returned as if the operation were a normal search operation.
- However, using the syncCookie as an indicator of what content the
- client was sent previously, the server sends copies of entries that
- have changed with a Sync State Control indicating state add. For
- each changed entry, all (modified or unmodified) attributes belonging
- to the content are sent.
-
- The server may perform either or both of the two distinct
- synchronization phases that are distinguished by how to synchronize
- entries deleted from the content: the present and the delete phases.
- When the server uses a single phase for the refresh stage, each phase
- is marked as ended by a SearchResultDone with a Sync Done Control. A
- present phase is identified by a FALSE refreshDeletes value in the
- Sync Done Control. A delete phase is identified by a TRUE
- refreshDeletes value. The present phase may be followed by a delete
- phase. The two phases are delimited by a refreshPresent Sync Info
- Message having a FALSE refreshDone value. In the case that both the
- phases are used, the present phase is used to bring the client copy
- up to the state at which the subsequent delete phase can begin.
-
- In the present phase, the server sends an empty entry (i.e., no
- attributes) with a Sync State Control indicating state present for
- each unchanged entry.
-
- The delete phase may be used when the server can reliably determine
- which entries in the prior client copy are no longer present in the
- content and the number of such entries is less than or equal to the
- number of unchanged entries. In the delete mode, the server sends an
- empty entry with a Sync State Control indicating state delete for
- each entry that is no longer in the content, instead of returning an
- empty entry with state present for each present entry.
-
- The server may send syncIdSet Sync Info Messages containing the set
- of UUIDs of either unchanged present entries or deleted entries,
- instead of sending multiple individual messages. If refreshDeletes
- of syncIdSet is set to FALSE, the UUIDs of unchanged present entries
- are contained in the syncUUIDs set; if refreshDeletes of syncIdSet is
- set to TRUE, the UUIDs of the entries no longer present in the
- content are contained in the syncUUIDs set. An optional cookie can
-
-
-
-Zeilenga & Choi Experimental [Page 6]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- be included in the syncIdSet to represent the state of the content
- after synchronizing the presence or the absence of the entries
- contained in the syncUUIDs set.
-
- The synchronized copy of the DIT fragment is constructed by the
- client.
-
- If refreshDeletes of syncDoneValue is FALSE, the new copy includes
- all changed entries returned by the reissued Sync Operation, as well
- as all unchanged entries identified as being present by the reissued
- Sync Operation, but whose content is provided by the previous Sync
- Operation. The unchanged entries not identified as being present are
- deleted from the client content. They had been either deleted,
- moved, or otherwise scoped-out from the content.
-
- If refreshDeletes of syncDoneValue is TRUE, the new copy includes all
- changed entries returned by the reissued Sync Operation, as well as
- all other entries of the previous copy except for those that are
- identified as having been deleted from the content.
-
- The client can, at some later time, re-poll for changes to this
- synchronized client copy.
-
-1.3.2. Listening for Changes (refreshAndPersist)
-
- Polling for changes can be expensive in terms of server, client, and
- network resources. The refreshAndPersist mode allows for active
- updates of changed entries in the content.
-
- By selecting the refreshAndPersist mode, the client requests that the
- server send updates of entries that are changed after the initial
- refresh content is determined. Instead of sending a SearchResultDone
- Message as in polling, the server sends a Sync Info Message to the
- client indicating that the refresh stage is complete and then enters
- the persist stage. After receipt of this Sync Info Message, the
- client will construct a synchronized copy as described in Section
- 1.3.1.
-
- The server may then send change notifications as the result of the
- original Sync search request, which now remains persistent in the
- server. For entries to be added to the returned content, the server
- sends a SearchResultEntry (with attributes) with a Sync State Control
- indicating state add. For entries to be deleted from the content,
- the server sends a SearchResultEntry containing no attributes and a
- Sync State Control indicating state delete. For entries to be
- modified in the return content, the server sends a SearchResultEntry
- (with attributes) with a Sync State Control indicating state modify.
-
-
-
-
-Zeilenga & Choi Experimental [Page 7]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Upon modification of an entry, all (modified or unmodified)
- attributes belonging to the content are sent.
-
- Note that renaming an entry of the DIT may cause an add state change
- where the entry is renamed into the content, a delete state change
- where the entry is renamed out of the content, and a modify state
- change where the entry remains in the content. Also note that a
- modification of an entry of the DIT may cause an add, delete, or
- modify state change to the content.
-
- Upon receipt of a change notification, the client updates its copy of
- the content.
-
- If the server desires to update the syncCookie during the persist
- stage, it may include the syncCookie in any Sync State Control or
- Sync Info Message returned.
-
- The operation persists until canceled [RFC3909] by the client or
- terminated by the server. A Sync Done Control shall be attached to
- SearchResultDone Message to provide a new syncCookie.
-
-1.4. 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].
-
- Protocol elements are described using ASN.1 [X.680] with implicit
- tags. The term "BER-encoded" means the element is to be encoded
- using the Basic Encoding Rules [X.690] under the restrictions
- detailed in Section 5.1 of [RFC4511].
-
-2. Elements of the Sync Operation
-
- The Sync Operation is defined as an extension to the LDAP Search
- Operation [RFC4511] where the directory user agent (DUA or client)
- submits a SearchRequest Message with a Sync Request Control and the
- directory system agent (DSA or server) responds with zero or more
- SearchResultEntry Messages, each with a Sync State Control; zero or
- more SearchResultReference Messages, each with a Sync State Control;
- zero or more Sync Info Intermediate Response Messages; and a
- SearchResultDone Message with a Sync Done Control.
-
- To allow clients to discover support for this operation, servers
- implementing this operation SHOULD publish 1.3.6.1.4.1.4203.1.9.1.1
- as a value of the 'supportedControl' attribute [RFC4512] of the root
- DSA-specific entry (DSE). A server MAY choose to advertise this
- extension only when the client is authorized to use it.
-
-
-
-Zeilenga & Choi Experimental [Page 8]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-2.1. Common ASN.1 Elements
-
-2.1.1. syncUUID
-
- The syncUUID data type is an OCTET STRING holding a 128-bit
- (16-octet) Universally Unique Identifier (UUID) [UUID].
-
- syncUUID ::= OCTET STRING (SIZE(16))
- -- constrained to UUID
-
-2.1.2. syncCookie
-
- The syncCookie is a notational convenience to indicate that, while
- the syncCookie type is encoded as an OCTET STRING, its value is an
- opaque value containing information about the synchronization session
- and its state. Generally, the session information would include a
- hash of the operation parameters that the server requires not be
- changed and the synchronization state information would include a
- commit (log) sequence number, a change sequence number, or a time
- stamp. For convenience of description, the term "no cookie" refers
- either to a null cookie or to a cookie with pre-initialized
- synchronization state.
-
- syncCookie ::= OCTET STRING
-
-2.2. Sync Request Control
-
- The Sync Request Control is an LDAP Control [RFC4511] where the
- controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.1 and the
- controlValue, an OCTET STRING, contains a BER-encoded
- syncRequestValue. The criticality field is either TRUE or FALSE.
-
- syncRequestValue ::= SEQUENCE {
- mode ENUMERATED {
- -- 0 unused
- refreshOnly (1),
- -- 2 reserved
- refreshAndPersist (3)
- },
- cookie syncCookie OPTIONAL,
- reloadHint BOOLEAN DEFAULT FALSE
- }
-
- The Sync Request Control is only applicable to the SearchRequest
- Message.
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 9]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-2.3. Sync State Control
-
- The Sync State Control is an LDAP Control [RFC4511] where the
- controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.2 and the
- controlValue, an OCTET STRING, contains a BER-encoded syncStateValue.
- The criticality is FALSE.
-
- syncStateValue ::= SEQUENCE {
- state ENUMERATED {
- present (0),
- add (1),
- modify (2),
- delete (3)
- },
- entryUUID syncUUID,
- cookie syncCookie OPTIONAL
- }
-
- The Sync State Control is only applicable to SearchResultEntry and
- SearchResultReference Messages.
-
-2.4. Sync Done Control
-
- The Sync Done Control is an LDAP Control [RFC4511] where the
- controlType is the object identifier 1.3.6.1.4.1.4203.1.9.1.3 and the
- controlValue contains a BER-encoded syncDoneValue. The criticality
- is FALSE (and hence absent).
-
- syncDoneValue ::= SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE
- }
-
- The Sync Done Control is only applicable to the SearchResultDone
- Message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 10]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-2.5. Sync Info Message
-
- The Sync Info Message is an LDAP Intermediate Response Message
- [RFC4511] where responseName is the object identifier
- 1.3.6.1.4.1.4203.1.9.1.4 and responseValue contains a BER-encoded
- syncInfoValue. The criticality is FALSE (and hence absent).
-
- syncInfoValue ::= CHOICE {
- newcookie [0] syncCookie,
- refreshDelete [1] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- refreshPresent [2] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDone BOOLEAN DEFAULT TRUE
- },
- syncIdSet [3] SEQUENCE {
- cookie syncCookie OPTIONAL,
- refreshDeletes BOOLEAN DEFAULT FALSE,
- syncUUIDs SET OF syncUUID
- }
- }
-
-2.6. Sync Result Codes
-
- The following LDAP resultCode [RFC4511] is defined:
-
- e-syncRefreshRequired (4096)
-
-3. Content Synchronization
-
- The Sync Operation is invoked when the client sends a SearchRequest
- Message with a Sync Request Control.
-
- The absence of a cookie or an initialized synchronization state in a
- cookie indicates a request for initial content, while the presence of
- a cookie representing a state of a client copy indicates a request
- for a content update. Synchronization Sessions are discussed in
- Section 3.1. Content Determination is discussed in Section 3.2.
-
- The mode is either refreshOnly or refreshAndPersist. The refreshOnly
- and refreshAndPersist modes are discussed in Sections 3.3 and 3.4,
- respectively. The refreshOnly mode consists only of a refresh stage,
- while the refreshAndPersist mode consists of a refresh stage and a
- subsequent persist stage.
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 11]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-3.1. Synchronization Session
-
- A sequence of Sync Operations where the last cookie returned by the
- server for one operation is provided by the client in the next
- operation is said to belong to the same Synchronization Session.
-
- The client MUST specify the same content-controlling parameters (see
- Section 3.5) in each Search Request of the session. The client
- SHOULD also issue each Sync request of a session under the same
- authentication and authorization associations with equivalent
- integrity and protections. If the server does not recognize the
- request cookie or the request is made under different associations or
- non-equivalent protections, the server SHALL return the initial
- content as if no cookie had been provided or return an empty content
- with the e-syncRefreshRequired LDAP result code. The decision
- between the return of the initial content and the return of the empty
- content with the e-syncRefreshRequired result code MAY be based on
- reloadHint in the Sync Request Control from the client. If the
- server recognizes the request cookie as representing empty or initial
- synchronization state of the client copy, the server SHALL return the
- initial content.
-
- A Synchronization Session may span multiple LDAP sessions between the
- client and the server. The client SHOULD issue each Sync request of
- a session to the same server. (Note: Shadowing considerations are
- discussed in Section 6.)
-
-3.2. Content Determination
-
- The content to be provided is determined by parameters of the Search
- Request, as described in [RFC4511], and possibly other controls. The
- same content parameters SHOULD be used in each Sync request of a
- session. If different content is requested and the server is
- unwilling or unable to process the request, the server SHALL return
- the initial content as if no cookie had been provided or return an
- empty content with the e-syncRefreshRequired LDAP result code. The
- decision between the return of the initial content and the return of
- the empty content with the e-syncRefreshRequired result code MAY be
- based on reloadHint in the Sync Request Control from the client.
-
- The content may not necessarily include all entries or references
- that would be returned by a normal search operation, nor, for those
- entries included, all attributes returned by a normal search. When
- the server is unwilling or unable to provide synchronization for any
- attribute for a set of entries, the server MUST treat all filter
- components matching against these attributes as Undefined and MUST
- NOT return these attributes in SearchResultEntry responses.
-
-
-
-
-Zeilenga & Choi Experimental [Page 12]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Servers SHOULD support synchronization for all non-collective user-
- application attributes for all entries.
-
- The server may also return continuation references to other servers
- or to itself. The latter is allowed as the server may partition the
- entries it holds into separate synchronization contexts.
-
- The client may chase all or some of these continuations, each as a
- separate content synchronization session.
-
-3.3. refreshOnly Mode
-
- A Sync request with mode refreshOnly and with no cookie is a poll for
- initial content. A Sync request with mode refreshOnly and with a
- cookie representing a synchronization state is a poll for content
- update.
-
-3.3.1. Initial Content Poll
-
- Upon receipt of the request, the server provides the initial content
- using a set of zero or more SearchResultEntry and
- SearchResultReference Messages followed by a SearchResultDone
- Message.
-
- Each SearchResultEntry Message SHALL include a Sync State Control of
- state add, an entryUUID containing the entry's UUID, and no cookie.
- Each SearchResultReference Message SHALL include a Sync State Control
- of state add, an entryUUID containing the UUID associated with the
- reference (normally the UUID of the associated named referral
- [RFC3296] object), and no cookie. The SearchResultDone Message SHALL
- include a Sync Done Control having refreshDeletes set to FALSE.
-
- A resultCode value of success indicates that the operation
- successfully completed. Otherwise, the result code indicates the
- nature of the failure. The server may return e-syncRefreshRequired
- result code on the initial content poll if it is safe to do so when
- it is unable to perform the operation due to various reasons.
- reloadHint is set to FALSE in the SearchRequest Message requesting
- the initial content poll.
-
- If the operation is successful, a cookie representing the
- synchronization state of the current client copy SHOULD be returned
- for use in subsequent Sync Operations.
-
-3.3.2. Content Update Poll
-
- Upon receipt of the request, the server provides the content refresh
- using a set of zero or more SearchResultEntry and
-
-
-
-Zeilenga & Choi Experimental [Page 13]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- SearchResultReference Messages followed by a SearchResultDone
- Message.
-
- The server is REQUIRED to:
-
- a) provide the sequence of messages necessary for eventual
- convergence of the client's copy of the content to the server's
- copy,
-
- b) treat the request as an initial content request (e.g., ignore
- the cookie or the synchronization state represented in the
- cookie),
-
- c) indicate that the incremental convergence is not possible by
- returning e-syncRefreshRequired,
-
- d) return a resultCode other than success or e-
- syncRefreshRequired.
-
- A Sync Operation may consist of a single present phase, a single
- delete phase, or a present phase followed by a delete phase.
-
- In each phase, for each entry or reference that has been added to the
- content or been changed since the previous Sync Operation indicated
- by the cookie, the server returns a SearchResultEntry or
- SearchResultReference Message, respectively, each with a Sync State
- Control consisting of state add, an entryUUID containing the UUID of
- the entry or reference, and no cookie. Each SearchResultEntry
- Message represents the current state of a changed entry. Each
- SearchResultReference Message represents the current state of a
- changed reference.
-
- In the present phase, for each entry that has not been changed since
- the previous Sync Operation, an empty SearchResultEntry is returned
- whose objectName reflects the entry's current DN, whose attributes
- field is empty, and whose Sync State Control consists of state
- present, an entryUUID containing the UUID of the entry, and no
- cookie. For each reference that has not been changed since the
- previous Sync Operation, an empty SearchResultReference containing an
- empty SEQUENCE OF LDAPURL is returned with a Sync State Control
- consisting of state present, an entryUUID containing the UUID of the
- entry, and no cookie. No messages are sent for entries or references
- that are no longer in the content.
-
- Multiple empty entries with a Sync State Control of state present
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to FALSE. syncUUIDs contain a set of
- UUIDs of the entries and references unchanged since the last Sync
-
-
-
-Zeilenga & Choi Experimental [Page 14]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Operation. syncUUIDs may be empty. The Sync Info Message of
- syncIdSet may contain a cookie to represent the state of the content
- after performing the synchronization of the entries in the set.
-
- In the delete phase, for each entry no longer in the content, the
- server returns a SearchResultEntry whose objectName reflects a past
- DN of the entry or is empty, whose attributes field is empty, and
- whose Sync State Control consists of state delete, an entryUUID
- containing the UUID of the deleted entry, and no cookie. For each
- reference no longer in the content, a SearchResultReference
- containing an empty SEQUENCE OF LDAPURL is returned with a Sync State
- Control consisting of state delete, an entryUUID containing the UUID
- of the deleted reference, and no cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references that have been deleted from the
- content since the last Sync Operation. syncUUIDs may be empty. The
- Sync Info Message of syncIdSet may contain a cookie to represent the
- state of the content after performing the synchronization of the
- entries in the set.
-
- When a present phase is followed by a delete phase, the two phases
- are delimited by a Sync Info Message containing syncInfoValue of
- refreshPresent, which may contain a cookie representing the state
- after completing the present phase. The refreshPresent contains
- refreshDone, which is always FALSE in the refreshOnly mode of Sync
- Operation because it is followed by a delete phase.
-
- If a Sync Operation consists of a single phase, each phase and hence
- the Sync Operation are marked as ended by a SearchResultDone Message
- with Sync Done Control, which SHOULD contain a cookie representing
- the state of the content after completing the Sync Operation. The
- Sync Done Control contains refreshDeletes, which is set to FALSE for
- the present phase and set to TRUE for the delete phase.
-
- If a Sync Operation consists of a present phase followed by a delete
- phase, the Sync Operation is marked as ended at the end of the delete
- phase by a SearchResultDone Message with Sync Done Control, which
- SHOULD contain a cookie representing the state of the content after
- completing the Sync Operation. The Sync Done Control contains
- refreshDeletes, which is set to TRUE.
-
- The client can specify whether it prefers to receive an initial
- content by supplying reloadHint of TRUE or to receive a e-
- syncRefreshRequired resultCode by supplying reloadHint of FALSE
- (hence absent), in the case that the server determines that it is
-
-
-
-Zeilenga & Choi Experimental [Page 15]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- impossible or inefficient to achieve the eventual convergence by
- continuing the current incremental synchronization thread.
-
- A resultCode value of success indicates that the operation is
- successfully completed. A resultCode value of e-syncRefreshRequired
- indicates that a full or partial refresh is needed. Otherwise, the
- result code indicates the nature of failure. A cookie is provided in
- the Sync Done Control for use in subsequent Sync Operations for
- incremental synchronization.
-
-3.4. refreshAndPersist Mode
-
- A Sync request with mode refreshAndPersist asks for initial content
- or content update (during the refresh stage) followed by change
- notifications (during the persist stage).
-
-3.4.1. refresh Stage
-
- The content refresh is provided as described in Section 3.3, except
- that the successful completion of content refresh is indicated by
- sending a Sync Info Message of refreshDelete or refreshPresent with a
- refreshDone value set to TRUE instead of a SearchResultDone Message
- with resultCode success. A cookie SHOULD be returned in the Sync
- Info Message to represent the state of the content after finishing
- the refresh stage of the Sync Operation.
-
-3.4.2. persist Stage
-
- Change notifications are provided during the persist stage.
-
- As updates are made to the DIT, the server notifies the client of
- changes to the content. DIT updates may cause entries and references
- to be added to the content, deleted from the content, or modified
- within the content. DIT updates may also cause references to be
- added, deleted, or modified within the content.
-
- Where DIT updates cause an entry to be added to the content, the
- server provides a SearchResultEntry Message that represents the entry
- as it appears in the content. The message SHALL include a Sync State
- Control with state of add, an entryUUID containing the entry's UUID,
- and an optional cookie.
-
- Where DIT updates cause a reference to be added to the content, the
- server provides a SearchResultReference Message that represents the
- reference in the content. The message SHALL include a Sync State
- Control with state of add, an entryUUID containing the UUID
- associated with the reference, and an optional cookie.
-
-
-
-
-Zeilenga & Choi Experimental [Page 16]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Where DIT updates cause an entry to be modified within the content,
- the server provides a SearchResultEntry Message that represents the
- entry as it appears in the content. The message SHALL include a Sync
- State Control with state of modify, an entryUUID containing the
- entry's UUID, and an optional cookie.
-
- Where DIT updates cause a reference to be modified within the
- content, the server provides a SearchResultReference Message that
- represents the reference in the content. The message SHALL include a
- Sync State Control with state of modify, an entryUUID containing the
- UUID associated with the reference, and an optional cookie.
-
- Where DIT updates cause an entry to be deleted from the content, the
- server provides a SearchResultEntry Message with no attributes. The
- message SHALL include a Sync State Control with state of delete, an
- entryUUID containing the entry's UUID, and an optional cookie.
-
- Where DIT updates cause a reference to be deleted from the content,
- the server provides a SearchResultReference Message with an empty
- SEQUENCE OF LDAPURL. The message SHALL include a Sync State Control
- with state of delete, an entryUUID containing the UUID associated
- with the reference, and an optional cookie.
-
- Multiple empty entries with a Sync State Control of state delete
- SHOULD be coalesced into one or more Sync Info Messages of syncIdSet
- value with refreshDeletes set to TRUE. syncUUIDs contain a set of
- UUIDs of the entries and references that have been deleted from the
- content. The Sync Info Message of syncIdSet may contain a cookie to
- represent the state of the content after performing the
- synchronization of the entries in the set.
-
- With each of these messages, the server may provide a new cookie to
- be used in subsequent Sync Operations. Additionally, the server may
- also return Sync Info Messages of choice newCookie to provide a new
- cookie. The client SHOULD use the newest (last) cookie it received
- from the server in subsequent Sync Operations.
-
-3.5. Search Request Parameters
-
- As stated in Section 3.1, the client SHOULD specify the same
- content-controlling parameters in each Search Request of the session.
- All fields of the SearchRequest Message are considered content-
- controlling parameters except for sizeLimit and timeLimit.
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 17]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-3.5.1. baseObject
-
- As with the normal search operation, the refresh and persist stages
- are not isolated from DIT changes. It is possible that the entry
- referred to by the baseObject is deleted, renamed, or moved. It is
- also possible that the alias object used in finding the entry
- referred to by the baseObject is changed such that the baseObject
- refers to a different entry.
-
- If the DIT is updated during processing of the Sync Operation in a
- manner that causes the baseObject no longer to refer to any entry or
- in a manner that changes the entry the baseObject refers to, the
- server SHALL return an appropriate non-success result code, such as
- noSuchObject, aliasProblem, aliasDereferencingProblem, referral, or
- e-syncRefreshRequired.
-
-3.5.2. derefAliases
-
- This operation does not support alias dereferencing during searching.
- The client SHALL specify neverDerefAliases or derefFindingBaseObj for
- the SearchRequest derefAliases parameter. The server SHALL treat
- other values (e.g., derefInSearching, derefAlways) as protocol
- errors.
-
-3.5.3. sizeLimit
-
- The sizeLimit applies only to entries (regardless of their state in
- Sync State Control) returned during the refreshOnly operation or the
- refresh stage of the refreshAndPersist operation.
-
-3.5.4. timeLimit
-
- For a refreshOnly Sync Operation, the timeLimit applies to the whole
- operation. For a refreshAndPersist operation, the timeLimit applies
- only to the refresh stage including the generation of the Sync Info
- Message with a refreshDone value of TRUE.
-
-3.5.5. filter
-
- The client SHOULD avoid filter assertions that apply to the values of
- the attributes likely to be considered by the server as ones holding
- meta-information. See Section 4.
-
-3.6. objectName
-
- The Sync Operation uses entryUUID values provided in the Sync State
- Control as the primary keys to entries. The client MUST use these
- entryUUIDs to correlate synchronization messages.
-
-
-
-Zeilenga & Choi Experimental [Page 18]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- In some circumstances, the DN returned may not reflect the entry's
- current DN. In particular, when the entry is being deleted from the
- content, the server may provide an empty DN if the server does not
- wish to disclose the entry's current DN (or, if deleted from the DIT,
- the entry's last DN).
-
- Also note that the entry's DN may be viewed as meta information (see
- Section 4.1).
-
-3.7. Canceling the Sync Operation
-
- Servers MUST implement the LDAP Cancel [RFC3909] Operation and
- support cancellation of outstanding Sync Operations as described
- here.
-
- To cancel an outstanding Sync Operation, the client issues an LDAP
- Cancel [RFC3909] Operation.
-
- If at any time the server becomes unwilling or unable to continue
- processing a Sync Operation, the server SHALL return a
- SearchResultDone with a non-success resultCode indicating the reason
- for the termination of the operation.
-
- Whether the client or the server initiated the termination, the
- server may provide a cookie in the Sync Done Control for use in
- subsequent Sync Operations.
-
-3.8. Refresh Required
-
- In order to achieve the eventually-convergent synchronization, the
- server may terminate the Sync Operation in the refresh or persist
- stages by returning an e-syncRefreshRequired resultCode to the
- client. If no cookie is provided, a full refresh is needed. If a
- cookie representing a synchronization state is provided in this
- response, an incremental refresh is needed.
-
- To obtain a full refresh, the client then issues a new
- synchronization request with no cookie. To obtain an incremental
- reload, the client issues a new synchronization with the provided
- cookie.
-
- The server may choose to provide a full copy in the refresh stage
- (e.g., ignore the cookie or the synchronization state represented in
- the cookie) instead of providing an incremental refresh in order to
- achieve the eventual convergence.
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 19]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- The decision between the return of the initial content and the return
- of the e-syncRefreshRequired result code may be based on reloadHint
- in the Sync Request Control from the client.
-
- In the case of persist stage Sync, the server returns the resultCode
- of e-syncRefreshRequired to the client to indicate that the client
- needs to issue a new Sync Operation in order to obtain a synchronized
- copy of the content. If no cookie is provided, a full refresh is
- needed. If a cookie representing a synchronization state is
- provided, an incremental refresh is needed.
-
- The server may also return e-syncRefreshRequired if it determines
- that a refresh would be more efficient than sending all the messages
- required for convergence.
-
- Note that the client may receive one or more of SearchResultEntry,
- SearchResultReference, and/or Sync Info Messages before it receives a
- SearchResultDone Message with the e-syncRefreshRequired result code.
-
-3.9. Chattiness Considerations
-
- The server MUST ensure that the number of entry messages generated to
- refresh the client content does not exceed the number of entries
- presently in the content. While there is no requirement for servers
- to maintain history information, if the server has sufficient history
- to allow it to reliably determine which entries in the prior client
- copy are no longer present in the content and the number of such
- entries is less than or equal to the number of unchanged entries, the
- server SHOULD generate delete entry messages instead of present entry
- messages (see Section 3.3.2).
-
- When the amount of history information maintained in the server is
- not enough for the clients to perform infrequent refreshOnly Sync
- Operations, it is likely that the server has incomplete history
- information (e.g., due to truncation) by the time those clients
- connect again.
-
- The server SHOULD NOT resort to full reload when the history
- information is not enough to generate delete entry messages. The
- server SHOULD generate either present entry messages only or present
- entry messages followed by delete entry messages to bring the client
- copy to the current state. In the latter case, the present entry
- messages bring the client copy to a state covered by the history
- information maintained in the server.
-
- The server SHOULD maintain enough (current or historical) state
- information (such as a context-wide last modify time stamp) to
- determine if no changes were made in the context since the content
-
-
-
-Zeilenga & Choi Experimental [Page 20]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- refresh was provided and, when no changes were made, generate zero
- delete entry messages instead of present messages.
-
- The server SHOULD NOT use the history information when its use does
- not reduce the synchronization traffic or when its use can expose
- sensitive information not allowed to be received by the client.
-
- The server implementor should also consider chattiness issues that
- span multiple Sync Operations of a session. As noted in Section 3.8,
- the server may return e-syncRefreshRequired if it determines that a
- reload would be more efficient than continuing under the current
- operation. If reloadHint in the Sync Request is TRUE, the server may
- initiate a reload without directing the client to request a reload.
-
- The server SHOULD transfer a new cookie frequently to avoid having to
- transfer information already provided to the client. Even where DIT
- changes do not cause content synchronization changes to be
- transferred, it may be advantageous to provide a new cookie using a
- Sync Info Message. However, the server SHOULD avoid overloading the
- client or network with Sync Info Messages.
-
- During persist mode, the server SHOULD coalesce multiple outstanding
- messages updating the same entry. The server MAY delay generation of
- an entry update in anticipation of subsequent changes to that entry
- that could be coalesced. The length of the delay should be long
- enough to allow coalescing of update requests issued back to back but
- short enough that the transient inconsistency induced by the delay is
- corrected in a timely manner.
-
- The server SHOULD use the syncIdSet Sync Info Message when there are
- multiple delete or present messages to reduce the amount of
- synchronization traffic.
-
- Also note that there may be many clients interested in a particular
- directory change, and that servers attempting to service all of these
- at once may cause congestion on the network. The congestion issues
- are magnified when the change requires a large transfer to each
- interested client. Implementors and deployers of servers should take
- steps to prevent and manage network congestion.
-
-3.10. Operation Multiplexing
-
- The LDAP protocol model [RFC4511] allows operations to be multiplexed
- over a single LDAP session. Clients SHOULD NOT maintain multiple
- LDAP sessions with the same server. Servers SHOULD ensure that
- responses from concurrently processed operations are interleaved
- fairly.
-
-
-
-
-Zeilenga & Choi Experimental [Page 21]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Clients SHOULD combine Sync Operations whose result set is largely
- overlapping. This avoids having to return multiple messages, once
- for each overlapping session, for changes to entries in the overlap.
-
- Clients SHOULD NOT combine Sync Operations whose result sets are
- largely non-overlapping. This ensures that an event requiring an
- e-syncRefreshRequired response can be limited to as few result sets
- as possible.
-
-4. Meta Information Considerations
-
-4.1. Entry DN
-
- As an entry's DN is constructed from its relative DN (RDN) and the
- entry's parent's DN, it is often viewed as meta information.
-
- While renaming or moving to a new superior causes the entry's DN to
- change, that change SHOULD NOT, by itself, cause synchronization
- messages to be sent for that entry. However, if the renaming or the
- moving could cause the entry to be added or deleted from the content,
- appropriate synchronization messages should be generated to indicate
- this to the client.
-
- When a server treats the entry's DN as meta information, the server
- SHALL either
-
- - evaluate all MatchingRuleAssertions [RFC4511] to TRUE if
- matching a value of an attribute of the entry, otherwise
- Undefined, or
-
- - evaluate all MatchingRuleAssertion with dnAttributes of TRUE as
- Undefined.
-
- The latter choice is offered for ease of server implementation.
-
-4.2. Operational Attributes
-
- Where values of an operational attribute are determined by values not
- held as part of the entry it appears in, the operational attribute
- SHOULD NOT support synchronization of that operational attribute.
-
- For example, in servers that implement the X.501 subschema model
- [X.501], servers should not support synchronization of the
- subschemaSubentry attribute as its value is determined by values held
- and administrated in subschema subentries.
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 22]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- As a counter example, servers that implement aliases [RFC4512][X.501]
- can support synchronization of the aliasedObjectName attribute as its
- values are held and administrated as part of the alias entries.
-
- Servers SHOULD support synchronization of the following operational
- attributes: createTimestamp, modifyTimestamp, creatorsName,
- modifiersName [RFC4512]. Servers MAY support synchronization of
- other operational attributes.
-
-4.3. Collective Attributes
-
- A collective attribute is "a user attribute whose values are the same
- for each member of an entry collection" [X.501]. Use of collective
- attributes in LDAP is discussed in [RFC3671].
-
- Modification of a collective attribute generally affects the content
- of multiple entries, which are the members of the collection. It is
- inefficient to include values of collective attributes visible in
- entries of the collection, as a single modification of a collective
- attribute requires transmission of multiple SearchResultEntry (one
- for each entry of the collection that the modification affected).
-
- Servers SHOULD NOT synchronize collective attributes appearing in
- entries of any collection. Servers MAY support synchronization of
- collective attributes appearing in collective attribute subentries.
-
-4.4. Access and Other Administrative Controls
-
- Entries are commonly subject to access and other administrative
- Controls. While portions of the policy information governing a
- particular entry may be held in the entry, policy information is
- often held elsewhere (in superior entries, in subentries, in the root
- DSE, in configuration files, etc.). Because of this, changes to
- policy information make it difficult to ensure eventual convergence
- during incremental synchronization.
-
- Where it is impractical or infeasible to generate content changes
- resulting from a change to policy information, servers may opt to
- return e-syncRefreshRequired or to treat the Sync Operation as an
- initial content request (e.g., ignore the cookie or the
- synchronization state represented in the cookie).
-
-5. Interaction with Other Controls
-
- The Sync Operation may be used with:
-
- - ManageDsaIT Control [RFC3296]
-
-
-
-
-Zeilenga & Choi Experimental [Page 23]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- - Subentries Control [RFC3672]
-
- as described below. The Sync Operation may be used with other LDAP
- extensions as detailed in other documents.
-
-5.1. ManageDsaIT Control
-
- The ManageDsaIT Control [RFC3296] indicates that the operation acts
- upon the DSA Information Tree and causes referral and other special
- entries to be treated as object entries with respect to the
- operation.
-
-5.2. Subentries Control
-
- The Subentries Control is used with the search operation "to control
- the visibility of entries and subentries which are within scope"
- [RFC3672]. When used with the Sync Operation, the subentries control
- and other factors (search scope, filter, etc.) are used to determine
- whether an entry or subentry appears in the content.
-
-6. Shadowing Considerations
-
- As noted in [RFC4511], some servers may hold shadow copies of entries
- that can be used to answer search and comparison queries. Such
- servers may also support content synchronization requests. This
- section discusses considerations for implementors and deployers for
- the implementation and deployment of the Sync operation in shadowed
- directories.
-
- While a client may know of multiple servers that are equally capable
- of being used to obtain particular directory content from, a client
- SHOULD NOT assume that each of these servers is equally capable of
- continuing a content synchronization session. As stated in Section
- 3.1, the client SHOULD issue each Sync request of a Sync session to
- the same server.
-
- However, through domain naming or IP address redirection or other
- techniques, multiple physical servers can be made to appear as one
- logical server to a client. Only servers that are equally capable in
- regards to their support for the Sync operation and that hold equally
- complete copies of the entries should be made to appear as one
- logical server. In particular, each physical server acting as one
- logical server SHOULD be equally capable of continuing a content
- synchronization based upon cookies provided by any of the other
- physical servers without requiring a full reload. Because there is
- no standard LDAP shadowing mechanism, the specification of how to
- independently implement equally capable servers (as well as the
- precise definition of "equally capable") is left to future documents.
-
-
-
-Zeilenga & Choi Experimental [Page 24]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- Note that it may be difficult for the server to reliably determine
- what content was provided to the client by another server, especially
- in the shadowing environments that allow shadowing events to be
- coalesced. For these servers, the use of the delete phase discussed
- in Section 3.3.2 may not be applicable.
-
-7. Security Considerations
-
- In order to maintain a synchronized copy of the content, a client is
- to delete information from its copy of the content as described
- above. However, the client may maintain knowledge of information
- disclosed to it by the server separate from its copy of the content
- used for synchronization. Management of this knowledge is beyond the
- scope of this document. Servers should be careful not to disclose
- information for content the client is not authorized to have
- knowledge of and/or about.
-
- While the information provided by a series of refreshOnly Sync
- Operations is similar to that provided by a series of Search
- Operations, persist stage may disclose additional information. A
- client may be able to discern information about the particular
- sequence of update operations that caused content change.
-
- Implementors should take precautions against malicious cookie
- content, including malformed cookies or valid cookies used with
- different security associations and/or protections in an attempt to
- obtain unauthorized access to information. Servers may include a
- digital signature in the cookie to detect tampering.
-
- The operation may be the target of direct denial-of-service attacks.
- Implementors should provide safeguards to ensure the operation is not
- abused. Servers may place access control or other restrictions upon
- the use of this operation.
-
- Note that even small updates to the directory may cause a significant
- amount of traffic to be generated to clients using this operation. A
- user could abuse its update privileges to mount an indirect denial of
- service to these clients, other clients, and/or portions of the
- network. Servers should provide safeguards to ensure that update
- operations are not abused.
-
- Implementors of this (or any) LDAP extension should be familiar with
- general LDAP security considerations [RFC4510].
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 25]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-8. IANA Considerations
-
- Registration of the following values have been completed by the IANA
- [RFC4520].
-
-8.1. Object Identifier
-
- The OID arc 1.3.6.1.4.1.4203.1.9.1 was assigned [ASSIGN] by the
- OpenLDAP Foundation, under its IANA-assigned private enterprise
- allocation [PRIVATE], for use in this specification.
-
-8.2. LDAP Protocol Mechanism
-
- The IANA has registered the LDAP Protocol Mechanism described in this
- document.
-
- Subject: Request for LDAP Protocol Mechanism Registration
- Object Identifier: 1.3.6.1.4.1.4203.1.9.1.1
- Description: LDAP Content Synchronization Control
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at openldap.org>
- Usage: Control
- Specification: RFC 4533
- Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
- Comments: none
-
-8.3. LDAP Result Codes
-
- The IANA has registered the LDAP Result Code described in this
- document.
-
- Subject: LDAP Result Code Registration
- Person & email address to contact for further information:
- Kurt Zeilenga <kurt at OpenLDAP.org>
- Result Code Name: e-syncRefreshRequired (4096)
- Specification: RFC 4533
- Author/Change Controller: Kurt D. Zeilenga, Jong Hyuk Choi
- Comments: none
-
-9. Acknowledgements
-
- This document borrows significantly from the LDAP Client Update
- Protocol [RFC3928], a product of the IETF LDUP working group. This
- document also benefited from Persistent Search [PSEARCH], Triggered
- Search [TSEARCH], and Directory Synchronization [DIRSYNC] works.
- This document also borrows from "Lightweight Directory Access
- Protocol (v3)" [RFC2251].
-
-
-
-
-Zeilenga & Choi Experimental [Page 26]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-10. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC3296] Zeilenga, K., "Named Subordinate References in
- Lightweight Directory Access Protocol (LDAP)
- Directories", RFC 3296, July 2002.
-
- [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.
-
- [RFC3909] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) Cancel Operation", RFC 3909, October 2004.
-
- [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.
-
- [RFC4530] Zeilenga, K., "Lightweight Directory Access Protocol
- (LDAP) entryUUID Operational Attribute", RFC 4530, June
- 2006.
-
- [UUID] International Organization for Standardization (ISO),
- "Information technology - Open Systems Interconnection -
- Remote Procedure Call", ISO/IEC 11578:1996
-
- [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).
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 27]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- [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).
-
-11. Informative References
-
- [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [RFC3928] Megginson, R., Ed., Smith, M., Natkovich, O., and J.
- Parham, "Lightweight Directory Access Protocol (LDAP)
- Client Update Protocol (LCUP)", RFC 3928, October 2004.
-
- [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
-
- [PRIVATE] IANA, "Private Enterprise Numbers",
- http://www.iana.org/assignments/enterprise-numbers.
-
- [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
- http://www.openldap.org/foundation/oid-delegate.txt.
-
- [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.525] International Telecommunication Union - Telecommunication
- Standardization Sector, "The Directory: Replication",
- X.525(1993).
-
- [DIRSYNC] Armijo, M., "Microsoft LDAP Control for Directory
- Synchronization", Work in Progress.
-
- [PSEARCH] Smith, M., et al., "Persistent Search: A Simple LDAP
- Change Notification Mechanism", Work in Progress.
-
- [TSEARCH] Wahl, M., "LDAPv3 Triggered Search Control", Work in
- Progress.
-
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 28]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-Appendix A. CSN-based Implementation Considerations
-
- This appendix is provided for informational purposes only; it is not
- a normative part of the LDAP Content Synchronization Operation's
- technical specification.
-
- This appendix discusses LDAP Content Synchronization Operation server
- implementation considerations associated with Change Sequence Number
- based approaches.
-
- Change Sequence Number based approaches are targeted for use in
- servers that do not maintain history information (e.g., change logs,
- state snapshots) about changes made to the Directory and hence, must
- rely on current directory state and minimal synchronization state
- information embedded in Sync Cookie. Servers that maintain history
- information should consider other approaches that exploit the history
- information.
-
- A Change Sequence Number is effectively a time stamp that has
- sufficient granularity to ensure that the precedence relationship in
- time of two updates to the same object can be determined. Change
- Sequence Numbers are not to be confused with Commit Sequence Numbers
- or Commit Log Record Numbers. A Commit Sequence Number allows one to
- determine how two commits (to the same object or different objects)
- relate to each other in time. A Change Sequence Number associated
- with different entries may be committed out of order. In the
- remainder of this Appendix, the term CSN refers to a Change Sequence
- Number.
-
- In these approaches, the server not only maintains a CSN for each
- directory entry (the entry CSN) but also maintains a value that we
- will call the context CSN. The context CSN is the greatest committed
- entry CSN that is not greater than any outstanding (uncommitted)
- entry CSNs for all entries in a directory context. The values of
- context CSN are used in syncCookie values as synchronization state
- indicators.
-
- As search operations are not isolated from individual directory
- update operations and individual update operations cannot be assumed
- to be serialized, one cannot assume that the returned content
- incorporates each relevant change whose change sequence number is
- less than or equal to the greatest entry CSN in the content. The
- content incorporates all the relevant changes whose change sequence
- numbers are less than or equal to context CSN before search
- processing. The content may also incorporate any subset of the
- changes whose change sequence number is greater than context CSN
- before search processing but less than or equal to the context CSN
- after search processing. The content does not incorporate any of the
-
-
-
-Zeilenga & Choi Experimental [Page 29]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
- changes whose CSN is greater than the context CSN after search
- processing.
-
- A simple server implementation could use the value of the context CSN
- before search processing to indicate state. Such an implementation
- would embed this value into each SyncCookie returned. We'll call
- this the cookie CSN. When a refresh was requested, the server would
- simply generate "update" messages for all entries in the content
- whose CSN is greater than the supplied cookie CSN and generate
- "present" messages for all other entries in the content. However, if
- the current context CSN is the same as the cookie CSN, the server
- should instead generate zero "updates" and zero "delete" messages and
- indicate a refreshDeletes of TRUE, as the directory has not changed.
-
- The implementation should also consider the impact of changes to meta
- information, such as access controls, that affect content
- determination. One approach is for the server to maintain a
- context-wide meta information CSN or meta CSN. This meta CSN would
- be updated whenever meta information affecting content determination
- was changed. If the value of the meta CSN is greater than the cookie
- CSN, the server should ignore the cookie and treat the request as an
- initial request for content.
-
- Additionally, servers may want to consider maintaining some per-
- session history information to reduce the number of messages needed
- to be transferred during incremental refreshes. Specifically, a
- server could record information about entries as they leave the scope
- of a disconnected sync session and later use this information to
- generate delete messages instead of present messages.
-
- When the history information is truncated, the CSN of the latest
- truncated history information entry may be recorded as the truncated
- CSN of the history information. The truncated CSN may be used to
- determine whether a client copy can be covered by the history
- information by comparing it to the synchronization state contained in
- the cookie supplied by the client.
-
- When there is a large number of sessions, it may make sense to
- maintain such history only for the selected clients. Also, servers
- taking this approach need to consider resource consumption issues to
- ensure reasonable server operation and to protect against abuse. It
- may be appropriate to restrict this mode of operation by policy.
-
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 30]
-
-RFC 4533 LDAP Content Synchronization Operation June 2006
-
-
-Authors' Addresses
-
- Kurt D. Zeilenga
- OpenLDAP Foundation
-
- EMail: Kurt at OpenLDAP.org
-
-
- Jong Hyuk Choi
- IBM Corporation
-
- EMail: jongchoi at us.ibm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Zeilenga & Choi Experimental [Page 31]
-
-RFC 4533 LDAP Content Synchronization Operation 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 at www.rfc-editor.org/copyright.html, 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 & Choi Experimental [Page 32]
-
More information about the Pkg-samba-maint
mailing list