draft-ietf-ldapbis-syntaxes-09.txt   draft-ietf-ldapbis-syntaxes-10.txt 
INTERNET-DRAFT S. Legg, Editor INTERNET-DRAFT S. Legg, Editor
draft-ietf-ldapbis-syntaxes-09.txt eB2Bcom draft-ietf-ldapbis-syntaxes-10.txt eB2Bcom
Intended Category: Standards Track K. Dally Intended Category: Standards Track K. Dally
Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
Updates: RFC 3698 7 October 2004 Updates: RFC 3698 18 February 2005
Lightweight Directory Access Protocol (LDAP): Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules Syntaxes and Matching Rules
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo Status of this Memo
By submitting this Internet-draft, we certify that any applicable By submitting this Internet-draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed, patent or other IPR claims of which we are aware have been disclosed,
or will be disclosed, and any of which we become aware will be or will be disclosed, and any of which we become aware will be
disclosed, in accordance with RFC 3668. disclosed, in accordance with RFC 3668.
By submitting this Internet-draft, we accept the provisions of By submitting this Internet-draft, we accept the provisions of
Section 3 of RFC 3667. Section 3 of RFC 3667.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This document is intended to be, after appropriate review and This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document. revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of Distribution of this document is unlimited. Technical discussion of
this document should take place on the IETF LDAP Revision Working this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor send editorial comments directly to the editor
<steven.legg@eb2bcom.com>. <steven.legg@eb2bcom.com>.
This Internet-Draft expires on 7 April 2005. This Internet-Draft expires on 18 August 2005.
Abstract Abstract
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory, and whose values may be transfered in the LDAP (LDAP) directory, and whose values may be transfered in the LDAP
protocol, has a defined syntax which constrains the structure and protocol, has a defined syntax which constrains the structure and
format of its values. The comparison semantics for values of a format of its values. The comparison semantics for values of a
syntax are not part of the syntax definition but are instead provided syntax are not part of the syntax definition but are instead provided
through separately defined matching rules. Matching rules specify an through separately defined matching rules. Matching rules specify an
argument, an assertion value, which also has a defined syntax. This argument, an assertion value, which also has a defined syntax. This
skipping to change at page 3, line 27 skipping to change at page 3, line 27
3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
3.3.6. Directory String . . . . . . . . . . . . . . . . 9 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
3.3.7. DIT Content Rule Description . . . . . . . . . . 10 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
3.3.8. DIT Structure Rule Description . . . . . . . . . 11 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
3.3.19. Matching Rule Description. . . . . . . . . . . . 17 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
3.3.20. Matching Rule Use Description. . . . . . . . . . 17 3.3.20. Matching Rule Use Description. . . . . . . . . . 18
3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
3.3.22. Name Form Description. . . . . . . . . . . . . . 18 3.3.22. Name Form Description. . . . . . . . . . . . . . 19
3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
3.3.24. Object Class Description . . . . . . . . . . . . 19 3.3.24. Object Class Description . . . . . . . . . . . . 19
3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
3.3.29. Printable String . . . . . . . . . . . . . . . . 22 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. General Considerations . . . . . . . . . . . . . . . . . 26 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 28 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 28 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 29 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 29
4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 29 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 30 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 30
4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 31 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 32 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 33 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
4.2.14. directoryStringFirstComponentMatch . . . . . . . 34 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 35 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 35
4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 36 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 36
4.2.18. integerFirstComponentMatch . . . . . . . . . . . 36 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 37 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 37
4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 37 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
4.2.22. numericStringMatch . . . . . . . . . . . . . . . 38 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 38
4.2.23. numericStringOrderingMatch . . . . . . . . . . . 38 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
4.2.24. numericStringSubstringsMatch . . . . . . . . . . 39 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 40 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 41 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 42 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 43 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 43
4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 43 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 44 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 46 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 46
Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 47 Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 47
Normative References . . . . . . . . . . . . . . . . . . . . . . . 49 Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
Informative References . . . . . . . . . . . . . . . . . . . . . . 51 Informative References . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 52 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction 1. Introduction
Each attribute stored in a Lightweight Directory Access Protocol Each attribute stored in a Lightweight Directory Access Protocol
(LDAP) directory [ROADMAP], and whose values may be transfered in the (LDAP) directory [ROADMAP], and whose values may be transfered in the
LDAP protocol [PROT], has a defined syntax (i.e., data type) which LDAP protocol [PROT], has a defined syntax (i.e., data type) which
constrains the structure and format of its values. The comparison constrains the structure and format of its values. The comparison
semantics for values of a syntax are not part of the syntax semantics for values of a syntax are not part of the syntax
definition but are instead provided through separately defined definition but are instead provided through separately defined
matching rules. Matching rules specify an argument, an assertion matching rules. Matching rules specify an argument, an assertion
skipping to change at page 5, line 30 skipping to change at page 5, line 30
and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document. Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
A number of schema elements which were included in the previous A number of schema elements which were included in the previous
revision of the LDAP technical specification are not included in this revision of the LDAP technical specification are not included in this
revision of LDAP. Public Key Infrastructure schema elements are now revision of LDAP. Public Key Infrastructure schema elements are now
specified in [LDAP-PKI]. Unless reintroduced in future technical specified in [LDAP-PKI]. Unless reintroduced in future technical
specifications, the remainder are to be considered Historic. specifications, the remainder are to be considered Historic.
The changes from RFC 2252 and RFC 2256 are described in Appendix B of The changes with respect to RFC 2252 are described in Appendix B of
this document. this document.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[KEYWORD]. [KEYWORD].
Syntax definitions are written according to the <SyntaxDescription> Syntax definitions are written according to the <SyntaxDescription>
skipping to change at page 7, line 19 skipping to change at page 7, line 19
3.2. Common Definitions 3.2. Common Definitions
The following ABNF rules are used in a number of the syntax The following ABNF rules are used in a number of the syntax
definitions in Section 3.3. definitions in Section 3.3.
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS / PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F) IA5String = *(%x00-7F)
HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; N.B. allows upper and lower case
SLASH = %x2F ; forward slash ("/") SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":") COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?") QUESTION = %x3F ; question mark ("?")
The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
<COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
[MODELS].
3.3. Syntax Definitions 3.3. Syntax Definitions
3.3.1. Attribute Type Description 3.3.1. Attribute Type Description
A value of the Attribute Type Description syntax is the definition of A value of the Attribute Type Description syntax is the definition of
an attribute type. The LDAP-specific encoding of a value of this an attribute type. The LDAP-specific encoding of a value of this
syntax is defined by the <AttributeTypeDescription> rule in [MODELS]. syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
For example, the following definition of the createTimestamp For example, the following definition of the createTimestamp
attribute type from [MODELS] is also a value of the Attribute Type attribute type from [MODELS] is also a value of the Attribute Type
Description syntax (note: line breaks have been added for readability Description syntax (note: line breaks have been added for
- they are not part of the value when transfered in protocol). readability - they are not part of the value when transfered in
protocol).
( 2.5.18.1 NAME 'createTimestamp' ( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation ) USAGE directoryOperation )
The LDAP definition for the Attribute Type Description syntax is: The LDAP definition for the Attribute Type Description syntax is:
skipping to change at page 10, line 42 skipping to change at page 10, line 42
The DirectoryString ASN.1 type allows a choice between the The DirectoryString ASN.1 type allows a choice between the
TeletexString, PrintableString or UniversalString ASN.1 types from TeletexString, PrintableString or UniversalString ASN.1 types from
[ASN.1]. However, note that the chosen alternative is not indicated [ASN.1]. However, note that the chosen alternative is not indicated
in the LDAP-specific encoding of a Directory String value. in the LDAP-specific encoding of a Directory String value.
Implementations which convert Directory String values from the Implementations which convert Directory String values from the
LDAP-specific encoding to the BER encoding used by X.500 must choose LDAP-specific encoding to the BER encoding used by X.500 must choose
an alternative that permits the particular characters in the string, an alternative that permits the particular characters in the string,
and must convert the characters from the UTF-8 encoding into the and must convert the characters from the UTF-8 encoding into the
character encoding of the chosen alternative. character encoding of the chosen alternative. When converting
Directory String values from the BER encoding to the LDAP-specific
When converting Directory String values from the BER encoding to the encoding the characters must be converted from the character encoding
LDAP-specific encoding the characters must be converted from the of the chosen alternative into the UTF-8 encoding. These conversions
character encoding of the chosen alternative into the UTF-8 encoding. SHOULD be done in a manner consistent with the Transcode step of the
string preparation algorithms [PREP] for LDAP.
3.3.7. DIT Content Rule Description 3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition A value of the DIT Content Rule Description syntax is the definition
of a DIT (Directory Information Tree) content rule. The of a DIT (Directory Information Tree) content rule. The
LDAP-specific encoding of a value of this syntax is defined by the LDAP-specific encoding of a value of this syntax is defined by the
<DITContentRuleDescription> rule in [MODELS]. <DITContentRuleDescription> rule in [MODELS].
Example: Example:
( 2.5.6.4 DESC 'content rule for organization' ( 2.5.6.4 DESC 'content rule for organization'
NOT ( x121Address $ telexNumber ) ) NOT ( x121Address $ telexNumber ) )
Note: a line break has been added for readability - it is not part of Note: a line break has been added for readability - it is not part
the value. of the value.
The LDAP definition for the DIT Content Rule Description syntax is: The LDAP definition for the DIT Content Rule Description syntax is:
( 1.3.6.1.4.1.1466.115.121.1.16 ( 1.3.6.1.4.1.1466.115.121.1.16
DESC 'DIT Content Rule Description' ) DESC 'DIT Content Rule Description' )
This syntax corresponds to the DITContentRuleDescription ASN.1 type This syntax corresponds to the DITContentRuleDescription ASN.1 type
from [X.501]. from [X.501].
3.3.8. DIT Structure Rule Description 3.3.8. DIT Structure Rule Description
skipping to change at page 14, line 27 skipping to change at page 14, line 27
The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
3.3.13. Generalized Time 3.3.13. Generalized Time
A value of the Generalized Time syntax is a character string A value of the Generalized Time syntax is a character string
representing a date and time. The LDAP-specific encoding of a value representing a date and time. The LDAP-specific encoding of a value
of this syntax is a restriction of the format defined in [ISO8601], of this syntax is a restriction of the format defined in [ISO8601],
and is described by the following ABNF: 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" century = 2(%x30-39) ; "00" to "99"
year = 2(%x30-39) ; "00" to "99" year = 2(%x30-39) ; "00" to "99"
month = ( %x30 %x31-39 ) ; "01" (January) to "09" month = ( %x30 %x31-39 ) ; "01" (January) to "09"
/ ( %x31 %x30-32 ) ; "10" to "12" / ( %x31 %x30-32 ) ; "10" to "12"
day = ( %x30 %x31-39 ) ; "01" to "09" day = ( %x30 %x31-39 ) ; "01" to "09"
/ ( %x31-32 %x30-39 ) ; "10" to "29" / ( %x31-32 %x30-39 ) ; "10" to "29"
/ ( %x33 %x30-31 ) ; "30" to "31" / ( %x33 %x30-31 ) ; "30" to "31"
hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
minute = %x30-35 %x30-39 ; "00" to "59" minute = %x30-35 %x30-39 ; "00" to "59"
second = ( %x30-35 %x30-39 ) ; "00" to "59" second = ( %x30-35 %x30-39 ) ; "00" to "59"
/ ( %x36 %x30 ) ; "60" (a leap second) leap-second = ( %x36 %x30 ) ; "60"
GeneralizedTime = century year month day hour
[ minute [ second ] ] [ fraction ]
g-time-zone
fraction = ( DOT / COMMA ) 1*(%x30-39) fraction = ( DOT / COMMA ) 1*(%x30-39)
g-time-zone = %x5A ; "Z" g-time-zone = %x5A ; "Z"
/ g-differential / g-differential
g-differential = ( MINUS / PLUS ) hour [ minute ] g-differential = ( MINUS / PLUS ) hour [ minute ]
MINUS = %x2D ; minus sign ("-") MINUS = %x2D ; minus sign ("-")
The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS]. The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
The above ABNF allows character strings which 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 The time value represents coordinated universal time (equivalent to
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used, Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
otherwise the value represents a local time in the time zone otherwise the value represents a local time in the time zone
indicated by <g-differential>. In the latter case, coordinated indicated by <g-differential>. In the latter case, coordinated
universal time can be calculated by subtracting the differential from universal time can be calculated by subtracting the differential from
the local time. The "Z" form of <g-time-zone> SHOULD be used in the local time. The "Z" form of <g-time-zone> SHOULD be used in
preference to <g-differential>. preference to <g-differential>.
Examples: Examples:
199412161032Z 199412161032Z
skipping to change at page 21, line 49 skipping to change at page 22, line 5
line-char = %x00-23 line-char = %x00-23
/ (%x5C "24") ; escaped "$" / (%x5C "24") ; escaped "$"
/ %x25-5B / %x25-5B
/ (%x5C "5C") ; escaped "\" / (%x5C "5C") ; escaped "\"
/ %x5D-7F / %x5D-7F
/ UTFMB / UTFMB
Each character string (i.e., <line>) of a postal address value is Each character string (i.e., <line>) of a postal address value is
encoded as a UTF-8 [UTF8] string except that "\" and "$" characters, encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
if they occur in the string, are escaped by a "\" character followed if they occur in the string, are escaped by a "\" character followed
by the two hexadecimal digit code for the character. The <HEX-DIGIT> by the two hexadecimal digit code for the character. The <DOLLAR>
rule is defined in Section 3.2. The <DOLLAR> and <UTFMB> rules are and <UTFMB> rules are defined in [MODELS].
defined in [MODELS].
Many servers limit the postal address to no more than six lines of no Many servers limit the postal address to no more than six lines of no
more than thirty characters each. more than thirty characters each.
Example: Example:
1234 Main St.$Anytown, CA 12345$USA 1234 Main St.$Anytown, CA 12345$USA
\241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
The LDAP definition for the Postal Address syntax is: The LDAP definition for the Postal Address syntax is:
skipping to change at page 23, line 49 skipping to change at page 24, line 5
3.3.31. Telephone Number 3.3.31. Telephone Number
A value of the Telephone Number syntax is a string of printable A value of the Telephone Number syntax is a string of printable
characters that complies with the internationally agreed format for characters that complies with the internationally agreed format for
representing international telephone numbers [E.123]. representing international telephone numbers [E.123].
The LDAP-specific encoding of a value of this syntax is the The LDAP-specific encoding of a value of this syntax is the
unconverted string of characters, which conforms to the unconverted string of characters, which conforms to the
<PrintableString> rule in Section 3.2. <PrintableString> rule in Section 3.2.
Example: +1 512 315 0280 Examples:
+1 512 315 0280
+1-512-315-0280
+61 3 9896 7830
The LDAP definition for the Telephone Number syntax is: The LDAP definition for the Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ( 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 The Telephone Number syntax corresponds to the following ASN.1 type
from [X.520]: from [X.520]:
PrintableString (SIZE(1..ub-telephone-number)) PrintableString (SIZE(1..ub-telephone-number))
skipping to change at page 24, line 27 skipping to change at page 24, line 34
A value of this syntax specifies the identifier and (optionally) A value of this syntax specifies the identifier and (optionally)
parameters of a teletex terminal. parameters of a teletex terminal.
The LDAP-specific encoding of a value of this syntax is defined by The LDAP-specific encoding of a value of this syntax is defined by
the following ABNF: the following ABNF:
teletex-id = ttx-term *(DOLLAR ttx-param) teletex-id = ttx-term *(DOLLAR ttx-param)
ttx-term = PrintableString ; terminal identifier ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private" ttx-key = "graphic" / "control" / "misc" / "page" / "private"
ttx-value = *ttx-value-char ttx-value = *ttx-value-octet
ttx-value-char = %x00-23 ttx-value-octet = %x00-23
/ (%x5C "24") ; escaped "$" / (%x5C "24") ; escaped "$"
/ %x25-5B / %x25-5B
/ (%x5C "5C") ; escaped "\" / (%x5C "5C") ; escaped "\"
/ %x5D-FF / %x5D-FF
The <PrintableString> and <COLON> rules are defined in Section 3.2. The <PrintableString> and <COLON> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS]. The <DOLLAR> rule is defined in [MODELS].
The LDAP definition for the Teletex Terminal Identifier syntax is: The LDAP definition for the Teletex Terminal Identifier syntax is:
skipping to change at page 25, line 38 skipping to change at page 25, line 46
UTCTime = year month day hour minute [ second ] UTCTime = year month day hour minute [ second ]
[ u-time-zone ] [ u-time-zone ]
u-time-zone = %x5A ; "Z" u-time-zone = %x5A ; "Z"
/ u-differential / u-differential
u-differential = ( MINUS / PLUS ) hour minute u-differential = ( MINUS / PLUS ) hour minute
The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS> The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
rules are defined in Section 3.3.13. The <PLUS> rule is defined in rules are defined in Section 3.3.13. The <PLUS> rule is defined in
[MODELS]. [MODELS].
The above ABNF allows character strings which 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 The time value represents coordinated universal time if the "Z" form
of <u-time-zone> is used, otherwise the value represents a local of <u-time-zone> is used, otherwise the value represents a local
time. In the latter case, if <u-differential> is provided then time. In the latter case, if <u-differential> is provided then
coordinated universal time can be calculated by subtracting the coordinated universal time can be calculated by subtracting the
differential from the local time. The <u-time-zone> SHOULD be 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 present in time values and the "Z" form of <u-time-zone> SHOULD be
used in preference to <u-differential>. used in preference to <u-differential>.
The LDAP definition for the UTC Time syntax is: The LDAP definition for the UTC Time syntax is:
skipping to change at page 26, line 37 skipping to change at page 26, line 48
[PROT]. If an assertion is not Undefined then the result of the [PROT]. If an assertion is not Undefined then the result of the
assertion is the result of applying the selected matching rule. A assertion is the result of applying the selected matching rule. A
matching rule evaluates to TRUE, and in some cases Undefined, as matching rule evaluates to TRUE, and in some cases Undefined, as
specified in the description of the matching rule, otherwise it specified in the description of the matching rule, otherwise it
evaluates to FALSE. evaluates to FALSE.
Each assertion contains an assertion value. The definition of each Each assertion contains an assertion value. The definition of each
matching rule specifies the syntax for the assertion value. The matching rule specifies the syntax for the assertion value. The
syntax of the assertion value is typically, but not necessarily, 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 same as the syntax of the attribute values to which the matching rule
may be applied. Note that the AssertionValue in a SubstringFilter may be applied. Note that an AssertionValue in a SubstringFilter
[PROT] MUST conform to the assertion syntax of the equality matching [PROT] conforms to the assertion syntax of the equality matching rule
rule for the attribute type rather than the assertion syntax of the for the attribute type rather than the assertion syntax of the
substrings matching rule for the attribute type. The entire substrings matching rule for the attribute type. Conceptually, the
SubstringFilter is converted into an assertion value of the entire SubstringFilter is converted into an assertion value of the
substrings matching rule prior to applying the rule. substrings matching rule prior to applying the rule.
The definition of each matching rule indicates the attribute syntaxes The definition of each matching rule indicates the attribute syntaxes
to which the rule may be applied, by specifying conditions the to which the rule may be applied, by specifying conditions the
corresponding ASN.1 type of a candidate attribute syntax must corresponding ASN.1 type of a candidate attribute syntax must
satisfy. These conditions are also satisfied if the corresponding satisfy. These conditions are also satisfied if the corresponding
ASN.1 type is a tagged or constrained derivative of the ASN.1 type 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 explicitly mentioned in the rule description (i.e., ASN.1 tags and
constraints are ignored in checking applicability), or an alternative constraints are ignored in checking applicability), or an alternative
reference notation for the explicitly mentioned type. Each rule reference notation for the explicitly mentioned type. Each rule
skipping to change at page 27, line 43 skipping to change at page 28, line 7
unreferenced matching rules MAY be published in the matchingRules unreferenced matching rules MAY be published in the matchingRules
attribute. attribute.
If the server supports the extensibleMatch filter, then the server If the server supports the extensibleMatch filter, then the server
MAY use the matchingRuleUse attribute to indicate the applicability MAY use the matchingRuleUse attribute to indicate the applicability
(in an extensibleMatch filter) of selected matching rules to (in an extensibleMatch filter) of selected matching rules to
nominated attribute types. nominated attribute types.
4.2. Matching Rule Definitions 4.2. Matching Rule Definitions
When evaluating the numericStringMatch, numericStringSubstringsMatch, Nominated character strings in assertion and attribute values are
caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, prepared according to the string preparation algorithms [PREP] for
caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, LDAP when evaluating the following matching rules:
caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, numericStringMatch,
directoryStringFirstComponentMatch, telephoneNumberMatch and numericStringSubstringsMatch,
telephoneNumberSubstringsMatch matching rules the assertion value and caseExactMatch,
attribute value are prepared according to the string preparation caseExactOrderingMatch,
algorithms [PREP] for LDAP before being compared. The Transcode, caseExactSubstringsMatch,
Normalize, Prohibit and Check bidi steps are the same for each of the caseExactIA5Match,
matching rules. However, the Map and Insignificant Character Removal caseIgnoreIA5Match,
steps depends on the specific rule, as detailed in the description of caseIgnoreIA5SubstringsMatch,
these matching rules in the sections that follow. 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 depends on the specific rule, as detailed in
the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch 4.2.1. bitStringMatch
The bitStringMatch rule compares an assertion value of the Bit String 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 to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING. syntax) whose corresponding ASN.1 type is BIT STRING.
If the corresponding ASN.1 type of the attribute syntax does not have If the corresponding ASN.1 type of the attribute syntax does not have
a named bit list (which is the case for the Bit String syntax) then a named bit list [ASN.1] (which is the case for the Bit String
the rule evaluates to TRUE if and only if the attribute value has the syntax) then the rule evaluates to TRUE if and only if the attribute
same number of bits as the assertion value and the bits match on a value has the same number of bits as the assertion value and the bits
bitwise basis. match on a bitwise basis.
If the corresponding ASN.1 type does have a named bit list then If the corresponding ASN.1 type does have a named bit list then
bitStringMatch operates as above except that trailing zero bits in bitStringMatch operates as above except that trailing zero bits in
the attribute and assertion values are treated as absent. the attribute and assertion values are treated as absent.
The LDAP definition for the bitStringMatch rule is: The LDAP definition for the bitStringMatch rule is:
( 2.5.13.16 NAME 'bitStringMatch' ( 2.5.13.16 NAME 'bitStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
skipping to change at page 29, line 13 skipping to change at page 29, line 37
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseExactIA5Match rule is: The LDAP definition for the caseExactIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseExactIA5Match rule is an equality matching rule. The caseExactIA5Match rule is an equality matching rule.
4.2.4. caseExactMatch 4.2.4. caseExactMatch
skipping to change at page 29, line 40 skipping to change at page 30, line 16
(the other alternatives do not correspond to any syntax defined in (the other alternatives do not correspond to any syntax defined in
this document). this document).
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseExactMatch rule is: The LDAP definition for the caseExactMatch rule is:
( 2.5.13.5 NAME 'caseExactMatch' ( 2.5.13.5 NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactMatch rule is an equality matching rule. The caseExactMatch rule is an equality matching rule.
4.2.5. caseExactOrderingMatch 4.2.5. caseExactOrderingMatch
The caseExactOrderingMatch rule compares an assertion value of the The caseExactOrderingMatch rule compares an assertion value of the
Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax to an attribute value of a syntax (e.g., the
Directory String, Printable String, Country String or Telephone Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string,
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
skipping to change at page 30, line 17 skipping to change at page 30, line 41
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string,
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseExactOrderingMatch rule is: The LDAP definition for the caseExactOrderingMatch rule is:
( 2.5.13.6 NAME 'caseExactOrderingMatch' ( 2.5.13.6 NAME 'caseExactOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseExactOrderingMatch rule is an ordering matching rule. The caseExactOrderingMatch rule is an ordering matching rule.
4.2.6. caseExactSubstringsMatch 4.2.6. caseExactSubstringsMatch
The caseExactSubstringsMatch rule compares an assertion value of the The caseExactSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g., Substring Assertion syntax to an attribute value of a syntax (e.g.,
the Directory String, Printable String, Country String or Telephone the Directory String, Printable String, Country String or Telephone
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
skipping to change at page 30, line 47 skipping to change at page 31, line 22
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are not case folded in the Map preparation comparison, characters are not case folded in the Map preparation
step, and only Insignificant Space Removal is applied in the step, and only Insignificant Space Handling is applied in the
Insignificant Character Removal step. Insignificant Character Handling step.
The LDAP definition for the caseExactSubstringsMatch rule is: The LDAP definition for the caseExactSubstringsMatch rule is:
( 2.5.13.7 NAME 'caseExactSubstringsMatch' ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseExactSubstringsMatch rule is a substrings matching rule. The caseExactSubstringsMatch rule is a substrings matching rule.
4.2.7. caseIgnoreIA5Match 4.2.7. caseIgnoreIA5Match
skipping to change at page 31, line 23 skipping to change at page 31, line 45
String syntax to an attribute value of a syntax (e.g the IA5 String String syntax to an attribute value of a syntax (e.g the IA5 String
syntax) whose corresponding ASN.1 type is IA5String. syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseIgnoreIA5Match rule is: The LDAP definition for the caseIgnoreIA5Match rule is:
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
The caseIgnoreIA5Match rule is an equality matching rule. The caseIgnoreIA5Match rule is an equality matching rule.
4.2.8. caseIgnoreIA5SubstringsMatch 4.2.8. caseIgnoreIA5SubstringsMatch
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax (e.g 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 IA5 String syntax) whose corresponding ASN.1 type is IA5String.
The rule evaluates to TRUE if and only if the prepared substrings of The rule evaluates to TRUE if and only if the prepared substrings of
the assertion value match disjoint portions of the prepared attribute the assertion value match disjoint portions of the prepared attribute
skipping to change at page 31, line 51 skipping to change at page 32, line 24
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Removal is applied in the Insignificant and only Insignificant Space Handling is applied in the Insignificant
Character Removal step. Character Handling step.
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
4.2.9. caseIgnoreListMatch 4.2.9. caseIgnoreListMatch
The caseIgnoreListMatch rule compares an assertion value that is a The caseIgnoreListMatch rule compares an assertion value that is a
sequence of strings to an attribute value of a syntax (e.g., the sequence of strings to an attribute value of a syntax (e.g., the
skipping to change at page 33, line 32 skipping to change at page 34, line 7
whose corresponding ASN.1 type is DirectoryString or one of its whose corresponding ASN.1 type is DirectoryString or one of its
alternative string types. alternative string types.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseIgnoreMatch rule is: The LDAP definition for the caseIgnoreMatch rule is:
( 2.5.13.2 NAME 'caseIgnoreMatch' ( 2.5.13.2 NAME 'caseIgnoreMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreMatch rule is an equality matching rule. The caseIgnoreMatch rule is an equality matching rule.
4.2.12. caseIgnoreOrderingMatch 4.2.12. caseIgnoreOrderingMatch
skipping to change at page 34, line 9 skipping to change at page 34, line 32
Number syntax) whose corresponding ASN.1 type is DirectoryString or Number syntax) whose corresponding ASN.1 type is DirectoryString or
one of its alternative string types. one of its alternative string types.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion value character string, appears earlier than the prepared assertion value character string,
i.e., the attribute value is "less than" the assertion value. i.e., the attribute value is "less than" the assertion value.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
Insignificant Space Removal is applied in the Insignificant Character Insignificant Space Handling is applied in the Insignificant
Removal step. Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is: The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The caseIgnoreOrderingMatch rule is an ordering matching rule. The caseIgnoreOrderingMatch rule is an ordering matching rule.
4.2.13. caseIgnoreSubstringsMatch 4.2.13. caseIgnoreSubstringsMatch
skipping to change at page 34, line 39 skipping to change at page 35, line 13
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only Insignificant Space Removal is applied in the Insignificant and only Insignificant Space Handling is applied in the Insignificant
Character Removal step. Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is: The LDAP definition for the caseIgnoreSubstringsMatch rule is:
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The caseIgnoreSubstringsMatch rule is a substrings matching rule. The caseIgnoreSubstringsMatch rule is a substrings matching rule.
4.2.14. directoryStringFirstComponentMatch 4.2.14. directoryStringFirstComponentMatch
skipping to change at page 38, line 42 skipping to change at page 39, line 14
Numeric String syntax) whose corresponding ASN.1 type is Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Removal is applied in the numericString Insignificant Character Handling is applied in the
Insignificant Character Removal step. Insignificant Character Handling step.
The LDAP definition for the numericStringMatch matching rule is: The LDAP definition for the numericStringMatch matching rule is:
( 2.5.13.8 NAME 'numericStringMatch' ( 2.5.13.8 NAME 'numericStringMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
The numericStringMatch rule is an equality matching rule. The numericStringMatch rule is an equality matching rule.
4.2.23. numericStringOrderingMatch 4.2.23. numericStringOrderingMatch
The numericStringOrderingMatch rule compares an assertion value of The numericStringOrderingMatch rule compares an assertion value of
the Numeric String syntax to an attribute value of a syntax (e.g the the Numeric String syntax to an attribute value of a syntax (e.g the
Numeric String syntax) whose corresponding ASN.1 type is Numeric String syntax) whose corresponding ASN.1 type is
NumericString. NumericString.
The rule evaluates to TRUE if, and only if, in the code point The rule evaluates to TRUE if, and only if, in the code point
collation order, the prepared attribute value character string collation order, the prepared attribute value character string
appears earlier than the prepared assertion 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, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Removal is applied in the numericString Insignificant Character Handling is applied in the
Insignificant Character Removal step. Insignificant Character Handling step.
The rule is identical to the caseIgnoreOrderingMatch rule except that The rule is identical to the caseIgnoreOrderingMatch rule except that
all space characters are skipped during comparison (case is all space characters are skipped during comparison (case is
irrelevant as characters are numeric). irrelevant as characters are numeric).
The LDAP definition for the numericStringOrderingMatch matching rule The LDAP definition for the numericStringOrderingMatch matching rule
is: is:
( 2.5.13.9 NAME 'numericStringOrderingMatch' ( 2.5.13.9 NAME 'numericStringOrderingMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
skipping to change at page 39, line 49 skipping to change at page 40, line 24
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only characters are not case folded in the Map preparation step, and only
numericString Insignificant Character Removal is applied in the numericString Insignificant Character Handling is applied in the
Insignificant Character Removal step. Insignificant Character Handling step.
The LDAP definition for the numericStringSubstringsMatch matching The LDAP definition for the numericStringSubstringsMatch matching
rule is: rule is:
( 2.5.13.10 NAME 'numericStringSubstringsMatch' ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The numericStringSubstringsMatch rule is a substrings matching rule. The numericStringSubstringsMatch rule is a substrings matching rule.
4.2.25. objectIdentifierFirstComponentMatch 4.2.25. objectIdentifierFirstComponentMatch
skipping to change at page 42, line 27 skipping to change at page 42, line 49
Telephone Number syntax) whose corresponding ASN.1 type is a Telephone Number syntax) whose corresponding ASN.1 type is a
PrintableString representing a telephone number. PrintableString representing a telephone number.
The rule evaluates to TRUE if and only if the prepared attribute The rule evaluates to TRUE if and only if the prepared attribute
value character string and the prepared assertion value character value character string and the prepared assertion value character
string have the same number of characters and corresponding string have the same number of characters and corresponding
characters have the same code point. characters have the same code point.
In preparing the attribute value and assertion value for comparison, In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only characters are case folded in the Map preparation step, and only
telephoneNumber Insignificant Character Removal is applied in the telephoneNumber Insignificant Character Handling is applied in the
Insignificant Character Removal step. Insignificant Character Handling step.
The LDAP definition for the telephoneNumberMatch matching rule is: The LDAP definition for the telephoneNumberMatch matching rule is:
( 2.5.13.20 NAME 'telephoneNumberMatch' ( 2.5.13.20 NAME 'telephoneNumberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
The telephoneNumberMatch rule is an equality matching rule. The telephoneNumberMatch rule is an equality matching rule.
4.2.30. telephoneNumberSubstringsMatch 4.2.30. telephoneNumberSubstringsMatch
skipping to change at page 43, line 7 skipping to change at page 43, line 29
value character string in the order of the substrings in the value character string in the order of the substrings in the
assertion value, and an <initial> substring, if present, matches the assertion value, and an <initial> substring, if present, matches the
beginning of the prepared attribute value character string, and a beginning of the prepared attribute value character string, and a
<final> substring, if present, matches the end of the prepared <final> substring, if present, matches the end of the prepared
attribute value character string. A prepared substring matches a attribute value character string. A prepared substring matches a
portion of the prepared attribute value character string if portion of the prepared attribute value character string if
corresponding characters have the same code point. corresponding characters have the same code point.
In preparing the attribute value and assertion value substrings for In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step, comparison, characters are case folded in the Map preparation step,
and only telephoneNumber Insignificant Character Removal is applied and only telephoneNumber Insignificant Character Handling is applied
in the Insignificant Character Removal step. in the Insignificant Character Handling step.
The LDAP definition for the telephoneNumberSubstringsMatch matching The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is: rule is:
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
The telephoneNumberSubstringsMatch rule is a substrings matching The telephoneNumberSubstringsMatch rule is a substrings matching
rule. rule.
4.2.31. uniqueMemberMatch 4.2.31. uniqueMemberMatch
The uniqueMemberMatch rule compares an assertion value of the Name The uniqueMemberMatch rule compares an assertion value of the Name
And Optional UID syntax to an attribute value of a syntax (e.g the 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 Name And Optional UID syntax) whose corresponding ASN.1 type is
NameAndOptionalUID. NameAndOptionalUID.
The rule evaluates to TRUE if and only if the <distinguishedName> The rule evaluates to TRUE if and only if the <distinguishedName>
components of the assertion value and attribute value match according components of the assertion value and attribute value match according
to the distinguishedNameMatch rule and the <BitString> component is to the distinguishedNameMatch rule and either, the <BitString>
absent from the attribute value or matches the <BitString> component component is absent from both the attribute value and assertion
of the assertion value according to the bitStringMatch rule. value, or 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: The LDAP definition for the uniqueMemberMatch matching rule is:
( 2.5.13.23 NAME 'uniqueMemberMatch' ( 2.5.13.23 NAME 'uniqueMemberMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
The uniqueMemberMatch rule is an equality matching rule. The uniqueMemberMatch rule is an equality matching rule.
4.2.32. wordMatch 4.2.32. wordMatch
skipping to change at page 47, line 10 skipping to change at page 47, line 42
OID 1.3.6.1.4.1.1466.115.121.1.38 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 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 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 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 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 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 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 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 UTC Time 1.3.6.1.4.1.1466.115.121.1.53
Appendix B. Changes from RFC 2252 & RFC 2256 Appendix B. Changes from RFC 2252
This annex lists the significant differences between this This annex lists the significant differences between this
specification and RFC 2252 and Sections 6 and 8 of RFC 2256. specification and RFC 2252.
This annex is provided for informational purposes only. It is not a This annex is provided for informational purposes only. It is not a
normative part of this specification. normative part of this specification.
1. The IESG Note has been removed. 1. The IESG Note has been removed.
2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
and revised. Changes to the parts of these sections moved to and revised. Changes to the parts of these sections moved to
[MODELS] are detailed in [MODELS]. [MODELS] are detailed in [MODELS].
skipping to change at page 48, line 31 skipping to change at page 49, line 13
Terminal Identifier and Telex Number syntaxes from RFC 2256 have Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated. been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions. been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal 16. An encoding for the <ttx-value> rule in the Teletex Terminal
Identifier syntax has been defined. Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and 17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair from RFC 2252, and Supported Algorithm syntax Certificate Pair) have been removed. They are reintroduced in
from RFC 2256) have been removed. They are to be reintroduced in [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
PKIX documents.
18. The MHS OR Address syntax has been removed since its 18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity. specification (in RFC 2156) is not at draft standard maturity.
19. The DL Submit Permission syntax has been removed as it depends on 19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax. the MHS OR Address syntax.
20. The Presentation Address syntax has been removed since its 20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity. specification (in RFC 1278) is not at draft standard maturity.
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
Type, LDAP Schema Description, Master And Shadow Access Points, Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification, Modify Rights, Protocol Information, Subtree Specification,
Supplier Information, Supplier Or Consumer and Supplier And Supplier Information, Supplier Or Consumer and Supplier And
Consumer syntaxes have been removed. These syntaxes are Consumer syntaxes have been removed. These syntaxes are
referenced in RFC 2252, but not defined. referenced in RFC 2252, but not defined.
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
Mail Preference syntax have been removed on the grounds that they Mail Preference syntax have been removed on the grounds that they
are out of scope for a core specification. are out of scope for the core specification.
23. The description of each of the matching rules has been expanded 23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for so that they are less dependent on knowledge of X.500 for
interpretation. interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added. been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the caseIgnoreSubstringsMatch matching rules have been added to the
skipping to change at page 49, line 36 skipping to change at page 50, line 19
depends on an assertion syntax (Presentation Address) that is not depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity. at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it 28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information). depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to 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. X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching 30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added to this document. rule from RFC 2798 & X.520 has been added.
31. String preparation algorithms have been applied to the character 31. String preparation algorithms have been applied to the character
string matching rules. string matching rules.
32. The specifications of the booleanMatch, caseExactMatch, 32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch, caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch, directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch, keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added to this document. RFC 3698 & X.520 have been added.
Normative References Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629, November 2003. 10646", RFC 3629, November 2003.
[BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access Considerations for the Lightweight Directory Access
Protocol (LDAP)", BCP 64, RFC 3383, September 2002. Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[LDAPDN] Zeilenga, K., "LDAP: String Representation of [LDAPDN] Zeilenga, K., "LDAP: String Representation of
Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
in progress, February 2004. in progress, February 2005.
[PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
protocol-xx.txt, a work in progress, May 2004. protocol-xx.txt, a work in progress, February 2005.
[E.123] Notation for national and international telephone numbers, [E.123] Notation for national and international telephone numbers,
ITU-T Recommendation E.123, 1988. ITU-T Recommendation E.123, 1988.
[FAX] Standardization of Group 3 facsimile apparatus for [FAX] Standardization of Group 3 facsimile apparatus for
document transmission - Terminal Equipment and Protocols document transmission - Terminal Equipment and Protocols
for Telematic Services, ITU-T Recommendation T.4, 1993 for Telematic Services, ITU-T Recommendation T.4, 1993
[T.50] International Reference Alphabet (IRA) (Formerly [T.50] International Reference Alphabet (IRA) (Formerly
International Alphabet No. 5 or IA5) Information International Alphabet No. 5 or IA5) Information
skipping to change at page 51, line 15 skipping to change at page 51, line 46
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
Architecture and Basic Multilingual Plane, ISO/IEC Architecture and Basic Multilingual Plane, ISO/IEC
10646-1: 1993 (with amendments). 10646-1: 1993 (with amendments).
[JPEG] JPEG File Interchange Format (Version 1.02). Eric [JPEG] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
1992. 1992.
[ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", draft-ietf- (LDAP): Technical Specification Road Map", draft-ietf-
ldapbis-roadmap-xx.txt, a work in progress, February 2004. ldapbis-roadmap-xx.txt, a work in progress, February 2005.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
ietf-ldapbis-models-xx.txt, a work in progress, February ietf-ldapbis-models-xx.txt, a work in progress, February
2004. 2005.
[PREP] Zeilenga, K., "LDAP: Internationalized String [PREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
progress, February 2004. progress, February 2005.
Informative References Informative References
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute "Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997. Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
with LDAPv3", RFC 2256, December 1997. with LDAPv3", RFC 2256, December 1997.
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377, Protocol (v3): Technical Specification", RFC 3377,
September 2002. September 2002.
[RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Additional Matching Rules", RFC 3698, February (LDAP): Additional Matching Rules", RFC 3698, February
2004. 2004.
[SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
ietf-ldapbis-user-schema-xx.txt, a work in progress, June ietf-ldapbis-user-schema-xx.txt, a work in progress, July
2003. 2004.
[LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in (LDAP) schema definitions for X.509 Certificates", draft-
progress, July 2002. zeilenga-ldap-x509-xx.txt, a work in progress, February
2005.
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
Information Technology - Open Systems Interconnection - Information Technology - Open Systems Interconnection -
The Directory: Overview of concepts, models and services The Directory: Overview of concepts, models and services
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules: Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER) (DER)
Authors' Addresses Authors' Addresses
Steven Legg Steven Legg
eB2Bcom eB2Bcom
skipping to change at page 52, line 35 skipping to change at page 53, line 20
7515 Colshire Dr., ms-W650 7515 Colshire Dr., ms-W650
McLean VA 22102 McLean VA 22102
USA USA
Phone: +1 703 883 6058 Phone: +1 703 883 6058
Fax: +1 703 883 7142 Fax: +1 703 883 7142
Email: kdally@mitre.org Email: kdally@mitre.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
skipping to change at page 53, line 24 skipping to change at page 54, line 9
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
This Internet-Draft expires on 7 April 2005. This Internet-Draft expires on 18 August 2005.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/