Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26
Integer 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
Appendix B. Changes from RFC 2252
This annex lists the significant differences between this
specification and RFC 2252.
This annex is provided for informational purposes only. It is not a
normative part of this specification.
1. The IESG Note has been removed.
2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512]
and revised. Changes to the parts of these sections moved to
[RFC4512] are detailed in [RFC4512].
3. BNF descriptions of syntax formats have been replaced by ABNF
[RFC4234] specifications.
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
use of a backslash quoting mechanism to escape separator symbols
has been removed. The escaping mechanism is now explicitly
represented in the ABNF for the syntaxes where this provision
applies.
5. The description of each of the LDAP syntaxes has been expanded so
that they are less dependent on knowledge of X.500 for
interpretation.
6. The relationship of LDAP syntaxes to corresponding ASN.1 type
definitions has been made explicit.
7. The set of characters allowed in a <PrintableString> (formerly
<printablestring>) has been corrected to align with the
PrintableString ASN.1 type in [ASN.1]. Specifically, the double
quote character has been removed and the single quote character
and equals sign have been added.
8. Values of the Directory String, Printable String and Telephone
Number syntaxes are now required to have at least one character.
9. The <DITContentRuleDescription>, <NameFormDescription> and
<DITStructureRuleDescription> rules have been moved to [RFC4512].
10. The corresponding ASN.1 type for the Other Mailbox syntax has
been incorporated from RFC 1274.
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
has been invented.
12. The Binary syntax has been removed because it was not adequately
specified, implementations with different incompatible
interpretations exist, and it was confused with the ;binary
transfer encoding.
13. All discussion of transfer options, including the ";binary"
option, has been removed. All imperatives regarding binary
transfer of values have been removed.
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
Terminal Identifier and Telex Number syntaxes from RFC 2256 have
been incorporated.
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
been extended to accommodate empty "and" and "or" expressions.
16. An encoding for the <ttx-value> rule in the Teletex Terminal
Identifier syntax has been defined.
17. The PKI-related syntaxes (Certificate, Certificate List and
Certificate Pair) have been removed. They are reintroduced in
[RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
18. The MHS OR Address syntax has been removed since its
specification (in RFC 2156) is not at draft standard maturity.
19. The DL Submit Permission syntax has been removed as it depends on
the MHS OR Address syntax.
20. The Presentation Address syntax has been removed since its
specification (in RFC 1278) is not at draft standard maturity.
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
Type, LDAP Schema Description, Master And Shadow Access Points,
Modify Rights, Protocol Information, Subtree Specification,
Supplier Information, Supplier Or Consumer and Supplier And
Consumer syntaxes have been removed. These syntaxes are
referenced in RFC 2252, but not defined.
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
Mail Preference syntax have been removed on the grounds that they
are out of scope for the core specification.
23. The description of each of the matching rules has been expanded
so that they are less dependent on knowledge of X.500 for
interpretation.
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
been added.
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
caseIgnoreSubstringsMatch matching rules have been added to the
list of matching rules for which the provisions for handling
leading, trailing and multiple adjoining whitespace characters
apply (now through string preparation). This is consistent with
the definitions of these matching rules in X.500. The
caseIgnoreIA5SubstringsMatch rule has also been added to the
list.
26. The specification of the octetStringMatch matching rule from
RFC 2256 has been added to this document.
27. The presentationAddressMatch matching rule has been removed as it
depends on an assertion syntax (Presentation Address) that is not
at draft standard maturity.
28. The protocolInformationMatch matching rule has been removed as it
depends on an undefined assertion syntax (Protocol Information).
29. The definitive reference for ASN.1 has been changed from X.208 to
X.680 since X.680 is the version of ASN.1 referred to by X.500.
30. The specification of the caseIgnoreListSubstringsMatch matching
rule from RFC 2798 & X.520 has been added.
31. String preparation algorithms have been applied to the character
string matching rules.
32. The specifications of the booleanMatch, caseExactMatch,
caseExactOrderingMatch, caseExactSubstringsMatch,
directoryStringFirstComponentMatch, integerOrderingMatch,
keywordMatch, numericStringOrderingMatch,
octetStringOrderingMatch and wordMatch matching rules from
RFC 3698 & X.520 have been added.
Author’s Address
Steven Legg
eB2Bcom
Suite3, Woodhouse Corporate Centre
935 Station Street
Box Hill North, Victoria 3129
AUSTRALIA
Phone: +61 3 9896 7830
Fax: +61 3 9896 7801
EMail: steven.legg@eb2bcom.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).