-INTERNET-DRAFT S. Legg, Editor
-draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies
-Intended Category: Standards Track K. Dally
-Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
- 27 October 2003
+INTERNET-DRAFT S. Legg
+draft-ietf-ldapbis-syntaxes-11.txt eB2Bcom
+Intended Category: Standards Track 23 June 2005
+Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
- LDAP: Syntaxes and Matching Rules
+ Lightweight Directory Access Protocol (LDAP):
+ Syntaxes and Matching Rules
- Copyright (C) The Internet Society (2003). All Rights Reserved.
+ Copyright (C) The Internet Society (2005). All Rights Reserved.
Status of this Memo
+ By submitting this Internet-draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC2026.
+ By submitting this Internet-draft, I accept the provisions of Section
+ 3 of BCP 78.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
+ http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
+ http://www.ietf.org/shadow.html
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
this document should take place on the IETF LDAP Revision Working
Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
send editorial comments directly to the editor
- <steven.legg@adacel.com.au>.
-
- This Internet-Draft expires on 27 April 2004.
+ <steven.legg@eb2bcom.com>.
+ This Internet-Draft expires on 23 December 2005.
Abstract
- Each attribute stored in a Lightweight Directory Access Protocol
- (LDAP) directory, and whose values may be transfered in the LDAP
-
-Legg & Dally Expires 27 April 2004 [Page 1]
+Legg Expires 23 December 2005 [Page 1]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ Each attribute stored in a Lightweight Directory Access Protocol
+ (LDAP) directory, and whose values may be transfered in the LDAP
protocol, has a defined syntax which 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
-
-
-Legg & Dally Expires 27 April 2004 [Page 2]
+Legg Expires 23 December 2005 [Page 2]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
Table of Contents
2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. General Considerations . . . . . . . . . . . . . . . . . 6
- 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6
+ 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 7
3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
3.3.1. Attribute Type Description . . . . . . . . . . . 7
- 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7
+ 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 8
3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
3.3.4. Country String . . . . . . . . . . . . . . . . . 8
3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
- 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15
- 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15
+ 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 16
+ 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 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.20. Matching Rule Use Description. . . . . . . . . . 17
+ 3.3.20. Matching Rule Use Description. . . . . . . . . . 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.24. Object Class Description . . . . . . . . . . . . 19
- 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19
+ 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 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.29. Printable String . . . . . . . . . . . . . . . . 22
- 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
+ 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
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
- 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25
+ 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1. General Considerations . . . . . . . . . . . . . . . . . 26
- 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27
- 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27
- 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28
- 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28
+ 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 28
+ 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 28
+ 4.2.2. booleanMatch . . . . . . . . . . . . . . . . . . 29
+ 4.2.3. caseExactIA5Match. . . . . . . . . . . . . . . . 29
-Legg & Dally Expires 27 April 2004 [Page 3]
+Legg Expires 23 December 2005 [Page 3]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
- 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29
- 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29
- 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30
- 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 31
- 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31
- 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 32
- 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32
- 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33
- 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33
- 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 34
- 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34
- 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 35
- 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35
- 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 36
- 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36
- 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37
- 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37
- 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 38
- 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38
- 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 39
- 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
- 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
- 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
- 8.2. Informative References . . . . . . . . . . . . . . . . . 42
- 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43
- 10. Intellectual Property Notice . . . . . . . . . . . . . . . . . 44
- Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 44
- Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 45
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 4.2.4. caseExactMatch . . . . . . . . . . . . . . . . . 30
+ 4.2.5. caseExactOrderingMatch . . . . . . . . . . . . . 30
+ 4.2.6. caseExactSubstringsMatch . . . . . . . . . . . . 31
+ 4.2.7. caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
+ 4.2.8. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
+ 4.2.9. caseIgnoreListMatch. . . . . . . . . . . . . . . 32
+ 4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
+ 4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
+ 4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
+ 4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
+ 4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
+ 4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
+ 4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
+ 4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
+ 4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
+ 4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
+ 4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
+ 4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
+ 4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
+ 4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
+ 4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
+ 4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
+ 4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
+ 4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
+ 4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
+ 4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
+ 4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
+ 4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
+ 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 44
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
+ 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
+ Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
+ Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
+ Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
+ Informative References . . . . . . . . . . . . . . . . . . . . . . 52
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
1. Introduction
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
+
+
+
+Legg Expires 23 December 2005 [Page 4]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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.
Information Models [MODELS] 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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 4]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
LDAP.
This document is a integral part of the LDAP technical specification
Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
The remainder of RFC 2252 is obsoleted by this document. Sections 6
and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
- remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].
+ remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. All but
+ Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
A number of schema elements which were included in the previous
revision of the LDAP technical specification are not included in this
specified in [LDAP-PKI]. Unless reintroduced in future technical
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.
2. Conventions
3. Syntaxes
+
+
+
+Legg Expires 23 December 2005 [Page 5]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
Syntax definitions constrain the structure of attribute values stored
in an LDAP directory, and determine the representation of attribute
and assertion values transfered in the LDAP protocol.
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 5]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
discouraged since it will hinder interoperability. Client and server
implementations typically do not have the ability to dynamically
recognize new syntaxes.
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
+
+
+
+Legg Expires 23 December 2005 [Page 6]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
longer character strings. Note that a single character of the
Directory String syntax can be encoded in more than one octet since
UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
The following ABNF rules are used in a number of the syntax
definitions in Section 3.3.
-
-
-Legg & Dally Expires 27 April 2004 [Page 6]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
PLUS / COMMA / HYPHEN / DOT / EQUALS /
SLASH / COLON / QUESTION / SPACE
PrintableString = 1*PrintableCharacter
IA5String = *(%x00-7F)
- HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
- ; N.B. allows upper and lower case
SLASH = %x2F ; forward slash ("/")
COLON = %x3A ; colon (":")
QUESTION = %x3F ; question mark ("?")
- The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
- <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
- [MODELS].
+ The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
+ <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
3.3. Syntax Definitions
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 [MODELS].
- For example, the following definition of the createTimestamp
- attribute type from [MODELS] 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 transfered 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 )
+
+ For example, the following definition of the createTimestamp
+ attribute type from [MODELS] 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 transfered 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
+
+
+
+Legg Expires 23 December 2005 [Page 7]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
from [X.501].
3.3.2. Bit String
following ABNF:
BitString = SQUOTE *binary-digit SQUOTE "B"
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 7]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
binary-digit = "0" / "1"
The <SQUOTE> rule is defined in [MODELS].
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]:
+Legg Expires 23 December 2005 [Page 8]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ US
+ AU
+ The LDAP definition for the Country String syntax is:
-Legg & Dally Expires 27 April 2004 [Page 8]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+ ( 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
3.3.6. Directory String
+
+
+
+Legg Expires 23 December 2005 [Page 9]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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
The <UTF8> rule is defined in [MODELS].
-
-
-Legg & Dally Expires 27 April 2004 [Page 9]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
Example:
This is a value of Directory String containing #!%#@.
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.
+ 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 [PREP] for LDAP.
3.3.7. DIT Content Rule Description
A value of the DIT Content Rule Description syntax is the definition
+
+
+
+Legg Expires 23 December 2005 [Page 10]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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 [MODELS].
( 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 & Dally Expires 27 April 2004 [Page 10]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
+ Note: a line break has been added for readability - it is not part
+ of the value.
The LDAP definition for the DIT Content Rule Description syntax is:
A value of the DN syntax is the (purported) distinguished name (DN)
of an entry [MODELS]. The LDAP-specific encoding of a value of this
- syntax is defined by the <distinguishedName> rule in [LDAPDN].
+ syntax is defined by the <distinguishedName> rule from the string
+ representation of distinguished names [LDAPDN].
Examples (from [LDAPDN]):
UID=jsmith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
CN=John Smith\, III,DC=example,DC=net
+
+
+
+Legg Expires 23 December 2005 [Page 11]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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
[X.501]. Note that a BER encoded distinguished name (as used by
X.500) re-encoded into the LDAP-specific encoding is not necessarily
reversible to the original BER encoding since the chosen string type
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 11]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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).
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
<DOLLAR> rules are defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 12]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Enhanced Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
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 & Dally Expires 27 April 2004 [Page 12]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
"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.
A value of the Fax syntax is an image which is produced using the
Group 3 facsimile process [FAX] to duplicate an object, such as a
+
+
+
+Legg Expires 23 December 2005 [Page 13]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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].
assuming EXPLICIT TAGS:
Fax ::= CHOICE {
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 13]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
g3-facsimile [3] G3FacsimileBodyPart
}
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"
/ ( %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"
- / ( %x36 %x30 ) ; "60" (a leap second)
- GeneralizedTime = century year month day hour
- [ minute [ second ] ] [ fraction ]
- g-time-zone
+ 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
The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 14]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 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
Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
otherwise the value represents a local time in the time zone
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:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 14]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
10:32 AM, December 16, 1994.
The LDAP definition for the Generalized Time syntax is:
The <object-class> and <criteria> rules are defined in Section
3.3.10. The <SHARP> rule is defined in [MODELS].
+
+
+Legg Expires 23 December 2005 [Page 15]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Guide syntax is:
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
3.3.16. Integer
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 15]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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
The LDAP definition for the JPEG syntax is:
+
+
+Legg Expires 23 December 2005 [Page 16]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
The JPEG syntax corresponds to the following ASN.1 type:
The above LDAP definition for the LDAP Syntax Description syntax is
itself a legal value of the LDAP Syntax Description syntax.
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 16]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
The ASN.1 type corresponding to the LDAP Syntax Description syntax is
defined as follows, assuming EXPLICIT TAGS:
The LDAP definition for the Matching Rule Description syntax is:
+
+
+
+Legg Expires 23 December 2005 [Page 17]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
This syntax corresponds to the MatchingRuleDescription ASN.1 type
( 1.3.6.1.4.1.1466.115.121.1.31
DESC 'Matching Rule Use Description' )
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 17]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
from [X.501].
Example:
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
+
+
+
+Legg Expires 23 December 2005 [Page 18]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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' )
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 18]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
This syntax corresponds to the NameFormDescription ASN.1 type from
[X.501].
A value of the Object Class Description syntax is the definition of
an object class. The LDAP-specific encoding of a value of this
+
+
+
+Legg Expires 23 December 2005 [Page 19]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
syntax is defined by the <ObjectClassDescription> rule in [MODELS].
Example:
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 19]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
following ABNF:
OctetString = *OCTET
1.2.3.4
cn
+
+
+
+Legg Expires 23 December 2005 [Page 20]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the OID syntax is:
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
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.
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 20]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
The <DOLLAR> rule is defined in [MODELS].
The LDAP definition for the Other Mailbox syntax is:
line = 1*line-char
line-char = %x00-23
/ (%x5C "24") ; escaped "$"
+
+
+
+Legg Expires 23 December 2005 [Page 21]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
/ %x25-5B
/ (%x5C "5C") ; escaped "\"
/ %x5D-7F
Each character string (i.e., <line>) of a postal address value is
encoded as a UTF-8 [UTF8] 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 <HEX-DIGIT>
- rule is defined in Section 3.2. The <DOLLAR> and <UTFMB> rules are
- defined in [MODELS].
+ by the two hexadecimal digit code for the character. The <DOLLAR>
+ and <UTFMB> rules are defined in [MODELS].
Many servers limit the postal address to no more than six lines of no
more than thirty characters each.
The LDAP definition for the Postal Address syntax is:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 21]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
( 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],
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
+
+
+
+Legg Expires 23 December 2005 [Page 22]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
This syntax corresponds to the PrintableString ASN.1 type from
[ASN.1].
initial = substring
any = ASTERISK *(substring ASTERISK)
final = substring
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 22]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
ASTERISK = %x2A ; asterisk ("*")
substring = 1*substring-character
3.3.31. Telephone Number
+
+
+
+Legg Expires 23 December 2005 [Page 23]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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].
unconverted string of characters, which conforms to the
<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:
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
-
-Legg & Dally Expires 27 April 2004 [Page 23]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
- 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.
+ 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:
ttx-term = PrintableString ; terminal identifier
ttx-param = ttx-key COLON ttx-value ; parameter
ttx-key = "graphic" / "control" / "misc" / "page" / "private"
- ttx-value = *ttx-value-char
+ ttx-value = *ttx-value-octet
- ttx-value-char = %x00-23
- / (%x5C "24") ; escaped "$"
- / %x25-5B
- / (%x5C "5C") ; escaped "\"
- / %x5D-FF
+ ttx-value-octet = %x00-23
+ / (%x5C "24") ; escaped "$"
+ / %x25-5B
+ / (%x5C "5C") ; escaped "\"
+ / %x5D-FF
The <PrintableString> and <COLON> rules are defined in Section 3.2.
The <DOLLAR> rule is defined in [MODELS].
+
+
+
+Legg Expires 23 December 2005 [Page 24]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the Teletex Terminal Identifier syntax is:
( 1.3.6.1.4.1.1466.115.121.1.51
answerback = PrintableString
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 24]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
rule is defined in [MODELS].
The LDAP definition for the Telex Number syntax is:
rules are defined in Section 3.3.13. The <PLUS> rule is defined in
[MODELS].
+
+
+Legg Expires 23 December 2005 [Page 25]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 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
of <u-time-zone> is used, otherwise the value represents a local
time. In the latter case, if <u-differential> is provided then
Matching rules are used by directory implementations to compare
attribute values against assertion values when performing Search and
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 25]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
Compare operations [PROT]. They are also used when comparing a
purported distinguished name [MODELS] with the name of an entry.
When modifying entries, matching rules are used to identify values to
A matching rule is applied to attribute values through an
AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
conditions under which an AttributeValueAssertion or
- MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
- If an assertion is not Undefined then the result of the 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.
+ MatchingRuleAssertion evaluates to Undefined are specified elsewhere
+ [PROT]. If an assertion is not Undefined then the result of the
+ 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
+
+
+
+Legg Expires 23 December 2005 [Page 26]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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 the AssertionValue in a SubstringFilter
- [PROT] MUST conform to the assertion syntax of the equality matching
- rule for the attribute type rather than the assertion syntax of the
- substrings matching rule for the attribute type. The entire
- SubstringFilter is converted into an assertion value of the
+ may be applied. Note that an AssertionValue in a SubstringFilter
+ [PROT] conforms to the assertion syntax of the equality matching rule
+ for the attribute type rather than 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
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 26]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
attribute type definition [MODELS].
Each matching rule is uniquely identified with an object identifier.
If a change is desirable then a new matching rule with a different
object identifier should be defined instead.
- Servers SHOULD implement all the matching rules in Section 4.2.
+ Servers MAY implement the wordMatch and keywordMatch matching rules,
+ but SHOULD implement the other matching rules in Section 4.2.
Servers MAY implement additional matching rules.
Servers which implement the extensibleMatch filter SHOULD allow the
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
+
+
+
+Legg Expires 23 December 2005 [Page 27]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
unreferenced matching rules MAY be published in the matchingRules
attribute.
4.2. Matching Rule Definitions
- When evaluating the numericStringMatch, numericStringSubstringsMatch,
- caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
- caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
- caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
- telephoneNumberMatch and telephoneNumberSubstringsMatch matching
- rules the assertion value and attribute value are prepared according
- to the string preparation algorithms [PREP] for LDAP before being
- compared. The Transcode, Normalize, Prohibit and Check bidi steps
- are the same for each of the matching rules. However, the Map and
- Insignificant Character Removal steps depends on the specific rule,
- as detailed in the description of these matching rules in the
- sections that follow.
+ Nominated character strings in assertion and attribute values are
+ prepared according to the string preparation algorithms [PREP] 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 depends on the specific rule, as detailed in
+ the description of these matching rules in the sections that follow.
4.2.1. bitStringMatch
syntax to an attribute value of a syntax (e.g., the Bit String
syntax) whose corresponding ASN.1 type is BIT STRING.
+ 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.
+
-Legg & Dally Expires 27 April 2004 [Page 27]
+Legg Expires 23 December 2005 [Page 28]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- 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
- 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 bitStringMatch rule is an equality matching rule.
-4.2.2. caseExactIA5Match
+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
In preparing the attribute value and assertion value for comparison,
characters are not case folded in the Map preparation step, and only
- Insignificant Space Removal is applied in the Insignificant Character
- Removal step.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
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 )
+
+
+
+Legg Expires 23 December 2005 [Page 29]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The caseExactIA5Match rule is an equality matching rule.
-4.2.3. caseIgnoreIA5Match
+4.2.4. caseExactMatch
- 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.
+ 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, e.g., 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.
+
+ 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:
-Legg & Dally Expires 27 April 2004 [Page 28]
+
+Legg Expires 23 December 2005 [Page 30]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ ( 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 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, and an <initial> substring, if present, matches the
+ beginning of the prepared attribute value character string, and 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.
+ 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 Removal is applied in the Insignificant Character
- Removal step.
+
+
+
+Legg Expires 23 December 2005 [Page 31]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreIA5Match rule is:
The caseIgnoreIA5Match rule is an equality matching rule.
-4.2.4. caseIgnoreIA5SubstringsMatch
+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
In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step,
- and only Insignificant Space Removal is applied in the Insignificant
- Character Removal 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.5. caseIgnoreListMatch
+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
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.
-Legg & Dally Expires 27 April 2004 [Page 29]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+Legg Expires 23 December 2005 [Page 32]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
- 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:
The caseIgnoreListMatch rule is an equality matching rule.
-4.2.6. caseIgnoreListSubstringsMatch
+4.2.10. caseIgnoreListSubstringsMatch
The caseIgnoreListSubstringsMatch rule compares an assertion value of
the Substring Assertion syntax to an attribute value of a syntax
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
-Legg & Dally Expires 27 April 2004 [Page 30]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-4.2.7. caseIgnoreMatch
+Legg Expires 23 December 2005 [Page 33]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
- 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 the
- alternative string types of DirectoryString, e.g., PrintableString
- (the other alternatives do not correspond to any syntax defined in
- this document).
+ 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
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
- Insignificant Space Removal is applied in the Insignificant Character
- Removal step.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreMatch rule is:
The caseIgnoreMatch rule is an equality matching rule.
-4.2.8. caseIgnoreOrderingMatch
+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
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
- Insignificant Space Removal is applied in the Insignificant Character
- Removal step.
+ Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreOrderingMatch rule is:
( 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
-Legg & Dally Expires 27 April 2004 [Page 31]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
- SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
- The caseIgnoreOrderingMatch rule is an ordering matching rule.
+Legg Expires 23 December 2005 [Page 34]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
-4.2.9. caseIgnoreSubstringsMatch
The caseIgnoreSubstringsMatch rule compares an assertion value of the
Substring Assertion syntax to an attribute value of a syntax (e.g.,
In preparing the attribute value and assertion value substrings for
comparison, characters are case folded in the Map preparation step,
- and only Insignificant Space Removal is applied in the Insignificant
- Character Removal step.
+ and only Insignificant Space Handling is applied in the Insignificant
+ Character Handling step.
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
-4.2.10. distinguishedNameMatch
+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.
+
+ 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 )
+
+
+
+Legg Expires 23 December 2005 [Page 35]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 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
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 32]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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 distinguishedNameMatch rule is an equality matching rule.
-4.2.11. generalizedTimeMatch
+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
then the number of minutes or seconds (respectively) is assumed to be
zero.
+
+
+Legg Expires 23 December 2005 [Page 36]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The LDAP definition for the generalizedTimeMatch rule is:
( 2.5.13.27 NAME 'generalizedTimeMatch'
The generalizedTimeMatch rule is an equality matching rule.
-4.2.12. generalizedTimeOrderingMatch
+4.2.17. generalizedTimeOrderingMatch
The generalizedTimeOrderingMatch rule compares the time ordering of
an assertion value of the Generalized Time syntax to an attribute
The LDAP definition for the generalizedTimeOrderingMatch rule is:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 33]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
( 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.13. integerFirstComponentMatch
+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
The integerFirstComponentMatch rule is an equality matching rule.
When using integerFirstComponentMatch to compare two attribute values
+
+
+
+Legg Expires 23 December 2005 [Page 37]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
(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.14. integerMatch
+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)
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 the assertion value.
+
+ The LDAP definition for the integerOrderingMatch matching rule is:
+
+ ( 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.
+
-Legg & Dally Expires 27 April 2004 [Page 34]
+
+Legg Expires 23 December 2005 [Page 38]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+ 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.15. numericStringMatch
+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
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 Removal is applied in the
- Insignificant Character Removal step.
+ numericString Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
The LDAP definition for the numericStringMatch matching rule is:
The numericStringMatch rule is an equality matching rule.
-4.2.16. numericStringSubstringsMatch
+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
+
+
+
+Legg Expires 23 December 2005 [Page 39]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ irrelevant as 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
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 Removal is applied in the
- Insignificant Character Removal step.
+ 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.
-Legg & Dally Expires 27 April 2004 [Page 35]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
- ( 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.17. objectIdentifierFirstComponentMatch
+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
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
+
+
+
+Legg Expires 23 December 2005 [Page 40]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
first component of the OBJECT IDENTIFIER ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
The LDAP definition for the objectIdentifierFirstComponentMatch
matching rule is:
- ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
+ ( 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
value can be derived from an attribute value by taking the first
component of that attribute value.
-4.2.18. objectIdentifierMatch
+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
<numericoid> form of <oid> or implicitly in the <descr> form (see
[MODELS]).
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 36]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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 objectIdentifierMatch rule is an equality matching rule.
-4.2.19. octetStringMatch
+4.2.27. octetStringMatch
+
+
+
+
+Legg Expires 23 December 2005 [Page 41]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
The octetStringMatch rule compares an assertion value of the Octet
String syntax to an attribute value of a syntax (e.g the Octet String
The octetStringMatch rule is an equality matching rule.
-4.2.20. telephoneNumberMatch
+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
+ 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.
+
+
+
+Legg Expires 23 December 2005 [Page 42]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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
In preparing the attribute value and assertion value for comparison,
characters are case folded in the Map preparation step, and only
- telephoneNumber Insignificant Character Removal is applied in the
- Insignificant Character Removal step.
+ telephoneNumber Insignificant Character Handling is applied in the
+ Insignificant Character Handling step.
The LDAP definition for the telephoneNumberMatch matching rule is:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 37]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
( 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.21. telephoneNumberSubstringsMatch
+4.2.30. telephoneNumberSubstringsMatch
The telephoneNumberSubstringsMatch rule compares an assertion value
of the Substring Assertion syntax to an attribute value of a syntax
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 Removal is applied
- in the Insignificant Character Removal step.
+ and only telephoneNumber Insignificant Character Handling is applied
+ in the Insignificant Character Handling step.
The LDAP definition for the telephoneNumberSubstringsMatch matching
rule is:
The telephoneNumberSubstringsMatch rule is a substrings matching
rule.
-4.2.22. uniqueMemberMatch
+
+
+
+Legg Expires 23 December 2005 [Page 43]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+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
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 the <BitString> component is
- absent from the attribute value or matches the <BitString> component
- of the assertion value according to the bitStringMatch rule.
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 38]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
+ to the distinguishedNameMatch rule and either, the <BitString>
+ component is absent from both the attribute value and assertion
+ 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 uniqueMemberMatch rule is an equality matching rule.
+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
+
+
+
+Legg Expires 23 December 2005 [Page 44]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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
6. Acknowledgements
- This document is an 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.
+ 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.
This document is based upon input of the IETF LDAPBIS working group.
- The authors wish to thank J. Sermersheim and K. Zeilenga for their
- significant contribution to this revision.
+ The author would like to thank Kathy Dally for editing the early
+ drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
+ their significant contributions to this revision.
7. IANA Considerations
the LDAP descriptors registry [BCP64] as indicated by the following
templates:
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 39]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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@adacel.com.au>
+ Steven Legg <steven.legg@eb2bcom.com>
Usage: see comment
Specification: RFC XXXX
Author/Change Controller: IESG
Comments:
+
+
+Legg Expires 23 December 2005 [Page 45]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
The following descriptors (short names) should be updated to refer
to RFC XXXX.
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.31
+ objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17
+ octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20
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 should be changed to the following with a reference to RFC
- XXXX.
+ It should be changed to the following with a reference to
+ RFC XXXX.
NAME Type OID
------------------------------------------------------------------
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): caseIgnoreIA5SubstringsMatch
- Object Identifier: 1.3.6.1.4.1.1466.109.114.3
-Legg & Dally Expires 27 April 2004 [Page 40]
+Legg Expires 23 December 2005 [Page 46]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+ Object Identifier: 1.3.6.1.4.1.1466.109.114.3
Person & email address to contact for further information:
- Steven Legg <steven.legg@adacel.com.au>
- Usage: other (M)
- Specification: RFC XXXX
- Author/Change Controller: IESG
-
-
- Subject: Request for LDAP Descriptor Registration
- Descriptor (short name): caseIgnoreListSubstringsMatch
- Object Identifier: 2.5.13.12
- Person & email address to contact for further information:
- Steven Legg <steven.legg@adacel.com.au>
+ Steven Legg <steven.legg@eb2bcom.com>
Usage: other (M)
Specification: RFC XXXX
Author/Change Controller: IESG
-8. References
-
-8.1. Normative References
-
- [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
- Specifications: ABNF", RFC 2234, November 1997.
-
- [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
- progress, June 2003.
-
- [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
- Considerations for the Lightweight Directory Access
- Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
-
- [LDAPDN] Zeilenga, K., "LDAP: String Representation of
- Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
- in progress, June 2003.
-
- [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
- protocol-xx.txt, a work in progress, September 2003.
-
- [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
-
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 41]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
- [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".
-
- [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.
-
- [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
- draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
- June 2003.
-
- [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
- ietf-ldapbis-models-xx.txt, a work in progress, June 2003.
-
- [PREP] Zeilenga, K., "LDAP: Internationalized String
- Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
- progress, June 2003.
-
-8.2. Informative References
-
- [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
- "Lightweight Directory Access Protocol (v3): Attribute
- Syntax Definitions", RFC 2252, December 1997.
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 42]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
- [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
- with LDAPv3", RFC 2256, December 1997.
-
- [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
- Protocol (v3): Technical Specification", RFC 3377,
- September 2002.
-
- [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
- ietf-ldapbis-user-schema-xx.txt, a work in progress, June
- 2003.
-
- [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
- PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
- progress, July 2002.
-
- [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)
-
-9. Authors' Addresses
-
- Steven Legg
- Adacel Technologies Ltd.
- 250 Bay Street
- Brighton, Victoria 3186
- AUSTRALIA
-
- Phone: +61 3 8530 7710
- Fax: +61 3 8530 7888
- Email: steven.legg@adacel.com.au
-
-
- Kathy Dally
- The MITRE Corp.
- 7515 Colshire Dr., ms-W650
- McLean VA 22102
- USA
-
- Phone: +1 703 883 6058
- Fax: +1 703 883 7142
- Email: kdally@mitre.org
-
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 43]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
-10. Intellectual Property Notice
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
Appendix A. Summary of Syntax Object Identifiers
The following list summarizes the object identifiers assigned to the
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
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 44]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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
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 & RFC 2256
+
+
+Legg Expires 23 December 2005 [Page 47]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+Appendix B. Changes from RFC 2252
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
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 [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].
3. BNF descriptions of syntax formats have been replaced by ABNF
7. The set of characters allowed in a <PrintableString> (formerly
<printablestring>) has been corrected to align with the
-
-
-
-Legg & Dally Expires 27 April 2004 [Page 45]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented.
+
+
+
+Legg Expires 23 December 2005 [Page 48]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
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
Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and
- Certificate Pair from RFC 2252, and Supported Algorithm syntax
- from RFC 2256) have been removed. They are to be reintroduced in
- PKIX documents.
+ Certificate Pair) have been removed. They are reintroduced in
+ [LDAP-PKI] (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.
20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity.
-
-
-Legg & Dally Expires 27 April 2004 [Page 46]
-\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
-
-
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,
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 a core specification.
+ 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
+
+
+
+Legg Expires 23 December 2005 [Page 49]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
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.
+ 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
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 to this document.
+ 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.
+
+Normative References
+
+ [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", RFC 3629, November 2003.
+
+ [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
+ Considerations for the Lightweight Directory Access
+ Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
+
+
+
+Legg Expires 23 December 2005 [Page 50]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
+ xx.txt, a work in progress, March 2005.
+
+ [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", draft-ietf-
+ ldapbis-roadmap-xx.txt, a work in progress, February 2005.
+
+ [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
+ ietf-ldapbis-models-xx.txt, a work in progress, February
+ 2005.
+
+ [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
+ protocol-xx.txt, a work in progress, May 2005.
+
+ [LDAPDN] Zeilenga, K., "LDAP: String Representation of
+ Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
+ in progress, February 2005.
+
+ [PREP] Zeilenga, K., "LDAP: Internationalized String
+ Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
+ progress, February 2005.
+
+ [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,
+
+
+
+Legg Expires 23 December 2005 [Page 51]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ 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".
+
+ [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.
+
+Informative References
+
+ [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
+ "Lightweight Directory Access Protocol (v3): Attribute
+ Syntax Definitions", RFC 2252, December 1997.
+
+ [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification", RFC 3377,
+ September 2002.
+
+ [RFC3698] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Additional Matching Rules", RFC 3698, February
+ 2004.
+
+ [SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
+ draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
+ April 2005.
+
+ [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
+ (LDAP) schema definitions for X.509 Certificates", draft-
+ zeilenga-ldap-x509-xx.txt, a work in progress, February
+ 2005.
+
+ [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
+
+
+
+
+Legg Expires 23 December 2005 [Page 52]
+\f
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ [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)
+
+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@eb2bcom.com
+
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.
-Legg & Dally Expires 27 April 2004 [Page 47]
+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
+
+
+
+Legg Expires 23 December 2005 [Page 53]
\f
-INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
+INTERNET-DRAFT LDAP: Syntaxes and Matching Rules June 23, 2005
+
+
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
- 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 assignees.
- 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.
-Legg & Dally Expires 27 April 2004 [Page 48]
+Legg Expires 23 December 2005 [Page 54]
\f
projects / openldap / blobdiff