]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc4520.txt
Fix prev commit
[openldap] / doc / rfc / rfc4520.txt
1
2
3
4
5
6
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
12
13
14      Internet Assigned Numbers Authority (IANA) Considerations for
15             the Lightweight Directory Access Protocol (LDAP)
16
17 Status of This Memo
18
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.
22
23 Copyright Notice
24
25    Copyright (C) The Internet Society (2006).
26
27 Abstract
28
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.
33
34 1.  Introduction
35
36    The Lightweight Directory Access Protocol [RFC4510] (LDAP) is an
37    extensible protocol.  LDAP supports:
38
39       -  the addition of new operations,
40       -  the extension of existing operations, and
41       -  the extensible schema.
42
43    This document details procedures for registering values used to
44    unambiguously identify extensible elements of the protocol, including
45    the following:
46
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
53
54
55
56
57
58 Zeilenga                 Best Current Practice                  [Page 1]
59 \f
60 RFC 4520              IANA Considerations for LDAP             June 2006
61
62
63    These registries are maintained by the Internet Assigned Numbers
64    Authority (IANA).
65
66    In addition, this document provides guidelines to IANA describing the
67    conditions under which new values can be assigned.
68
69    This document replaces RFC 3383.
70
71 2.  Terminology and Conventions
72
73    This section details terms and conventions used in this document.
74
75 2.1.  Policy Terminology
76
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].
80
81    The term "registration owner" (or "owner") refers to the party
82    authorized to change a value's registration.
83
84 2.2.  Requirement Terminology
85
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.
92
93 2.3.  Common ABNF Productions
94
95    A number of syntaxes in this document are described using ABNF
96    [RFC4234].  These syntaxes rely on the following common productions:
97
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
108
109    Keywords are case insensitive.
110
111
112
113
114 Zeilenga                 Best Current Practice                  [Page 2]
115 \f
116 RFC 4520              IANA Considerations for LDAP             June 2006
117
118
119 3.  IANA Considerations for LDAP
120
121    This section details each kind of protocol value that can be
122    registered and provides IANA guidelines on how to assign new values.
123
124    IANA may reject obviously bogus registrations.
125
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.
130
131 3.1.  Object Identifiers
132
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.
136
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).
142
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.
147
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].
152
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].
160
161 3.2.  Protocol Mechanisms
162
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].
167
168
169
170 Zeilenga                 Best Current Practice                  [Page 3]
171 \f
172 RFC 4520              IANA Considerations for LDAP             June 2006
173
174
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.
180
181    Protocol mechanisms are registered on a First Come First Served
182    basis.
183
184 3.3.  LDAP Syntaxes
185
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.
190
191    LDAP Syntaxes are registered on a First Come First Served with
192    Specification Required basis.
193
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.
197
198 3.4.  Object Identifier Descriptors
199
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.
204
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.
212
213    Descriptors are restricted to strings of UTF-8 [RFC3629] encoded
214    Unicode characters restricted by the following ABNF:
215
216       name = keystring
217
218    Descriptors are case insensitive.
219
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:
223
224
225
226 Zeilenga                 Best Current Practice                  [Page 4]
227 \f
228 RFC 4520              IANA Considerations for LDAP             June 2006
229
230
231       numericoid = number 1*( DOT number )
232
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.
236
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.
241
242    Descriptors beginning with "x-" are for Private Use and cannot be
243    registered.
244
245    Descriptors beginning with "e-" are reserved for experiments and will
246    be registered on a First Come First Served basis.
247
248    All other descriptors require Expert Review to be registered.
249
250    The registrant need not "own" the OID being named.
251
252    The OID name space is managed by the ISO/IEC Joint Technical
253    Committee 1 - Subcommittee 6.
254
255 3.5.  AttributeDescription Options
256
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:
261
262       option = keystring
263
264    Options are case insensitive.
265
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.
269
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.
274
275    Options beginning with "x-" are for Private Use and cannot be
276    registered.
277
278
279
280
281
282 Zeilenga                 Best Current Practice                  [Page 5]
283 \f
284 RFC 4520              IANA Considerations for LDAP             June 2006
285
286
287    Options beginning with "e-" are reserved for experiments and will be
288    registered on a First Come First Served basis.
289
290    All other options require Standards Action or Expert Review with
291    Specification Required to be registered.
292
293 3.6.  LDAP Message Types
294
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].
303
304    New values will be registered upon Standards Action.
305
306    Note: LDAP provides extensible messages that reduce but do not
307          eliminate the need to add new message types.
308
309 3.7.  LDAP Authentication Method
310
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.
314
315    The registrant SHALL classify the authentication method usage using
316    one of the following terms:
317
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.
323
324    Methods without publicly available specifications SHALL NOT be
325    classified as COMMON.  New registrations of the class OBSOLETE cannot
326    be registered.
327
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
335
336
337
338 Zeilenga                 Best Current Practice                  [Page 6]
339 \f
340 RFC 4520              IANA Considerations for LDAP             June 2006
341
342
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.
346
347    Note: LDAP supports Simple Authentication and Security Layers
348          [RFC4422] as an authentication choice.  SASL is an extensible
349          authentication framework.
350
351 3.8.  LDAP Result Codes
352
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.
357
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.
367
368 3.9.  LDAP Search Scope
369
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.
374
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.
384
385 3.10.  LDAP Filter Choice
386
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.
391
392
393
394 Zeilenga                 Best Current Practice                  [Page 7]
395 \f
396 RFC 4520              IANA Considerations for LDAP             June 2006
397
398
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.
402
403    Note: LDAP provides the extensibleMatching choice, which reduces but
404          does not eliminate the need to add new filter choices.
405
406 3.11.  LDAP ModifyRequest Operation Type
407
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.
412
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.
422
423 3.12.  LDAP authzId Prefixes
424
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:
429
430          prefix = keystring COLON
431          COLON = %x3A ; COLON (":" U+003A)
432
433    Prefixes are case insensitive.
434
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.
438
439    Prefixes beginning with "x-" are for Private Use and cannot be
440    registered.
441
442    Prefixes beginning with "e-" are reserved for experiments and will be
443    registered on a First Come First Served basis.
444
445    All other prefixes require Standards Action or Expert Review with
446    Specification Required to be registered.
447
448
449
450 Zeilenga                 Best Current Practice                  [Page 8]
451 \f
452 RFC 4520              IANA Considerations for LDAP             June 2006
453
454
455 3.13.  Directory Systems Names
456
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].
461
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).
466
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.
470
471 4.  Registration Procedure
472
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.
475
476    The first step is for the requester to fill out the appropriate form.
477    Templates are provided in Appendix A.
478
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.
484
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.
498
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.
503
504
505
506 Zeilenga                 Best Current Practice                  [Page 9]
507 \f
508 RFC 4520              IANA Considerations for LDAP             June 2006
509
510
511    Neither the Expert nor IANA will take position on the claims of
512    copyright or trademark issues regarding completed forms.
513
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.
517
518 5.  Registration Maintenance
519
520    This section discusses maintenance of registrations.
521
522 5.1.  Lists of Registered Values
523
524    IANA makes lists of registered values readily available to the
525    Internet community on its web site: <http://www.iana.org/>.
526
527 5.2.  Change Control
528
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.
534
535 5.3.  Comments
536
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.
543
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.
547
548 6.  Security Considerations
549
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.
554
555    Security considerations for LDAP are discussed in documents
556    comprising the technical specification [RFC4510].
557
558
559
560
561
562 Zeilenga                 Best Current Practice                 [Page 10]
563 \f
564 RFC 4520              IANA Considerations for LDAP             June 2006
565
566
567 7.  Acknowledgement
568
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.
572
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.
576
577 8.  References
578
579 8.1.  Normative References
580
581    [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
582               3", BCP 9, RFC 2026, October 1996.
583
584    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
585               Requirement Levels", BCP 14, RFC 2119, March 1997.
586
587    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
588               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
589               October 1998.
590
591    [RFC2578]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
592               "Structure of Management Information Version 2 (SMIv2)",
593               STD 58, RFC 2578, April 1999.
594
595    [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
596               10646", STD 63, RFC 3629, November 2003.
597
598    [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
599               Specifications: ABNF", RFC 4234, October 2005.
600
601    [RFC4510]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
602               (LDAP): Technical Specification Road Map", RFC 4510, June
603               2006.
604
605    [RFC4511]  Sermersheim, J., Ed., "Lightweight Directory Access
606               Protocol (LDAP): The Protocol", RFC 4511, June 2006.
607
608    [RFC4512]  Zeilenga, K., "Lightweight Directory Access Protocol
609               (LDAP): Directory Information Models", RFC 4512, June
610               2006.
611
612    [RFC4513]  Harrison, R., Ed., "Lightweight Directory Access Protocol
613               (LDAP): Authentication Methods and Security Mechanisms",
614               RFC 4513, June 2006.
615
616
617
618 Zeilenga                 Best Current Practice                 [Page 11]
619 \f
620 RFC 4520              IANA Considerations for LDAP             June 2006
621
622
623    [RFC4516]  Smith, M., Ed. and T. Howes, "Lightweight Directory Access
624               Protocol (LDAP): Uniform Resource Locator", RFC 4516, June
625               2006.
626
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/).
634
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).
639
640 8.2.  Informative References
641
642    [RFC1779]  Kille, S., "A String Representation of Distinguished
643               Names", RFC 1779, March 1995.
644
645    [RFC3494]  Zeilenga, K.,"Lightweight Directory Access Protocol
646               version 2 (LDAPv2) to Historic Status", RFC 3494, March
647               2003.
648
649    [RFC4514]  Zeilenga, K., Ed., "Lightweight Directory Access Protocol
650               (LDAP): String Representation of Distinguished Names", RFC
651               4514, June 2006.
652
653    [RFC4422]  Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
654               Authentication and Security Layer (SASL)", RFC 4422, June
655               2006.
656
657    [IANADSN]  IANA, "Directory Systems Names",
658               http://www.iana.org/assignments/directory-system-names.
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674 Zeilenga                 Best Current Practice                 [Page 12]
675 \f
676 RFC 4520              IANA Considerations for LDAP             June 2006
677
678
679 Appendix A.  Registration Templates
680
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.
685
686 A.1.  LDAP Object Identifier Registration Template
687
688    Subject: Request for LDAP OID Registration
689
690    Person & email address to contact for further information:
691
692    Specification: (I-D)
693
694    Author/Change Controller:
695
696    Comments:
697
698    (Any comments that the requester deems relevant to the request.)
699
700 A.2.  LDAP Protocol Mechanism Registration Template
701
702    Subject: Request for LDAP Protocol Mechanism Registration
703
704    Object Identifier:
705
706    Description:
707
708    Person & email address to contact for further information:
709
710    Usage: (One of Control or Extension or Feature or other)
711
712    Specification: (RFC, I-D, URI)
713
714    Author/Change Controller:
715
716    Comments:
717
718    (Any comments that the requester deems relevant to the request.)
719
720
721
722
723
724
725
726
727
728
729
730 Zeilenga                 Best Current Practice                 [Page 13]
731 \f
732 RFC 4520              IANA Considerations for LDAP             June 2006
733
734
735 A.3.  LDAP Syntax Registration Template
736
737    Subject: Request for LDAP Syntax Registration
738
739    Object Identifier:
740
741    Description:
742
743    Person & email address to contact for further information:
744
745    Specification: (RFC, I-D, URI)
746
747    Author/Change Controller:
748
749    Comments:
750
751    (Any comments that the requester deems relevant to the request.)
752
753 A.4.  LDAP Descriptor Registration Template
754
755    Subject: Request for LDAP Descriptor Registration
756
757    Descriptor (short name):
758
759    Object Identifier:
760
761    Person & email address to contact for further information:
762
763    Usage: (One of administrative role, attribute type, matching rule,
764      name form, object class, URL extension, or other)
765
766    Specification: (RFC, I-D, URI)
767
768    Author/Change Controller:
769
770    Comments:
771
772    (Any comments that the requester deems relevant to the request.)
773
774
775
776
777
778
779
780
781
782
783
784
785
786 Zeilenga                 Best Current Practice                 [Page 14]
787 \f
788 RFC 4520              IANA Considerations for LDAP             June 2006
789
790
791 A.5.  LDAP Attribute Description Option Registration Template
792
793    Subject: Request for LDAP Attribute Description Option Registration
794    Option Name:
795
796    Family of Options: (YES or NO)
797
798    Person & email address to contact for further information:
799
800    Specification: (RFC, I-D, URI)
801
802    Author/Change Controller:
803
804    Comments:
805
806    (Any comments that the requester deems relevant to the request.)
807
808 A.6.  LDAP Message Type Registration Template
809
810    Subject: Request for LDAP Message Type Registration
811
812    LDAP Message Name:
813
814    Person & email address to contact for further information:
815
816    Specification: (Approved I-D)
817
818    Comments:
819
820    (Any comments that the requester deems relevant to the request.)
821
822 A.7.  LDAP Authentication Method Registration Template
823
824    Subject: Request for LDAP Authentication Method Registration
825
826    Authentication Method Name:
827
828    Person & email address to contact for further information:
829
830    Specification: (RFC, I-D, URI)
831
832    Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE)
833
834    Author/Change Controller:
835
836    Comments:
837
838    (Any comments that the requester deems relevant to the request.)
839
840
841
842 Zeilenga                 Best Current Practice                 [Page 15]
843 \f
844 RFC 4520              IANA Considerations for LDAP             June 2006
845
846
847 A.8.  LDAP Result Code Registration Template
848
849    Subject: Request for LDAP Result Code Registration
850
851    Result Code Name:
852
853    Person & email address to contact for further information:
854
855    Specification: (RFC, I-D, URI)
856
857    Author/Change Controller:
858
859    Comments:
860
861    (Any comments that the requester deems relevant to the request.)
862
863 A.8.  LDAP Search Scope Registration Template
864
865    Subject: Request for LDAP Search Scope Registration
866
867    Search Scope Name:
868
869    Filter Scope String:
870
871    Person & email address to contact for further information:
872
873    Specification: (RFC, I-D, URI)
874
875    Author/Change Controller:
876
877    Comments:
878
879    (Any comments that the requester deems relevant to the request.)
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898 Zeilenga                 Best Current Practice                 [Page 16]
899 \f
900 RFC 4520              IANA Considerations for LDAP             June 2006
901
902
903 A.9.  LDAP Filter Choice Registration Template
904
905    Subject: Request for LDAP Filter Choice Registration
906
907    Filter Choice Name:
908
909    Person & email address to contact for further information:
910
911    Specification: (RFC, I-D, URI)
912
913    Author/Change Controller:
914
915    Comments:
916
917    (Any comments that the requester deems relevant to the request.)
918
919 A.10.  LDAP ModifyRequest Operation Registration Template
920
921    Subject: Request for LDAP ModifyRequest Operation Registration
922
923    ModifyRequest Operation Name:
924
925    Person & email address to contact for further information:
926
927    Specification: (RFC, I-D, URI)
928
929    Author/Change Controller:
930
931    Comments:
932
933    (Any comments that the requester deems relevant to the request.)
934
935 Appendix B.  Changes since RFC 3383
936
937    This informative appendix provides a summary of changes made since
938    RFC 3383.
939
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.
946
947       -  Protocol Mechanisms practices were updated to include values of
948          the 'supportedFeatures' attribute type.
949
950
951
952
953
954 Zeilenga                 Best Current Practice                 [Page 17]
955 \f
956 RFC 4520              IANA Considerations for LDAP             June 2006
957
958
959       -  LDAP Syntax, Search Scope, Filter Choice, ModifyRequest
960          operation, and authzId prefixes registries were added.
961
962       -  References to RFCs comprising the LDAP technical specifications
963          have been updated to latest revisions.
964
965       -  References to ISO 10646 have been replaced with [Unicode].
966
967       -  The "Assigned Values" appendix providing initial registry
968          values was removed.
969
970       -  Numerous editorial changes were made.
971
972 Author's Address
973
974    Kurt D. Zeilenga
975    OpenLDAP Foundation
976
977    EMail: Kurt@OpenLDAP.org
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010 Zeilenga                 Best Current Practice                 [Page 18]
1011 \f
1012 RFC 4520              IANA Considerations for LDAP             June 2006
1013
1014
1015 Full Copyright Statement
1016
1017    Copyright (C) The Internet Society (2006).
1018
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.
1022
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.
1030
1031 Intellectual Property
1032
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.
1041
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.
1048
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.
1054
1055 Acknowledgement
1056
1057    Funding for the RFC Editor function is provided by the IETF
1058    Administrative Support Activity (IASA).
1059
1060
1061
1062
1063
1064
1065
1066 Zeilenga                 Best Current Practice                 [Page 19]
1067 \f