rfc2252.txt

<VC++网络游戏建摸与实现>源代码

RFC 2252                   LADPv3 Attributes               December 1997


    ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
      SUP top AUXILIARY )

   The mandatory attributes of the other object classes of this entry
   are still required to be present.

   Note that not all servers will implement this object class, and those
   which do not will reject requests to add entries which contain this
   object class, or modify an entry to add this object class.

7.2. subschema

   This object class is used in the subschema entry.

    ( 2.5.20.1 NAME 'subschema' AUXILIARY
      MAY ( dITStructureRules $ nameForms $ ditContentRules $
      objectClasses $ attributeTypes $ matchingRules $
      matchingRuleUse ) )

   The ldapSyntaxes operational attribute may also be present in
   subschema entries.

8. Matching Rules

   Servers which implement the extensibleMatch filter SHOULD allow all
   the matching rules listed in this section to be used in the
   extensibleMatch.  In general these servers SHOULD allow matching
   rules to be used with all attribute types known to the server, when
   the assertion syntax of the matching rule is the same as the value
   syntax of the attribute.

   Servers MAY implement additional matching rules.

8.1. Matching Rules used in Equality Filters

   Servers SHOULD be capable of performing the following matching rules.

   For all these rules, the assertion syntax is the same as the value
   syntax.

    ( 2.5.13.0 NAME 'objectIdentifierMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   If the client supplies a filter using an objectIdentifierMatch whose
   matchValue oid is in the "descr" form, and the oid is not recognized
   by the server, then the filter is Undefined.

    ( 2.5.13.1 NAME 'distinguishedNameMatch'



Wahl, et. al.               Standards Track                    [Page 25]

RFC 2252                   LADPv3 Attributes               December 1997


      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )

    ( 2.5.13.2 NAME 'caseIgnoreMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

    ( 2.5.13.8 NAME 'numericStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )

    ( 2.5.13.11 NAME 'caseIgnoreListMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )

    ( 2.5.13.14 NAME 'integerMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

    ( 2.5.13.16 NAME 'bitStringMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )

    ( 2.5.13.20 NAME 'telephoneNumberMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

    ( 2.5.13.22 NAME 'presentationAddressMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )

    ( 2.5.13.23 NAME 'uniqueMemberMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )

    ( 2.5.13.24 NAME 'protocolInformationMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )

    ( 2.5.13.27 NAME 'generalizedTimeMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

    ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

    ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

   When performing the caseIgnoreMatch, caseIgnoreListMatch,
   telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
   multiple adjoining whitespace characters are treated the same as an
   individual space, and leading and trailing whitespace is ignored.

   Clients MUST NOT assume that servers are capable of transliteration
   of Unicode values.






Wahl, et. al.               Standards Track                    [Page 26]

RFC 2252                   LADPv3 Attributes               December 1997


8.2. Matching Rules used in Inequality Filters

   Servers SHOULD be capable of performing the following matching rules,
   which are used in greaterOrEqual and lessOrEqual filters.

    ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

    ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

   The sort ordering for a caseIgnoreOrderingMatch is implementation-
   dependent.

8.3. Syntax and Matching Rules used in Substring Filters

   The Substring Assertion syntax is used only as the syntax of
   assertion values in the extensible match.  It is not used as the
   syntax of attributes, or in the substring filter.

   ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )

   The Substring Assertion is encoded according to the following BNF:

      substring = [initial] any [final]
      initial = value
      any = "*" *(value "*")
      final = value

   The <value> production is UTF-8 encoded string.  Should the backslash
   or asterix characters be present in a production of <value>, they are
   quoted as described in section 4.3.

   Servers SHOULD be capable of performing the following matching rules,
   which are used in substring filters.

   ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )

   ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )







Wahl, et. al.               Standards Track                    [Page 27]

RFC 2252                   LADPv3 Attributes               December 1997


8.4. Matching Rules for Subschema Attributes

   Servers which allow subschema entries to be modified by clients MUST
   support the following matching rules, as they are the equality
   matching rules for several of the subschema attributes.

   ( 2.5.13.29 NAME 'integerFirstComponentMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

   ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
     SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

   Implementors should note that the assertion syntax of these matching
   rules, an INTEGER or OID, is different from the value syntax of
   attributes for which this is the equality matching rule.

   If the client supplies an extensible filter using an
   objectIdentifierFirstComponentMatch whose matchValue is in the
   "descr" form, and the OID is not recognized by the server, then the
   filter is Undefined.

9. Security Considerations

9.1. Disclosure

   Attributes of directory entries are used to provide descriptive
   information about the real-world objects they represent, which can be
   people, organizations or devices.  Most countries have privacy laws
   regarding the publication of information about people.

9.2. Use of Attribute Values in Security Applications

   The transformations of an AttributeValue value from its X.501 form to
   an LDAP string representation are not always reversible back to the
   same BER or DER form.  An example of a situation which requires the
   DER form of a distinguished name is the verification of an X.509
   certificate.

   For example, a distinguished name consisting of one RDN with one AVA,
   in which the type is commonName and the value is of the TeletexString
   choice with the letters 'Sam' would be represented in LDAP as the
   string CN=Sam.  Another distinguished name in which the value is
   still 'Sam' but of the PrintableString choice would have the same
   representation CN=Sam.

   Applications which require the reconstruction of the DER form of the
   value SHOULD NOT use the string representation of attribute syntaxes
   when converting a value to LDAP format.  Instead it SHOULD use the



Wahl, et. al.               Standards Track                    [Page 28]

RFC 2252                   LADPv3 Attributes               December 1997


   Binary syntax.

10. Acknowledgements

   This document is based substantially on RFC 1778, written by Tim
   Howes, Steve Kille, Wengyik Yeong and Colin Robbins.

   Many of the attribute syntax encodings defined in this and related
   documents are adapted from those used in the QUIPU and the IC R3
   X.500 implementations. The contributions of the authors of both these
   implementations in the specification of syntaxes are gratefully
   acknowledged.







































Wahl, et. al.               Standards Track                    [Page 29]

RFC 2252                   LADPv3 Attributes               December 1997


11. Authors' Addresses

   Mark Wahl
   Critical Angle Inc.
   4815 West Braker Lane #502-385
   Austin, TX 78759
   USA

   Phone:  [phone]
   EMail:  [e-mail]

   Andy Coulbeck
   Isode Inc.
   9390 Research Blvd Suite 305
   Austin, TX 78759
   USA

   Phone:  [phone]
   EMail:  [e-mail]

   Tim Howes
   Netscape Communications Corp.
   501 E. Middlefield Rd, MS MV068
   Mountain View, CA 94043
   USA

   Phone:  [phone]
   EMail:   [e-mail]

   Steve Kille
   Isode Limited
   The Dome, The Square
   Richmond
   TW9 1DT
   UK

   Phone:  [phone]
   EMail:  [e-mail]













Wahl, et. al.               Standards Track                    [Page 30]

RFC 2252                   LADPv3 Attributes               December 1997


12. Bibliography

   [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
       Protocol (v3)", RFC 2251, December 1997.

   [2] The Directory: Selected Attribute Types.  ITU-T Recommendation
       X.520, 1993.

   [3] The Directory: Models. ITU-T Recommendation X.501, 1993.

   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", RFC 2119, March 1997.

   [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
       Protocol (v3): UTF-8 String Representation of
       Distinguished Names", RFC 2253, December 1997.

   [6] Kille, S., "A String Representation for Presentation Addresses",
       RFC 1278, November 1991.

   [7] Terminal Equipment and Protocols for Telematic Services -
       Standardization of Group 3 facsimile apparatus for document
       transmission.  CCITT, Recommendation T.4.

   [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton,
       C-Cube Microsystems, Milpitas, CA, September 1, 1992.

   [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
       10646", RFC 2044, October 1996.

   [10] Universal Multiple-Octet Coded Character Set (UCS) -
        Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
        1993 (With amendments).

   [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
        and RFC 822", RFC 1327, May 1992.

   [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
        with LDAPv3", RFC 2256, December 1997.

   [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
        Messages", STD 11, RFC 822, August 1982.

   [14] ISO 3166, "Codes for the representation of names of countries".

   [15] ITU-T Rec. E.123, Notation for national and international
        telephone numbers, 1988.




Wahl, et. al.               Standards Track                    [Page 31]

RFC 2252                   LADPv3 Attributes               December 1997


13.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Wahl, et. al.               Standards Track                    [Page 32]