rfc4521.txt

samba最新软件

   SHOULD mandate use of binary or other transfer encoding option.

5.2.  Matching Rules

   Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and
   SUBSTRING) may be associated with an attribute type.  In addition,
   LDAP provides an extensible matching rule mechanism.

   The matching rule specification SHOULD detail which kind of matching
   rule it is and SHOULD describe which kinds of values it can be used
   with.

   In addition to requirements stated in the LDAP technical
   specification, equality matching rules SHOULD be commutative.



Zeilenga                 Best Current Practice                 [Page 11]

RFC 4521                    LDAP Extensions                    June 2006


5.3.  Attribute Types

   Designers SHOULD carefully consider how the structure of values is to
   be restricted.  Designers SHOULD consider that servers will only
   enforce constraints of the attribute's syntax.  That is, an attribute
   intended to hold URIs, but that has directoryString syntax, is not
   restricted to values that are URIs.

   Designers SHOULD carefully consider which matching rules, if any, are
   appropriate for the attribute type.  Matching rules specified for an
   attribute type MUST be compatible with the attribute type's syntax.

   Extensions specifying operational attributes MUST detail how servers
   are to maintain and/or utilize values of each operational attribute.

5.4.  Object Classes

   Designers SHOULD carefully consider whether each attribute of an
   object class is required ("MUST") or allowed ("MAY").

   Extensions specifying object classes that allow (or require)
   operational attributes MUST specify how servers are to maintain
   and/or utilize entries belonging to these object classes.

6.  Other Extension Mechanisms

6.1.  Attribute Description Options

   Each option is identified by a string of letters, numbers, and
   hyphens.  This string SHOULD be short.

6.2.  Authorization Identities

   Extensions interacting with authorization identities SHALL support
   the LDAP authzId format [RFC4513].  The authzId format is extensible.

6.3.  LDAP URL Extensions

   LDAP URL extensions are identified by a short string, a descriptor.
   Like other descriptors, the string SHOULD be short.

7.  Security Considerations

   LDAP does not place undue restrictions on the kinds of extensions
   that can be implemented.  While this document attempts to outline
   some specific issues that designers need to consider, it is not (and





Zeilenga                 Best Current Practice                 [Page 12]

RFC 4521                    LDAP Extensions                    June 2006


   cannot be) all encompassing.  Designers MUST do their own evaluations
   of the security considerations applicable to their extensions.

   Designers MUST NOT assume that the LDAP "core" technical
   specification [RFC4510] adequately addresses the specific concerns
   surrounding their extensions or assume that their extensions have no
   specific concerns.

   Extension specifications, however, SHOULD note whether security
   considerations specific to the feature they are extending, as well as
   general LDAP security considerations, apply to the extension.

8.  Acknowledgements

   The author thanks the IETF LDAP community for their thoughtful
   comments.

   This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce
   Greenblatt.

9.  References

9.1.  Normative References

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC2849]  Good, G., "The LDAP Data Interchange Format (LDIF) -
              Technical Specification", RFC 2849, June 2000.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3641]  Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
              Types", RFC 3641, October 2003.

   [RFC3642]  Legg, S., "Common Elements of Generic String Encoding
              Rules (GSER) Encodings", RFC 3642, October 2003.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.





Zeilenga                 Best Current Practice                 [Page 13]

RFC 4521                    LDAP Extensions                    June 2006


   [RFC3866]  Zeilenga, K., Ed., "Language Tags and Ranges in the
              Lightweight Directory Access Protocol (LDAP)", RFC 3866,
              July 2004.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

   [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
              (LDAP): Technical Specification Road Map", RFC 4510, June
              2006.

   [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
              Protocol (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): Directory Information Models", RFC 4512, June
              2006.

   [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
              (LDAP): Authentication Methods and Security Mechanisms",
              RFC 4513, June 2006.

   [RFC4515]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): String Representation of Search Filters",
              RFC 4515, June 2006.

   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
              2006.

   [RFC4517]  Legg, S., Ed., "Lightweight Directory Access Protocol
              (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.

   [RFC4518]  Zeilenga, K., "Lightweight Directory Access Protocol
              (LDAP): String Representation of Distinguished Names", RFC
              4518, June 2006.

   [RFC4520]  Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
              Considerations for the Lightweight Directory Access
              Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

   [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.







Zeilenga                 Best Current Practice                 [Page 14]

RFC 4521                    LDAP Extensions                    June 2006


   [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
              3.2.0" is defined by "The Unicode Standard, Version 3.0"
              (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
              as amended by the "Unicode Standard Annex #27: Unicode
              3.1" (http://www.unicode.org/reports/tr27/) and by the
              "Unicode Standard Annex #28: Unicode 3.2"
              (http://www.unicode.org/reports/tr28/).

   [FORMAL]   IESG, "Guidelines for the use of formal languages in IETF
              specifications",
              <http://www.ietf.org/IESG/STATEMENTS/pseudo-code-in-
              specs.txt>, 2001.

   [X.511]    International Telecommunication Union - Telecommunication
              Standardization Sector, "The Directory: Abstract Service
              Definition", X.511(1993) (also ISO/IEC 9594-3:1993).

   [X.680]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Abstract Syntax Notation One
              (ASN.1) - Specification of Basic Notation", X.680(2002)
              (also ISO/IEC 8824-1:2002).

   [X.690]    International Telecommunication Union - Telecommunication
              Standardization Sector, "Specification of ASN.1 encoding
              rules: Basic Encoding Rules (BER), Canonical Encoding
              Rules (CER), and Distinguished Encoding Rules (DER)",
              X.690(2002) (also ISO/IEC 8825-1:2002).

9.2.  Informative References

   [ACID]     Section 4 of ISO/IEC 10026-1:1992.

   [GUIDE]    Greenblatt, B., "LDAP Extension Style Guide", Work in
              Progress.

   [RFC3062]  Zeilenga, K., "LDAP Password Modify Extended Operation",
              RFC 3062, February 2001.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

Author's Address

   Kurt D. Zeilenga
   OpenLDAP Foundation

   EMail: [e-mail]




Zeilenga                 Best Current Practice                 [Page 15]

RFC 4521                    LDAP Extensions                    June 2006


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
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Zeilenga                 Best Current Practice                 [Page 16]