rfc4520.txt

samba最新软件

   New resultCodes integers in the range 0-1023 require Standards Action
   to be registered.  New resultCode integers in the range 1024-4095
   require Expert Review with Specification Required.  New resultCode
   integers in the range 4096-16383 will be registered on a First Come
   First Served basis.  Keywords associated with integers in the range
   0-4095 SHALL NOT start with "e-" or "x-".  Keywords associated with
   integers in the range 4096-16383 SHALL start with "e-".  Values
   greater than or equal to 16384 and keywords starting with "x-" are
   for Private Use and cannot be registered.

3.9.  LDAP Search Scope

   LDAP SearchRequest messages carry a scope-enumerated value to
   indicate the extent of search within the DIT [RFC4511].  Each search
   value consists of an ASN.1 identifier in the form of a keyword and a
   non-negative integer.

   New scope integers in the range 0-1023 require Standards Action to be
   registered.  New scope integers in the range 1024-4095 require Expert
   Review with Specification Required.  New scope integers in the range
   4096-16383 will be registered on a First Come First Served basis.
   Keywords associated with integers in the range 0-4095 SHALL NOT start
   with "e-" or "x-".  Keywords associated with integers in the range
   4096-16383 SHALL start with "e-".  Values greater than or equal to
   16384 and keywords starting with "x-" are for Private Use and cannot
   be registered.

3.10.  LDAP Filter Choice

   LDAP filters are used in making assertions against an object
   represented in the directory [RFC4511].  The Filter CHOICE indicates
   a type of assertion.  Each Filter CHOICE consists of an ASN.1
   identifier in the form of a keyword and a non-negative choice number.



Zeilenga                 Best Current Practice                  [Page 7]

RFC 4520              IANA Considerations for LDAP             June 2006


   The choice number is combined with the class (APPLICATION) and data
   type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
   message's encoding.

   Note: LDAP provides the extensibleMatching choice, which reduces but
         does not eliminate the need to add new filter choices.

3.11.  LDAP ModifyRequest Operation Type

   The LDAP ModifyRequest carries a sequence of modification operations
   [RFC4511].  Each kind (e.g., add, delete, replace) of operation
   consists of an ASN.1 identifier in the form of a keyword and a non-
   negative integer.

   New operation type integers in the range 0-1023 require Standards
   Action to be registered.  New operation type integers in the range
   1024-4095 require Expert Review with Specification Required.  New
   operation type integers in the range 4096-16383 will be registered on
   a First Come First Served basis.  Keywords associated with integers
   in the range 0-4095 SHALL NOT start with "e-" or "x-".  Keywords
   associated with integers in the range 4096-16383 SHALL start with
   "e-".  Values greater than or equal to 16384 and keywords starting
   with "x-" are for Private Use and cannot be registered.

3.12.  LDAP authzId Prefixes

   Authorization Identities in LDAP are strings conforming to the
   <authzId> production [RFC4513].  This production is extensible.  Each
   new specific authorization form is identified by a prefix string
   conforming to the following ABNF:

         prefix = keystring COLON
         COLON = %x3A ; COLON (":" U+003A)

   Prefixes are case insensitive.

   While the protocol places no maximum length restriction upon prefix
   strings, they should be short.  Prefixes longer than 12 characters
   may be viewed as too long to register.

   Prefixes beginning with "x-" are for Private Use and cannot be
   registered.

   Prefixes beginning with "e-" are reserved for experiments and will be
   registered on a First Come First Served basis.

   All other prefixes require Standards Action or Expert Review with
   Specification Required to be registered.



Zeilenga                 Best Current Practice                  [Page 8]

RFC 4520              IANA Considerations for LDAP             June 2006


3.13.  Directory Systems Names

   The IANA-maintained "Directory Systems Names" registry [IANADSN] of
   valid keywords for well-known attributes was used in the LDAPv2
   string representation of a distinguished name [RFC1779].  LDAPv2 is
   now Historic [RFC3494].

   Directory systems names are not known to be used in any other
   context.  LDAPv3 [RFC4514] uses Object Identifier Descriptors
   [Section 3.2] (which have a different syntax than directory system
   names).

   New Directory System Names will no longer be accepted.  For
   historical purposes, the current list of registered names should
   remain publicly available.

4.  Registration Procedure

   The procedure given here MUST be used by anyone who wishes to use a
   new value of a type described in Section 3 of this document.

   The first step is for the requester to fill out the appropriate form.
   Templates are provided in Appendix A.

   If the policy is Standards Action, the completed form SHOULD be
   provided to the IESG with the request for Standards Action.  Upon
   approval of the Standards Action, the IESG SHALL forward the request
   (possibly revised) to IANA.  The IESG SHALL be regarded as the
   registration owner of all values requiring Standards Action.

   If the policy is Expert Review, the requester SHALL post the
   completed form to the <[e-mail]> mailing list for
   public review.  The review period is two (2) weeks.  If a revised
   form is later submitted, the review period is restarted.  Anyone may
   subscribe to this list by sending a request to <directory-
   [e-mail]>.  During the review, objections may be raised
   by anyone (including the Expert) on the list.  After completion of
   the review, the Expert, based on public comments, SHALL either
   approve the request and forward it to the IANA OR deny the request.
   In either case, the Expert SHALL promptly notify the requester of the
   action.  Actions of the Expert may be appealed [RFC2026].  The Expert
   is appointed by Applications Area Directors.  The requester is viewed
   as the registration owner of values registered under Expert Review.

   If the policy is First Come First Served, the requester SHALL submit
   the completed form directly to the IANA: <[e-mail]>.  The
   requester is viewed as the registration owner of values registered
   under First Come First Served.



Zeilenga                 Best Current Practice                  [Page 9]

RFC 4520              IANA Considerations for LDAP             June 2006


   Neither the Expert nor IANA will take position on the claims of
   copyright or trademark issues regarding completed forms.

   Prior to submission of the Internet Draft (I-D) to the RFC Editor but
   after IESG review and tentative approval, the document editor SHOULD
   revise the I-D to use registered values.

5.  Registration Maintenance

   This section discusses maintenance of registrations.

5.1.  Lists of Registered Values

   IANA makes lists of registered values readily available to the
   Internet community on its web site: <http://www.iana.org/>.

5.2.  Change Control

   The registration owner MAY update the registration subject to the
   same constraints and review as with new registrations.  In cases
   where the registration owner is unable or is unwilling to make
   necessary updates, the IESG MAY assume ownership of the registration
   in order to update the registration.

5.3.  Comments

   For cases where others (anyone other than the registration owner)
   have significant objections to the claims in a registration and the
   registration owner does not agree to change the registration,
   comments MAY be attached to a registration upon Expert Review.  For
   registrations owned by the IESG, the objections SHOULD be addressed
   by initiating a request for Expert Review.

   The form of these requests is ad hoc, but MUST include the specific
   objections to be reviewed and SHOULD contain (directly or by
   reference) materials supporting the objections.

6.  Security Considerations

   The security considerations detailed in BCP 26 [RFC2434] are
   generally applicable to this document.  Additional security
   considerations specific to each name space are discussed in Section
   3, where appropriate.

   Security considerations for LDAP are discussed in documents
   comprising the technical specification [RFC4510].





Zeilenga                 Best Current Practice                 [Page 10]

RFC 4520              IANA Considerations for LDAP             June 2006


7.  Acknowledgement

   This document is a product of the IETF LDAP Revision (LDAPBIS)
   Working Group (WG).  This document is a revision of RFC 3383, also a
   product of the LDAPBIS WG.

   This document includes text borrowed from "Guidelines for Writing an
   IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
   Harald Alvestrand.

8.  References

8.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [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.

   [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Structure of Management Information Version 2 (SMIv2)",
              STD 58, RFC 2578, April 1999.

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

   [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.



Zeilenga                 Best Current Practice                 [Page 11]

RFC 4520              IANA Considerations for LDAP             June 2006


   [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
              Protocol (LDAP): Uniform Resource Locator", RFC 4516, 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/).

   [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).

8.2.  Informative References

   [RFC1779]  Kille, S., "A String Representation of Distinguished
              Names", RFC 1779, March 1995.

   [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
              version 2 (LDAPv2) to Historic Status", RFC 3494, March
              2003.

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

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

   [IANADSN]  IANA, "Directory Systems Names",
              http://www.iana.org/assignments/directory-system-names.















Zeilenga                 Best Current Practice                 [Page 12]

RFC 4520              IANA Considerations for LDAP             June 2006


Appendix A.  Registration Templates

   This appendix provides registration templates for registering new
   LDAP values.  Note that more than one value may be requested by
   extending the template by listing multiple values, or through use of
   tables.

A.1.  LDAP Object Identifier Registration Template

   Subject: Request for LDAP OID Registration

   Person & email address to contact for further information:

   Specification: (I-D)

   Author/Change Controller:

   Comments:

   (Any comments that the requester deems relevant to the request.)

A.2.  LDAP Protocol Mechanism Registration Template

   Subject: Request for LDAP Protocol Mechanism Registration

   Object Identifier:

   Description:

   Person & email address to contact for further information:

   Usage: (One of Control or Extension or Feature or other)

   Specification: (RFC, I-D, URI)