source4/ldap_server/devdocs/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