wafsamba: use additional xml catalog file (bug #9512)
[Samba/bb.git] / source4 / ldap_server / devdocs / rfc4520.txt
blob9ef5daadea6eac64b9db0557665b7f7a03e5117f
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 4520                           OpenLDAP Foundation
9 BCP: 64                                                        June 2006
10 Obsoletes: 3383
11 Category: Best Current Practice
14      Internet Assigned Numbers Authority (IANA) Considerations for
15             the Lightweight Directory Access Protocol (LDAP)
17 Status of This Memo
19    This document specifies an Internet Best Current Practices for the
20    Internet Community, and requests discussion and suggestions for
21    improvements.  Distribution of this memo is unlimited.
23 Copyright Notice
25    Copyright (C) The Internet Society (2006).
27 Abstract
29    This document provides procedures for registering extensible elements
30    of the Lightweight Directory Access Protocol (LDAP).  The document
31    also provides guidelines to the Internet Assigned Numbers Authority
32    (IANA) describing conditions under which new values can be assigned.
34 1.  Introduction
36    The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
37    extensible protocol.  LDAP supports:
39       -  the addition of new operations,
40       -  the extension of existing operations, and
41       -  the extensible schema.
43    This document details procedures for registering values used to
44    unambiguously identify extensible elements of the protocol, including
45    the following:
47       - LDAP message types
48       - LDAP extended operations and controls
49       - LDAP result codes
50       - LDAP authentication methods
51       - LDAP attribute description options
52       - Object Identifier descriptors
58 Zeilenga                 Best Current Practice                  [Page 1]
60 RFC 4520              IANA Considerations for LDAP             June 2006
63    These registries are maintained by the Internet Assigned Numbers
64    Authority (IANA).
66    In addition, this document provides guidelines to IANA describing the
67    conditions under which new values can be assigned.
69    This document replaces RFC 3383.
71 2.  Terminology and Conventions
73    This section details terms and conventions used in this document.
75 2.1.  Policy Terminology
77    The terms "IESG Approval", "Standards Action", "IETF Consensus",
78    "Specification Required", "First Come First Served", "Expert Review",
79    and "Private Use" are used as defined in BCP 26 [RFC2434].
81    The term "registration owner" (or "owner") refers to the party
82    authorized to change a value's registration.
84 2.2.  Requirement Terminology
86    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
87    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
88    document are to be interpreted as described in BCP 14 [RFC2119].  In
89    this case, "the specification", as used by BCP 14, refers to the
90    processing of protocols being submitted to the IETF standards
91    process.
93 2.3.  Common ABNF Productions
95    A number of syntaxes in this document are described using ABNF
96    [RFC4234].  These syntaxes rely on the following common productions:
98          ALPHA = %x41-5A / %x61-7A    ; "A"-"Z" / "a"-"z"
99          LDIGIT = %x31-39             ; "1"-"9"
100          DIGIT = %x30 / LDIGIT        ; "0"-"9"
101          HYPHEN = %x2D                ; "-"
102          DOT = %x2E                   ; "."
103          number = DIGIT / ( LDIGIT 1*DIGIT )
104          keychar = ALPHA / DIGIT / HYPHEN
105          leadkeychar = ALPHA
106          keystring = leadkeychar *keychar
107          keyword = keystring
109    Keywords are case insensitive.
114 Zeilenga                 Best Current Practice                  [Page 2]
116 RFC 4520              IANA Considerations for LDAP             June 2006
119 3.  IANA Considerations for LDAP
121    This section details each kind of protocol value that can be
122    registered and provides IANA guidelines on how to assign new values.
124    IANA may reject obviously bogus registrations.
126    LDAP values specified in RFCs MUST be registered.  Other LDAP values,
127    except those in private-use name spaces, SHOULD be registered.  RFCs
128    SHOULD NOT reference, use, or otherwise recognize unregistered LDAP
129    values.
131 3.1.  Object Identifiers
133    Numerous LDAP schema and protocol elements are identified by Object
134    Identifiers (OIDs) [X.680].  Specifications that assign OIDs to
135    elements SHOULD state who delegated the OIDs for their use.
137    For IETF-developed elements, specifications SHOULD use OIDs under
138    "Internet Directory Numbers" (1.3.6.1.1.x).  For elements developed
139    by others, any properly delegated OID can be used, including those
140    under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private
141    Enterprise Numbers" (1.3.6.1.4.1.x).
143    Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert
144    Review with Specification Required.  Only one OID per specification
145    will be assigned.  The specification MAY then assign any number of
146    OIDs within this arc without further coordination with IANA.
148    Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by
149    IANA <http://www.iana.org/cgi-bin/enterprise.pl>.  Practices for IANA
150    assignment of Internet Private Enterprise Numbers are detailed in RFC
151    2578 [RFC2578].
153    To avoid interoperability problems between early implementations of a
154    "work in progress" and implementations of the published specification
155    (e.g., the RFC), experimental OIDs SHOULD be used in "works in
156    progress" and early implementations.  OIDs under the Internet
157    Experimental OID arc (1.3.6.1.3.x) may be used for this purpose.
158    Practices for IANA assignment of these Internet Experimental numbers
159    are detailed in RFC 2578 [RFC2578].
161 3.2.  Protocol Mechanisms
163    LDAP provides a number of Root DSA-Specific Entry (DSE) attributes
164    for discovery of protocol mechanisms identified by OIDs, including
165    the supportedControl, supportedExtension, and supportedFeatures
166    attributes [RFC4512].
170 Zeilenga                 Best Current Practice                  [Page 3]
172 RFC 4520              IANA Considerations for LDAP             June 2006
175    A registry of OIDs used for discovery of protocol mechanisms is
176    provided to allow implementors and others to locate the technical
177    specification for these protocol mechanisms.  Future specifications
178    of additional Root DSE attributes holding values identifying protocol
179    mechanisms MAY extend this registry for their values.
181    Protocol mechanisms are registered on a First Come First Served
182    basis.
184 3.3.  LDAP Syntaxes
186    This registry provides a listing of LDAP syntaxes [RFC4512].  Each
187    LDAP syntax is identified by an OID.  This registry is provided to
188    allow implementors and others to locate the technical specification
189    describing a particular LDAP Syntax.
191    LDAP Syntaxes are registered on a First Come First Served with
192    Specification Required basis.
194    Note: Unlike object classes, attribute types, and various other kinds
195          of schema elements, descriptors are not used in LDAP to
196          identify LDAP Syntaxes.
198 3.4.  Object Identifier Descriptors
200    LDAP allows short descriptive names (or descriptors) to be used
201    instead of a numeric Object Identifier to identify select protocol
202    extensions [RFC4511], schema elements [RFC4512], LDAP URL [RFC4516]
203    extensions, and other objects.
205    Although the protocol allows the same descriptor to refer to
206    different object identifiers in certain cases and the registry
207    supports multiple registrations of the same descriptor (each
208    indicating a different kind of schema element and different object
209    identifier), multiple registrations of the same descriptor are to be
210    avoided.  All such multiple registration requests require Expert
211    Review.
213    Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
214    Unicode characters restricted by the following ABNF:
216       name = keystring
218    Descriptors are case insensitive.
220    Multiple names may be assigned to a given OID.  For purposes of
221    registration, an OID is to be represented in numeric OID form (e.g.,
222    1.1.0.23.40) conforming to the following ABNF:
226 Zeilenga                 Best Current Practice                  [Page 4]
228 RFC 4520              IANA Considerations for LDAP             June 2006
231       numericoid = number 1*( DOT number )
233    While the protocol places no maximum length restriction upon
234    descriptors, they should be short.  Descriptors longer than 48
235    characters may be viewed as too long to register.
237    A value ending with a hyphen ("-") reserves all descriptors that
238    start with that value.  For example, the registration of the option
239    "descrFamily-" reserves all options that start with "descrFamily-"
240    for some related purpose.
242    Descriptors beginning with "x-" are for Private Use and cannot be
243    registered.
245    Descriptors beginning with "e-" are reserved for experiments and will
246    be registered on a First Come First Served basis.
248    All other descriptors require Expert Review to be registered.
250    The registrant need not "own" the OID being named.
252    The OID name space is managed by the ISO/IEC Joint Technical
253    Committee 1 - Subcommittee 6.
255 3.5.  AttributeDescription Options
257    An AttributeDescription [RFC4512] can contain zero or more options
258    specifying additional semantics.  An option SHALL be restricted to a
259    string of UTF-8 encoded Unicode characters limited by the following
260    ABNF:
262       option = keystring
264    Options are case insensitive.
266    While the protocol places no maximum length restriction upon option
267    strings, they should be short.  Options longer than 24 characters may
268    be viewed as too long to register.
270    Values ending with a hyphen ("-") reserve all option names that start
271    with the name.  For example, the registration of the option
272    "optionFamily-" reserves all options that start with "optionFamily-"
273    for some related purpose.
275    Options beginning with "x-" are for Private Use and cannot be
276    registered.
282 Zeilenga                 Best Current Practice                  [Page 5]
284 RFC 4520              IANA Considerations for LDAP             June 2006
287    Options beginning with "e-" are reserved for experiments and will be
288    registered on a First Come First Served basis.
290    All other options require Standards Action or Expert Review with
291    Specification Required to be registered.
293 3.6.  LDAP Message Types
295    Each protocol message is encapsulated in an LDAPMessage envelope
296    [RFC4511.  The protocolOp CHOICE indicates the type of message
297    encapsulated.  Each message type consists of an ASN.1 identifier in
298    the form of a keyword and a non-negative choice number.  The choice
299    number is combined with the class (APPLICATION) and data type
300    (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's
301    encoding.  The choice numbers for existing protocol messages are
302    implicit in the protocol's ASN.1 defined in [RFC4511].
304    New values will be registered upon Standards Action.
306    Note: LDAP provides extensible messages that reduce but do not
307          eliminate the need to add new message types.
309 3.7.  LDAP Authentication Method
311    The LDAP Bind operation supports multiple authentication methods
312    [RFC4511].  Each authentication choice consists of an ASN.1
313    identifier in the form of a keyword and a non-negative integer.
315    The registrant SHALL classify the authentication method usage using
316    one of the following terms:
318          COMMON      - method is appropriate for common use on the
319                        Internet.
320          LIMITED USE - method is appropriate for limited use.
321          OBSOLETE    - method has been deprecated or otherwise found to
322                        be inappropriate for any use.
324    Methods without publicly available specifications SHALL NOT be
325    classified as COMMON.  New registrations of the class OBSOLETE cannot
326    be registered.
328    New authentication method integers in the range 0-1023 require
329    Standards Action to be registered.  New authentication method
330    integers in the range 1024-4095 require Expert Review with
331    Specification Required.  New authentication method integers in the
332    range 4096-16383 will be registered on a First Come First Served
333    basis.  Keywords associated with integers in the range 0-4095 SHALL
334    NOT start with "e-" or "x-".  Keywords associated with integers in
338 Zeilenga                 Best Current Practice                  [Page 6]
340 RFC 4520              IANA Considerations for LDAP             June 2006
343    the range 4096-16383 SHALL start with "e-".  Values greater than or
344    equal to 16384 and keywords starting with "x-" are for Private Use
345    and cannot be registered.
347    Note: LDAP supports Simple Authentication and Security Layers
348          [RFC4422] as an authentication choice.  SASL is an extensible
349          authentication framework.
351 3.8.  LDAP Result Codes
353    LDAP result messages carry a resultCode enumerated value to indicate
354    the outcome of the operation [RFC4511].  Each result code consists of
355    an ASN.1 identifier in the form of a keyword and a non-negative
356    integer.
358    New resultCodes integers in the range 0-1023 require Standards Action
359    to be registered.  New resultCode integers in the range 1024-4095
360    require Expert Review with Specification Required.  New resultCode
361    integers in the range 4096-16383 will be registered on a First Come
362    First Served basis.  Keywords associated with integers in the range
363    0-4095 SHALL NOT start with "e-" or "x-".  Keywords associated with
364    integers in the range 4096-16383 SHALL start with "e-".  Values
365    greater than or equal to 16384 and keywords starting with "x-" are
366    for Private Use and cannot be registered.
368 3.9.  LDAP Search Scope
370    LDAP SearchRequest messages carry a scope-enumerated value to
371    indicate the extent of search within the DIT [RFC4511].  Each search
372    value consists of an ASN.1 identifier in the form of a keyword and a
373    non-negative integer.
375    New scope integers in the range 0-1023 require Standards Action to be
376    registered.  New scope integers in the range 1024-4095 require Expert
377    Review with Specification Required.  New scope integers in the range
378    4096-16383 will be registered on a First Come First Served basis.
379    Keywords associated with integers in the range 0-4095 SHALL NOT start
380    with "e-" or "x-".  Keywords associated with integers in the range
381    4096-16383 SHALL start with "e-".  Values greater than or equal to
382    16384 and keywords starting with "x-" are for Private Use and cannot
383    be registered.
385 3.10.  LDAP Filter Choice
387    LDAP filters are used in making assertions against an object
388    represented in the directory [RFC4511].  The Filter CHOICE indicates
389    a type of assertion.  Each Filter CHOICE consists of an ASN.1
390    identifier in the form of a keyword and a non-negative choice number.
394 Zeilenga                 Best Current Practice                  [Page 7]
396 RFC 4520              IANA Considerations for LDAP             June 2006
399    The choice number is combined with the class (APPLICATION) and data
400    type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the
401    message's encoding.
403    Note: LDAP provides the extensibleMatching choice, which reduces but
404          does not eliminate the need to add new filter choices.
406 3.11.  LDAP ModifyRequest Operation Type
408    The LDAP ModifyRequest carries a sequence of modification operations
409    [RFC4511].  Each kind (e.g., add, delete, replace) of operation
410    consists of an ASN.1 identifier in the form of a keyword and a non-
411    negative integer.
413    New operation type integers in the range 0-1023 require Standards
414    Action to be registered.  New operation type integers in the range
415    1024-4095 require Expert Review with Specification Required.  New
416    operation type integers in the range 4096-16383 will be registered on
417    a First Come First Served basis.  Keywords associated with integers
418    in the range 0-4095 SHALL NOT start with "e-" or "x-".  Keywords
419    associated with integers in the range 4096-16383 SHALL start with
420    "e-".  Values greater than or equal to 16384 and keywords starting
421    with "x-" are for Private Use and cannot be registered.
423 3.12.  LDAP authzId Prefixes
425    Authorization Identities in LDAP are strings conforming to the
426    <authzId> production [RFC4513].  This production is extensible.  Each
427    new specific authorization form is identified by a prefix string
428    conforming to the following ABNF:
430          prefix = keystring COLON
431          COLON = %x3A ; COLON (":" U+003A)
433    Prefixes are case insensitive.
435    While the protocol places no maximum length restriction upon prefix
436    strings, they should be short.  Prefixes longer than 12 characters
437    may be viewed as too long to register.
439    Prefixes beginning with "x-" are for Private Use and cannot be
440    registered.
442    Prefixes beginning with "e-" are reserved for experiments and will be
443    registered on a First Come First Served basis.
445    All other prefixes require Standards Action or Expert Review with
446    Specification Required to be registered.
450 Zeilenga                 Best Current Practice                  [Page 8]
452 RFC 4520              IANA Considerations for LDAP             June 2006
455 3.13.  Directory Systems Names
457    The IANA-maintained "Directory Systems Names" registry [IANADSN] of
458    valid keywords for well-known attributes was used in the LDAPv2
459    string representation of a distinguished name [RFC1779].  LDAPv2 is
460    now Historic [RFC3494].
462    Directory systems names are not known to be used in any other
463    context.  LDAPv3 [RFC4514] uses Object Identifier Descriptors
464    [Section 3.2] (which have a different syntax than directory system
465    names).
467    New Directory System Names will no longer be accepted.  For
468    historical purposes, the current list of registered names should
469    remain publicly available.
471 4.  Registration Procedure
473    The procedure given here MUST be used by anyone who wishes to use a
474    new value of a type described in Section 3 of this document.
476    The first step is for the requester to fill out the appropriate form.
477    Templates are provided in Appendix A.
479    If the policy is Standards Action, the completed form SHOULD be
480    provided to the IESG with the request for Standards Action.  Upon
481    approval of the Standards Action, the IESG SHALL forward the request
482    (possibly revised) to IANA.  The IESG SHALL be regarded as the
483    registration owner of all values requiring Standards Action.
485    If the policy is Expert Review, the requester SHALL post the
486    completed form to the <directory@apps.ietf.org> mailing list for
487    public review.  The review period is two (2) weeks.  If a revised
488    form is later submitted, the review period is restarted.  Anyone may
489    subscribe to this list by sending a request to <directory-
490    request@apps.ietf.org>.  During the review, objections may be raised
491    by anyone (including the Expert) on the list.  After completion of
492    the review, the Expert, based on public comments, SHALL either
493    approve the request and forward it to the IANA OR deny the request.
494    In either case, the Expert SHALL promptly notify the requester of the
495    action.  Actions of the Expert may be appealed [RFC2026].  The Expert
496    is appointed by Applications Area Directors.  The requester is viewed
497    as the registration owner of values registered under Expert Review.
499    If the policy is First Come First Served, the requester SHALL submit
500    the completed form directly to the IANA: <iana@iana.org>.  The
501    requester is viewed as the registration owner of values registered
502    under First Come First Served.
506 Zeilenga                 Best Current Practice                  [Page 9]
508 RFC 4520              IANA Considerations for LDAP             June 2006
511    Neither the Expert nor IANA will take position on the claims of
512    copyright or trademark issues regarding completed forms.
514    Prior to submission of the Internet Draft (I-D) to the RFC Editor but
515    after IESG review and tentative approval, the document editor SHOULD
516    revise the I-D to use registered values.
518 5.  Registration Maintenance
520    This section discusses maintenance of registrations.
522 5.1.  Lists of Registered Values
524    IANA makes lists of registered values readily available to the
525    Internet community on its web site: <http://www.iana.org/>.
527 5.2.  Change Control
529    The registration owner MAY update the registration subject to the
530    same constraints and review as with new registrations.  In cases
531    where the registration owner is unable or is unwilling to make
532    necessary updates, the IESG MAY assume ownership of the registration
533    in order to update the registration.
535 5.3.  Comments
537    For cases where others (anyone other than the registration owner)
538    have significant objections to the claims in a registration and the
539    registration owner does not agree to change the registration,
540    comments MAY be attached to a registration upon Expert Review.  For
541    registrations owned by the IESG, the objections SHOULD be addressed
542    by initiating a request for Expert Review.
544    The form of these requests is ad hoc, but MUST include the specific
545    objections to be reviewed and SHOULD contain (directly or by
546    reference) materials supporting the objections.
548 6.  Security Considerations
550    The security considerations detailed in BCP 26 [RFC2434] are
551    generally applicable to this document.  Additional security
552    considerations specific to each name space are discussed in Section
553    3, where appropriate.
555    Security considerations for LDAP are discussed in documents
556    comprising the technical specification [RFC4510].
562 Zeilenga                 Best Current Practice                 [Page 10]
564 RFC 4520              IANA Considerations for LDAP             June 2006
567 7.  Acknowledgement
569    This document is a product of the IETF LDAP Revision (LDAPBIS)
570    Working Group (WG).  This document is a revision of RFC 3383, also a
571    product of the LDAPBIS WG.
573    This document includes text borrowed from "Guidelines for Writing an
574    IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and
575    Harald Alvestrand.
577 8.  References
579 8.1.  Normative References
581    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
582               3", BCP 9, RFC 2026, October 1996.
584    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
585               Requirement Levels", BCP 14, RFC 2119, March 1997.
587    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
588               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
589               October 1998.
591    [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
592               "Structure of Management Information Version 2 (SMIv2)",
593               STD 58, RFC 2578, April 1999.
595    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
596               10646", STD 63, RFC 3629, November 2003.
598    [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
599               Specifications: ABNF", RFC 4234, October 2005.
601    [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
602               (LDAP): Technical Specification Road Map", RFC 4510, June
603               2006.
605    [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
606               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
608    [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
609               (LDAP): Directory Information Models", RFC 4512, June
610               2006.
612    [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
613               (LDAP): Authentication Methods and Security Mechanisms",
614               RFC 4513, June 2006.
618 Zeilenga                 Best Current Practice                 [Page 11]
620 RFC 4520              IANA Considerations for LDAP             June 2006
623    [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
624               Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
625               2006.
627    [Unicode]  The Unicode Consortium, "The Unicode Standard, Version
628               3.2.0" is defined by "The Unicode Standard, Version 3.0"
629               (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
630               as amended by the "Unicode Standard Annex #27: Unicode
631               3.1" (http://www.unicode.org/reports/tr27/) and by the
632               "Unicode Standard Annex #28: Unicode 3.2"
633               (http://www.unicode.org/reports/tr28/).
635    [X.680]    International Telecommunication Union - Telecommunication
636               Standardization Sector, "Abstract Syntax Notation One
637               (ASN.1) - Specification of Basic Notation", X.680(2002)
638               (also ISO/IEC 8824-1:2002).
640 8.2.  Informative References
642    [RFC1779]  Kille, S., "A String Representation of Distinguished
643               Names", RFC 1779, March 1995.
645    [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
646               version 2 (LDAPv2) to Historic Status", RFC 3494, March
647               2003.
649    [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
650               (LDAP): String Representation of Distinguished Names", RFC
651               4514, June 2006.
653    [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
654               Authentication and Security Layer (SASL)", RFC 4422, June
655               2006.
657    [IANADSN]  IANA, "Directory Systems Names",
658               http://www.iana.org/assignments/directory-system-names.
674 Zeilenga                 Best Current Practice                 [Page 12]
676 RFC 4520              IANA Considerations for LDAP             June 2006
679 Appendix A.  Registration Templates
681    This appendix provides registration templates for registering new
682    LDAP values.  Note that more than one value may be requested by
683    extending the template by listing multiple values, or through use of
684    tables.
686 A.1.  LDAP Object Identifier Registration Template
688    Subject: Request for LDAP OID Registration
690    Person & email address to contact for further information:
692    Specification: (I-D)
694    Author/Change Controller:
696    Comments:
698    (Any comments that the requester deems relevant to the request.)
700 A.2.  LDAP Protocol Mechanism Registration Template
702    Subject: Request for LDAP Protocol Mechanism Registration
704    Object Identifier:
706    Description:
708    Person & email address to contact for further information:
710    Usage: (One of Control or Extension or Feature or other)
712    Specification: (RFC, I-D, URI)
714    Author/Change Controller:
716    Comments:
718    (Any comments that the requester deems relevant to the request.)
730 Zeilenga                 Best Current Practice                 [Page 13]
732 RFC 4520              IANA Considerations for LDAP             June 2006
735 A.3.  LDAP Syntax Registration Template
737    Subject: Request for LDAP Syntax Registration
739    Object Identifier:
741    Description:
743    Person & email address to contact for further information:
745    Specification: (RFC, I-D, URI)
747    Author/Change Controller:
749    Comments:
751    (Any comments that the requester deems relevant to the request.)
753 A.4.  LDAP Descriptor Registration Template
755    Subject: Request for LDAP Descriptor Registration
757    Descriptor (short name):
759    Object Identifier:
761    Person & email address to contact for further information:
763    Usage: (One of administrative role, attribute type, matching rule,
764      name form, object class, URL extension, or other)
766    Specification: (RFC, I-D, URI)
768    Author/Change Controller:
770    Comments:
772    (Any comments that the requester deems relevant to the request.)
786 Zeilenga                 Best Current Practice                 [Page 14]
788 RFC 4520              IANA Considerations for LDAP             June 2006
791 A.5.  LDAP Attribute Description Option Registration Template
793    Subject: Request for LDAP Attribute Description Option Registration
794    Option Name:
796    Family of Options: (YES or NO)
798    Person & email address to contact for further information:
800    Specification: (RFC, I-D, URI)
802    Author/Change Controller:
804    Comments:
806    (Any comments that the requester deems relevant to the request.)
808 A.6.  LDAP Message Type Registration Template
810    Subject: Request for LDAP Message Type Registration
812    LDAP Message Name:
814    Person & email address to contact for further information:
816    Specification: (Approved I-D)
818    Comments:
820    (Any comments that the requester deems relevant to the request.)
822 A.7.  LDAP Authentication Method Registration Template
824    Subject: Request for LDAP Authentication Method Registration
826    Authentication Method Name:
828    Person & email address to contact for further information:
830    Specification: (RFC, I-D, URI)
832    Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
834    Author/Change Controller:
836    Comments:
838    (Any comments that the requester deems relevant to the request.)
842 Zeilenga                 Best Current Practice                 [Page 15]
844 RFC 4520              IANA Considerations for LDAP             June 2006
847 A.8.  LDAP Result Code Registration Template
849    Subject: Request for LDAP Result Code Registration
851    Result Code Name:
853    Person & email address to contact for further information:
855    Specification: (RFC, I-D, URI)
857    Author/Change Controller:
859    Comments:
861    (Any comments that the requester deems relevant to the request.)
863 A.8.  LDAP Search Scope Registration Template
865    Subject: Request for LDAP Search Scope Registration
867    Search Scope Name:
869    Filter Scope String:
871    Person & email address to contact for further information:
873    Specification: (RFC, I-D, URI)
875    Author/Change Controller:
877    Comments:
879    (Any comments that the requester deems relevant to the request.)
898 Zeilenga                 Best Current Practice                 [Page 16]
900 RFC 4520              IANA Considerations for LDAP             June 2006
903 A.9.  LDAP Filter Choice Registration Template
905    Subject: Request for LDAP Filter Choice Registration
907    Filter Choice Name:
909    Person & email address to contact for further information:
911    Specification: (RFC, I-D, URI)
913    Author/Change Controller:
915    Comments:
917    (Any comments that the requester deems relevant to the request.)
919 A.10.  LDAP ModifyRequest Operation Registration Template
921    Subject: Request for LDAP ModifyRequest Operation Registration
923    ModifyRequest Operation Name:
925    Person & email address to contact for further information:
927    Specification: (RFC, I-D, URI)
929    Author/Change Controller:
931    Comments:
933    (Any comments that the requester deems relevant to the request.)
935 Appendix B.  Changes since RFC 3383
937    This informative appendix provides a summary of changes made since
938    RFC 3383.
940       -  Object Identifier Descriptors practices were updated to require
941          all descriptors defined in RFCs to be registered and
942          recommending all other descriptors (excepting those in
943          private-use name space) be registered.  Additionally, all
944          requests for multiple registrations of the same descriptor are
945          now subject to Expert Review.
947       -  Protocol Mechanisms practices were updated to include values of
948          the 'supportedFeatures' attribute type.
954 Zeilenga                 Best Current Practice                 [Page 17]
956 RFC 4520              IANA Considerations for LDAP             June 2006
959       -  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
960          operation, and authzId prefixes registries were added.
962       -  References to RFCs comprising the LDAP technical specifications
963          have been updated to latest revisions.
965       -  References to ISO 10646 have been replaced with [Unicode].
967       -  The "Assigned Values" appendix providing initial registry
968          values was removed.
970       -  Numerous editorial changes were made.
972 Author's Address
974    Kurt D. Zeilenga
975    OpenLDAP Foundation
977    EMail: Kurt@OpenLDAP.org
1010 Zeilenga                 Best Current Practice                 [Page 18]
1012 RFC 4520              IANA Considerations for LDAP             June 2006
1015 Full Copyright Statement
1017    Copyright (C) The Internet Society (2006).
1019    This document is subject to the rights, licenses and restrictions
1020    contained in BCP 78, and except as set forth therein, the authors
1021    retain all their rights.
1023    This document and the information contained herein are provided on an
1024    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1025    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1026    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1027    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1028    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1029    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1031 Intellectual Property
1033    The IETF takes no position regarding the validity or scope of any
1034    Intellectual Property Rights or other rights that might be claimed to
1035    pertain to the implementation or use of the technology described in
1036    this document or the extent to which any license under such rights
1037    might or might not be available; nor does it represent that it has
1038    made any independent effort to identify any such rights.  Information
1039    on the procedures with respect to rights in RFC documents can be
1040    found in BCP 78 and BCP 79.
1042    Copies of IPR disclosures made to the IETF Secretariat and any
1043    assurances of licenses to be made available, or the result of an
1044    attempt made to obtain a general license or permission for the use of
1045    such proprietary rights by implementers or users of this
1046    specification can be obtained from the IETF on-line IPR repository at
1047    http://www.ietf.org/ipr.
1049    The IETF invites any interested party to bring to its attention any
1050    copyrights, patents or patent applications, or other proprietary
1051    rights that may cover technology that may be required to implement
1052    this standard.  Please address the information to the IETF at
1053    ietf-ipr@ietf.org.
1055 Acknowledgement
1057    Funding for the RFC Editor function is provided by the IETF
1058    Administrative Support Activity (IASA).
1066 Zeilenga                 Best Current Practice                 [Page 19]