rfc4517.txt

samba最新软件

Network Working Group                                       S. Legg, Ed.
Request for Comments: 4517                                       eB2Bcom
Obsoletes: 2252, 2256                                          June 2006
Updates: 3698
Category: Standards Track


             Lightweight Directory Access Protocol (LDAP):
                      Syntaxes and Matching Rules


Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Each attribute stored in a Lightweight Directory Access Protocol
   (LDAP) directory, whose values may be transferred in the LDAP
   protocol, has a defined syntax that constrains the structure and
   format of its values.  The comparison semantics for values of a
   syntax are not part of the syntax definition but are instead provided
   through separately defined matching rules.  Matching rules specify an
   argument, an assertion value, which also has a defined syntax.  This
   document defines a base set of syntaxes and matching rules for use in
   defining attributes for LDAP directories.

Table of Contents

   1. Introduction ....................................................3
   2. Conventions .....................................................4
   3. Syntaxes ........................................................4
      3.1. General Considerations .....................................5
      3.2. Common Definitions .........................................5
      3.3. Syntax Definitions .........................................6
           3.3.1. Attribute Type Description ..........................6
           3.3.2. Bit String ..........................................6
           3.3.3. Boolean .............................................7
           3.3.4. Country String ......................................7
           3.3.5. Delivery Method .....................................8



Legg                        Standards Track                     [Page 1]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


           3.3.6. Directory String ....................................8
           3.3.7. DIT Content Rule Description ........................9
           3.3.8. DIT Structure Rule Description .....................10
           3.3.9. DN .................................................10
           3.3.10. Enhanced Guide ....................................11
           3.3.11. Facsimile Telephone Number ........................12
           3.3.12. Fax ...............................................12
           3.3.13. Generalized Time ..................................13
           3.3.14. Guide .............................................14
           3.3.15. IA5 String ........................................15
           3.3.16. Integer ...........................................15
           3.3.17. JPEG ..............................................15
           3.3.18. LDAP Syntax Description ...........................16
           3.3.19. Matching Rule Description .........................16
           3.3.20. Matching Rule Use Description .....................17
           3.3.21. Name and Optional UID .............................17
           3.3.22. Name Form Description .............................18
           3.3.23. Numeric String ....................................18
           3.3.24. Object Class Description ..........................18
           3.3.25. Octet String ......................................19
           3.3.26. OID ...............................................19
           3.3.27. Other Mailbox .....................................20
           3.3.28. Postal Address ....................................20
           3.3.29. Printable String ..................................21
           3.3.30. Substring Assertion ...............................22
           3.3.31. Telephone Number ..................................23
           3.3.32. Teletex Terminal Identifier .......................23
           3.3.33. Telex Number ......................................24
           3.3.34. UTC Time ..........................................24
   4. Matching Rules .................................................25
      4.1. General Considerations ....................................25
      4.2. Matching Rule Definitions .................................27
           4.2.1. bitStringMatch .....................................27
           4.2.2. booleanMatch .......................................28
           4.2.3. caseExactIA5Match ..................................28
           4.2.4. caseExactMatch .....................................29
           4.2.5. caseExactOrderingMatch .............................29
           4.2.6. caseExactSubstringsMatch ...........................30
           4.2.7. caseIgnoreIA5Match .................................30
           4.2.8. caseIgnoreIA5SubstringsMatch .......................31
           4.2.9. caseIgnoreListMatch ................................31
           4.2.10. caseIgnoreListSubstringsMatch .....................32
           4.2.11. caseIgnoreMatch ...................................33
           4.2.12. caseIgnoreOrderingMatch ...........................33
           4.2.13. caseIgnoreSubstringsMatch .........................34
           4.2.14. directoryStringFirstComponentMatch ................34
           4.2.15. distinguishedNameMatch ............................35
           4.2.16. generalizedTimeMatch ..............................36



Legg                        Standards Track                     [Page 2]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


           4.2.17. generalizedTimeOrderingMatch ......................36
           4.2.18. integerFirstComponentMatch ........................36
           4.2.19. integerMatch ......................................37
           4.2.20. integerOrderingMatch ..............................37
           4.2.21. keywordMatch ......................................38
           4.2.22. numericStringMatch ................................38
           4.2.23. numericStringOrderingMatch ........................39
           4.2.24. numericStringSubstringsMatch ......................39
           4.2.25. objectIdentifierFirstComponentMatch ...............40
           4.2.26. objectIdentifierMatch .............................40
           4.2.27. octetStringMatch ..................................41
           4.2.28. octetStringOrderingMatch ..........................41
           4.2.29. telephoneNumberMatch ..............................42
           4.2.30. telephoneNumberSubstringsMatch ....................42
           4.2.31. uniqueMemberMatch .................................43
           4.2.32. wordMatch .........................................44
   5. Security Considerations ........................................44
   6. Acknowledgements ...............................................44
   7. IANA Considerations ............................................45
   8. References .....................................................46
      8.1. Normative References ......................................46
      8.2. Informative References ....................................48
   Appendix A. Summary of Syntax Object Identifiers ..................49
   Appendix B. Changes from RFC 2252 .................................49

1.  Introduction

   Each attribute stored in a Lightweight Directory Access Protocol
   (LDAP) directory [RFC4510], whose values may be transferred in the
   LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that
   constrains the structure and format of its values.  The comparison
   semantics for values of a syntax are not part of the syntax
   definition but are instead provided through separately defined
   matching rules.  Matching rules specify an argument, an assertion
   value, which also has a defined syntax.  This document defines a base
   set of syntaxes and matching rules for use in defining attributes for
   LDAP directories.

   Readers are advised to familiarize themselves with the Directory
   Information Models [RFC4512] before reading the rest of this
   document.  Section 3 provides definitions for the base set of LDAP
   syntaxes.  Section 4 provides definitions for the base set of
   matching rules for LDAP.

   This document is an integral part of the LDAP technical specification
   [RFC4510], which obsoletes the previously defined LDAP technical
   specification, RFC 3377, in its entirety.




Legg                        Standards Track                     [Page 3]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512].  The
   remainder of RFC 2252 is obsoleted by this document.  Sections 6 and
   8 of RFC 2256 are obsoleted by this document.  The remainder of RFC
   2256 is obsoleted by [RFC4519] and [RFC4512].  All but Section 2.11
   of RFC 3698 is obsoleted by this document.

   A number of schema elements that were included in the previous
   revision of the LDAP technical specification are not included in this
   revision of LDAP.  Public Key Infrastructure schema elements are now
   specified in [RFC4523].  Unless reintroduced in future technical
   specifications, the remainder are to be considered Historic.

   The changes with respect to RFC 2252 are described in Appendix B of
   this document.

2.  Conventions

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

   Syntax definitions are written according to the <SyntaxDescription>
   ABNF [RFC4234] rule specified in [RFC4512], and matching rule
   definitions are written according to the <MatchingRuleDescription>
   ABNF rule specified in [RFC4512], except that the syntax and matching
   rule definitions provided in this document are line-wrapped for
   readability.  When such definitions are transferred as attribute
   values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
   matchingRules attributes [RFC4512], respectively), then those values
   would not contain line breaks.

3.  Syntaxes

   Syntax definitions constrain the structure of attribute values stored
   in an LDAP directory, and determine the representation of attribute
   and assertion values transferred in the LDAP protocol.

   Syntaxes that are required for directory operation, or that are in
   common use, are specified in this section.  Servers SHOULD recognize
   all the syntaxes listed in this document, but are not required to
   otherwise support them, and MAY recognise or support other syntaxes.
   However, the definition of additional arbitrary syntaxes is
   discouraged since it will hinder interoperability.  Client and server
   implementations typically do not have the ability to dynamically
   recognize new syntaxes.





Legg                        Standards Track                     [Page 4]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


3.1.  General Considerations

   The description of each syntax specifies how attribute or assertion
   values conforming to the syntax are to be represented when
   transferred in the LDAP protocol [RFC4511].  This representation is
   referred to as the LDAP-specific encoding to distinguish it from
   other methods of encoding attribute values (e.g., the Basic Encoding
   Rules (BER) encoding [BER] used by X.500 [X.500] directories).

   The LDAP-specific encoding of a given attribute syntax always
   produces octet-aligned values.  To the greatest extent possible,
   encoding rules for LDAP syntaxes should produce character strings
   that can be displayed with little or no translation by clients
   implementing LDAP.  However, clients MUST NOT assume that the LDAP-
   specific encoding of a value of an unrecognized syntax is a human-
   readable character string.  There are a few cases (e.g., the JPEG
   syntax) when it is not reasonable to produce a human-readable
   representation.

   Each LDAP syntax is uniquely identified with an object identifier
   [ASN.1] represented in the dotted-decimal format (short descriptive
   names are not defined for syntaxes).  These object identifiers are
   not intended to be displayed to users.  The object identifiers for
   the syntaxes defined in this document are summarized in Appendix A.

   A suggested minimum upper bound on the number of characters in an
   attribute value with a string-based syntax, or the number of octets
   in a value for all other syntaxes, MAY be indicated by appending the
   bound inside of curly braces following the syntax's OBJECT IDENTIFIER
   in an attribute type definition (see the <noidlen> rule in
   [RFC4512]).  Such a bound is not considered part of the syntax
   identifier.

   For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
   definition suggests that the directory server will allow a value of
   the attribute to be up to 64 characters long, although it may allow
   longer character strings.  Note that a single character of the
   Directory String syntax can be encoded in more than one octet, since
   UTF-8 [RFC3629] is a variable-length encoding.  Therefore, a 64-
   character string may be more than 64 octets in length.

3.2.  Common Definitions

   The following ABNF rules are used in a number of the syntax
   definitions in Section 3.3.

      PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
                           PLUS / COMMA / HYPHEN / DOT / EQUALS /



Legg                        Standards Track                     [Page 5]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


                           SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")

   The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
   <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in
   [RFC4512].

3.3.  Syntax Definitions

3.3.1.  Attribute Type Description

   A value of the Attribute Type Description syntax is the definition of
   an attribute type.  The LDAP-specific encoding of a value of this
   syntax is defined by the <AttributeTypeDescription> rule in
   [RFC4512].

      For example, the following definition of the createTimestamp
      attribute type from [RFC4512] is also a value of the Attribute
      Type Description syntax.  (Note: Line breaks have been added for
      readability; they are not part of the value when transferred in
      protocol.)

         ( 2.5.18.1 NAME 'createTimestamp'
            EQUALITY generalizedTimeMatch
            ORDERING generalizedTimeOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
            SINGLE-VALUE NO-USER-MODIFICATION
            USAGE directoryOperation )

   The LDAP definition for the Attribute Type Description syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )

   This syntax corresponds to the AttributeTypeDescription ASN.1 type
   from [X.501].

3.3.2.  Bit String

   A value of the Bit String syntax is a sequence of binary digits.  The
   LDAP-specific encoding of a value of this syntax is defined by the
   following ABNF:

      BitString    = SQUOTE *binary-digit SQUOTE "B"
      binary-digit = "0" / "1"



Legg                        Standards Track                     [Page 6]

RFC 4517           LDAP: Syntaxes and Matching Rules           June 2006


   The <SQUOTE> rule is defined in [RFC4512].

      Example:
         '0101111101'B