1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4520 OpenLDAP Foundation 9BCP: 64 June 2006 10Obsoletes: 3383 11Category: Best Current Practice 12 13 14 Internet Assigned Numbers Authority (IANA) Considerations for 15 the Lightweight Directory Access Protocol (LDAP) 16 17Status 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 23Copyright Notice 24 25 Copyright (C) The Internet Society (2006). 26 27Abstract 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 341. 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 58Zeilenga Best Current Practice [Page 1] 59 60RFC 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 712. Terminology and Conventions 72 73 This section details terms and conventions used in this document. 74 752.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 842.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 932.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 114Zeilenga Best Current Practice [Page 2] 115 116RFC 4520 IANA Considerations for LDAP June 2006 117 118 1193. 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 1313.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 1613.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 170Zeilenga Best Current Practice [Page 3] 171 172RFC 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 1843.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 1983.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 226Zeilenga Best Current Practice [Page 4] 227 228RFC 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 2553.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 282Zeilenga Best Current Practice [Page 5] 283 284RFC 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 2933.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 3093.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 338Zeilenga Best Current Practice [Page 6] 339 340RFC 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 3513.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 3683.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 3853.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 394Zeilenga Best Current Practice [Page 7] 395 396RFC 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 4063.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 4233.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 450Zeilenga Best Current Practice [Page 8] 451 452RFC 4520 IANA Considerations for LDAP June 2006 453 454 4553.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 4714. 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 506Zeilenga Best Current Practice [Page 9] 507 508RFC 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 5185. Registration Maintenance 519 520 This section discusses maintenance of registrations. 521 5225.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 5275.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 5355.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 5486. 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 562Zeilenga Best Current Practice [Page 10] 563 564RFC 4520 IANA Considerations for LDAP June 2006 565 566 5677. 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 5778. References 578 5798.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 618Zeilenga Best Current Practice [Page 11] 619 620RFC 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 6408.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 674Zeilenga Best Current Practice [Page 12] 675 676RFC 4520 IANA Considerations for LDAP June 2006 677 678 679Appendix 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 686A.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 700A.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 730Zeilenga Best Current Practice [Page 13] 731 732RFC 4520 IANA Considerations for LDAP June 2006 733 734 735A.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 753A.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 786Zeilenga Best Current Practice [Page 14] 787 788RFC 4520 IANA Considerations for LDAP June 2006 789 790 791A.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 808A.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 822A.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 842Zeilenga Best Current Practice [Page 15] 843 844RFC 4520 IANA Considerations for LDAP June 2006 845 846 847A.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 863A.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 898Zeilenga Best Current Practice [Page 16] 899 900RFC 4520 IANA Considerations for LDAP June 2006 901 902 903A.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 919A.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 935Appendix 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 954Zeilenga Best Current Practice [Page 17] 955 956RFC 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 972Author'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 1010Zeilenga Best Current Practice [Page 18] 1011 1012RFC 4520 IANA Considerations for LDAP June 2006 1013 1014 1015Full 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 1031Intellectual 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 1055Acknowledgement 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 1066Zeilenga Best Current Practice [Page 19] 1067 1068