idnits 2.17.1 draft-ietf-ldapbis-bcp64-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 923. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 934. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 941. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 947. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 911), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 36 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (31 January 2006) is 6658 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3629' is defined on line 543, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Obsolete informational reference (is this intentional?): RFC 1779 (Obsoleted by RFC 2253, RFC 3494) -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: BCP OpenLDAP Foundation 4 Expires in six months 31 January 2006 5 Obsoletes: RFC 3383 7 IANA Considerations for LDAP 8 10 Status of Memo 12 This document is intended to be, after appropriate review and 13 revision, submitted to the RFC Editor as a Best Current Practice 14 document. This document is intended to replace RFC 3383. 15 Distribution of this memo is unlimited. Technical discussion of this 16 document will take place on the IETF LDAP Revision Working Group 17 (LDAPBIS) mailing list . Please send 18 editorial comments directly to the document editor 19 . 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that other 28 groups may also distribute working documents as Internet-Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/1id-abstracts.html 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 Copyright (C) The Internet Society (2006). All Rights Reserved. 43 Please see the Full Copyright section near the end of this document 44 for more information. 46 Abstract 48 This document provides procedures for registering extensible elements 49 of Lightweight Directory Access Protocol (LDAP). The document also 50 provides guidelines to Internet Assigned Numbers Authority (IANA) 51 describing conditions under which new values can be assigned. 53 1. Introduction 55 The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an 56 extensible protocol. LDAP supports: 58 - addition of new operations, 59 - extension of existing operations, and 60 - extensible schema. 62 This document details procedures for registering values of used to 63 unambiguously identify extensible elements of the protocol including: 65 - LDAP message types; 66 - LDAP extended operations and controls; 67 - LDAP result codes; 68 - LDAP authentication methods; 69 - LDAP attribute description options; and 70 - Object Identifier descriptors. 72 These registries are maintained by the Internet Assigned Numbers 73 Authority (IANA). 75 In addition, this document provides guidelines to IANA describing the 76 conditions under which new values can be assigned. 78 This document replaces RFC 3383. 80 2. Terminology and Conventions 82 This section details terms and conventions used in this document. 84 2.1. Policy Terminology 86 The terms "IESG Approval", "Standards Action", "IETF Consensus", 87 "Specification Required", "First Come First Served", "Expert Review", 88 and "Private Use" are used as defined in BCP 26 [RFC2434]. 90 The term "registration owner" (or "owner") refers to the party 91 authorized to change a value's registration. 93 2.2. Requirement Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in BCP 14 [RFC2119]. In 98 this case, "the specification" as used by BCP 14 refers to the 99 processing of protocols being submitted to the IETF standards 100 process. 102 2.3. Common ABNF Productions 104 A number of syntaxes in this document are described using ABNF 105 [ABNF]. These syntaxes rely on the following common productions: 107 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 108 LDIGIT = %x31-39 ; "1"-"9" 109 DIGIT = %x30 / LDIGIT ; "0"-"9" 110 HYPHEN = %x2D ; "-" 111 DOT = %x2E ; "." 112 number = DIGIT / ( LDIGIT 1*DIGIT ) 113 keychar = ALPHA / DIGIT / HYPHEN 114 leadkeychar = ALPHA 115 keystring = leadkeychar *keychar 116 keyword = keystring 118 Keywords are case-insensitive. 120 3. IANA Considerations for LDAP 122 This section details each kind of protocol value which can be 123 registered and provides IANA guidelines on how to assign new values. 125 IANA may reject obviously bogus registrations. 127 LDAP values specified in RFCs MUST be registered. Other LDAP values, 128 except those in private-use name spaces, SHOULD be registered. RFCs 129 SHOULD NOT reference, use, or otherwise recognize unregistered LDAP 130 values. 132 3.1. Object Identifiers 134 Numerous LDAP schema and protocol elements are identified by Object 135 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 136 elements SHOULD state who delegated the OIDs for its use. 138 For IETF developed elements, specifications SHOULD use OIDs under 139 "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 140 by others, any properly delegated OID can be used, including those 141 under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 142 Enterprise Numbers" (1.3.6.1.4.1.x). 144 Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 145 Review with Specification Required. Only one OID per specification 146 will be assigned. The specification MAY then assign any number of 147 OIDs within this arc without further coordination with IANA. 149 Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 150 IANA . Practices for IANA 151 assignment of Internet Private Enterprise Numbers is detailed in RFC 152 2578 [RFC2578]. 154 To avoid interoperability problems between early implementations of a 155 "work in progress" and implementations of the published specification 156 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 157 progress" and early implementations. OIDs under the Internet 158 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 159 Practices for IANA assignment of these Internet Experimental numbers 160 is detailed in RFC 2578 [RFC2578] 162 3.2 Protocol Mechanisms 164 LDAP provides a number of Root DSE attributes for discovery of 165 protocol mechanisms identified by OIDs, including the 166 supportedControl, supportedExtension, and supportedFeatures 167 attributes [Models], 169 A registry of OIDs used for discover of protocol mechanisms is 170 provided to allow implementors and others to locate the technical 171 specification for these protocol mechanisms. Future specifications 172 of additional Root DSE attributes holding values identifying protocol 173 mechanisms MAY extend this registry for their values. 175 Protocol Mechanisms are registered on a First Come First Served 176 basis. 178 3.3 LDAP Syntaxes 180 This registry provides a listing of LDAP syntaxes [Models]. Each 181 LDAP syntax is identified by an object identifier (OID). This 182 registry is provided to allow implementors and others to locate the 183 technical specification describing a particular LDAP Syntax. 185 LDAP Syntaxes are registered on a First Come First Served with 186 Specification Required basis. 188 Note: unlike object classes, attribute types and various other kinds 189 of schema elements, descriptors are not used in LDAP to identify LDAP 190 Syntaxes. 192 3.4. Object Identifier Descriptors 194 LDAP allows short descriptive names (or descriptors) to be used 195 instead of a numeric Object Identifier to identify select protocol 196 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 197 extensions, and other objects. 199 While the protocol allows the same descriptor to refer to different 200 object identifiers in certain cases and the registry supports 201 multiple registrations of the same descriptor (each indicating a 202 different kind of schema element and different object identifier), 203 multiple registrations of the same descriptor are to be avoided. All 204 such multiple registration requests require Expert Review. 206 Descriptors are restricted to strings of UTF-8 encoded Unicode 207 characters restricted by the following ABNF: 209 name = keystring 211 Descriptors are case-insensitive. 213 Multiple names may be assigned to a given OID. For purposes of 214 registration, an OID is to be represented in numeric OID form (e.g., 215 1.1.0.23.40) conforming to the ABNF: 217 numericoid = number 1*( DOT number ) 219 While the protocol places no maximum length restriction upon 220 descriptors, they should be short. Descriptors longer than 48 221 characters may be viewed as too long to register. 223 A value ending with a hyphen ("-") reserves all descriptors which 224 start with that value. For example, the registration of the option 225 "descrFamily-" reserves all options which start with "descrFamily-" 226 for some related purpose. 228 Descriptors beginning with "x-" are for Private Use and cannot be 229 registered. 231 Descriptors beginning with "e-" are reserved for experiments and will 232 be registered on a First Come First Served basis. 234 All other descriptors require Expert Review to be registered. 236 The registrant need not "own" the OID being named. 238 The OID name space is managed by The ISO/IEC Joint Technical 239 Committee 1 - Subcommittee 6. 241 3.5. AttributeDescription Options 243 An AttributeDescription [Models] can contain zero or more options 244 specifying additional semantics. An option SHALL be restricted to a 245 string UTF-8 encoded Unicode characters limited by the following 246 ABNF: 248 option = keystring 250 Options are case-insensitive. 252 While the protocol places no maximum length restriction upon option 253 strings, they should be short. Options longer than 24 characters may 254 be viewed as too long to register. 256 Values ending with a hyphen ("-") reserve all option names which 257 start with the name. For example, the registration of the option 258 "optionFamily-" reserves all options which start with "optionFamily-" 259 for some related purpose. 261 Options beginning with "x-" are for Private Use and cannot be 262 registered. 264 Options beginning with "e-" are reserved for experiments and will be 265 registered on a First Come First Served basis. 267 All other options require Standards Action or Expert Review with 268 Specification Required to be registered. 270 3.6. LDAP Message Types 272 Each protocol message is encapsulated in an LDAPMessage envelope 273 [Protocol]. The protocolOp CHOICE indicates the type of message 274 encapsulated. Each message type consists of an ASN.1 identifier in 275 the form of a keyword and a non-negative choice number. The choice 276 number is combined with the class (APPLICATION) and data type 277 (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's 278 encoding. The choice numbers for existing protocol messages are 279 implicit in the protocol's ASN.1 defined in [Protocol]. 281 New values will be registered upon Standards Action. 283 Note: LDAP provides extensible messages which reduces, but does not 284 eliminate, the need to add new message types. 286 3.7. LDAP Authentication Method 288 The LDAP Bind operation supports multiple authentication methods 289 [Protocol]. Each authentication choice consists of an ASN.1 290 identifier in the form of a keyword and a non-negative integer. 292 The registrant SHALL classify the authentication method usage using 293 one of the following terms: 295 COMMON - method is appropriate for common use on the 296 Internet, 297 LIMITED USE - method is appropriate for limited use, 298 OBSOLETE - method has been deprecated or otherwise found to 299 be inappropriate for any use. 301 Methods without publicly available specifications SHALL NOT be 302 classified as COMMON. New registrations of class OBSOLETE cannot be 303 registered. 305 New authentication method integers in the range 0-1023 require 306 Standards Action to be registered. New authentication method 307 integers in the range 1024-4095 require Expert Review with 308 Specification Required. New authentication method integers in the 309 range 4096-16383 will be registered on a First Come First Served 310 basis. Keywords associated with integers in the range 0-4095 SHALL 311 NOT start with "e-" or "x-". Keywords associated with integers in 312 the range 4096-16383 SHALL start with "e-". Values greater than or 313 equal to 16384 and keywords starting with "x-" are for Private Use 314 and cannot be registered. 316 Note: LDAP supports Simple Authentication and Security Layers [SASL] 317 as an authentication choice. SASL is an extensible 318 authentication framework. 320 3.8. LDAP Result Codes 322 LDAP result messages carry an resultCode enumerated value to indicate 323 the outcome of the operation [Protocol]. Each result code consists 324 of a ASN.1 identifier in the form of a keyword and a non-negative 325 integer. 327 New resultCodes integers in the range 0-1023 require Standards Action 328 to be registered. New resultCode integers in the range 1024-4095 329 require Expert Review with Specification Required. New resultCode 330 integers in the range 4096-16383 will be registered on a First Come 331 First Served basis. Keywords associated with integers in the range 332 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 333 integers in the range 4096-16383 SHALL start with "e-". Values 334 greater than or equal to 16384 and keywords starting with "x-" are 335 for Private Use and cannot be registered. 337 3.9. LDAP Search Scope 339 LDAP SearchRequest messages carry a scope enumerated value to 340 indicate the extend of search within the DIT [Protocol] Each search 341 value consists of a ASN.1 identifier in the form of a keyword and a 342 non-negative integer. 344 New scope integers in the range 0-1023 require Standards Action to be 345 registered. New scope integers in the range 1024-4095 require Expert 346 Review with Specification Required. New scope integers in the range 347 4096-16383 will be registered on a First Come First Served basis. 348 Keywords associated with integers in the range 0-4095 SHALL NOT start 349 with "e-" or "x-". Keywords associated with integers in the range 350 4096-16383 SHALL start with "e-". Values greater than or equal to 351 16384 and keywords starting with "x-" are for Private Use and cannot 352 be registered. 354 3.10. LDAP Filter Choice 356 LDAP filters are used in making assertions against an object 357 represented in the directory [Protocol]. The Filter CHOICE indicates 358 a type of assertion. Each Filter CHOICE consists of an ASN.1 359 identifier in the form of a keyword and a non-negative choice number. 360 The choice number is combined with the class (APPLICATION) and data 361 type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the 362 message's encoding. 364 Note: LDAP provides the extensibleMatching choice which reduces, but 365 does not eliminate, the need to add new filter choices. 367 3.11. LDAP ModifyRequest Operation Type 369 The LDAP ModifyRequest carries a sequence of modification operations 370 [Protocol]. Each kind (e.g., add, delete, replace) of operation is 371 consists of a ASN.1 identifier in the form of a keyword and a 372 non-negative integer. 374 New operation type integers in the range 0-1023 require Standards 375 Action to be registered. New operation type integers in the range 376 1024-4095 require Expert Review with Specification Required. New 377 operation type integers in the range 4096-16383 will be registered on 378 a First Come First Served basis. Keywords associated with integers 379 in the range 0-4095 SHALL NOT start with "e-" or "x-". Keywords 380 associated with integers in the range 4096-16383 SHALL start with 381 "e-". Values greater than or equal to 16384 and keywords starting 382 with "x-" are for Private Use and cannot be registered. 384 3.12. LDAP authzId Prefixes 386 Authorization Identities in LDAP are strings conforming to the 387 production [AuthMeth]. This production is extensible. 388 Each new specific authorization form is identified by a prefix string 389 conforming to the following ABNF: 391 prefix = keystring COLON 392 COLON = %x3A ; COLON (":" U+003A) 394 Prefixes are case-insensitive. 396 While the protocol places no maximum length restriction upon prefix 397 strings, they should be short. Prefixes longer than 12 characters 398 may be viewed as too long to register. 400 Prefixes beginning with "x-" are for Private Use and cannot be 401 registered. 403 Prefixes beginning with "e-" are reserved for experiments and will be 404 registered on a First Come First Served basis. 406 All other prefixes require Standards Action or Expert Review with 407 Specification Required to be registered. 409 3.13. Directory Systems Names 411 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 412 valid keywords for well known attributes was used in the LDAPv2 413 string representation of a distinguished name [RFC1779]. LDAPv2 is 414 now Historic [RFC3494]. 416 Directory systems names are not known to be used in any other 417 context. LDAPv3 [LDAPDN] uses Object Identifier Descriptors [Section 418 3.2] (which have a different syntax than directory system names). 420 New Directory System Names will no longer be accepted. For 421 historical purposes, the current list of registered names should 422 remain publicly available. 424 4. Registration Procedure 426 The procedure given here MUST be used by anyone who wishes to use a 427 new value of a type described in Section 3 of this document. 429 The first step is for the requester to fill out the appropriate form. 430 Templates are provided in Appendix A. 432 If the policy is Standards Action, the completed form SHOULD be 433 provided to the IESG with the request for Standards Action. Upon 434 approval of the Standards Action, the IESG SHALL forward the request 435 (possibly revised) to IANA. The IESG SHALL be regarded as the 436 registration owner of all values requiring Standards Action. 438 If the policy is Expert Review, the requester SHALL post the 439 completed form to the mailing list for 440 public review. The review period is two (2) weeks. If a revised 441 form is later submitted, the review period is restarted. Anyone may 442 subscribe to this list by sending a request to 443 . During the review, objections may 444 be raised by anyone (including the Expert) on the list. After 445 completion of the review, the Expert, based upon public comments, 446 SHALL either approve the request and forward it to the IANA OR deny 447 the request. In either case, the Expert SHALL promptly notify the 448 requester of the action. Actions of the Expert may be appealed 449 [RFC2026]. The Expert is appointed by Applications Area Director(s). 450 The requester is viewed as the registration owner of values 451 registered under Expert Review. 453 If the policy is First Come First Served, the requester SHALL submit 454 the completed form directly to the IANA: . The 455 requester is viewed as the registration owner of values registered 456 under First Come First Served. 458 Neither the Expert nor IANA will take position on the claims of 459 copyright or trademarks issues regarding completed forms. 461 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 462 after IESG review and tentative approval, the document editor SHOULD 463 revise the I-D to use registered values. 465 5. Registration Maintenance 467 This section discusses maintenance of registrations. 469 5.1. Lists of Registered Values 471 IANA makes lists of registered values readily available to the 472 Internet community on their web site: . 474 5.2. Change Control 476 The registration owner MAY update the registration subject to the 477 same constraints and review as with new registrations. In cases 478 where the registration owner is not unable or unwilling to make 479 necessary updates, the IESG MAY assume ownership of the registration 480 in order to update the registration. 482 5.3. Comments 484 For cases where others (anyone other than the registration owner) 485 have significant objections to the claims in a registration and the 486 registration owner does not agree to change the registration, 487 comments MAY be attached to a registration upon Expert Review. For 488 registrations owned by the IESG, the objections SHOULD be addressed 489 by initiating a request for Expert Review. 491 The form to these requests is ad hoc, but MUST include the specific 492 objections to be reviewed and SHOULD contain (directly or by 493 reference) materials supporting the objections. 495 6. Security Considerations 497 The security considerations detailed in BCP 26 [RFC2434] are 498 generally applicable to this document. Additional security 499 considerations specific to each name space are discussed in Section 3 500 where appropriate. 502 Security considerations for LDAP are discussed in documents 503 comprising the technical specification [Roadmap]. 505 7. Acknowledgment 507 This document is a product of the IETF LDAP Revision (LDAPBIS) 508 Working Group (WG). This document is a revision of RFC 3383, also a 509 product of the LDAPBIS WG. 511 This document includes text borrowed from "Guidelines for Writing an 512 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 513 Harald Alvestrand. 515 8. Author's Address 517 Kurt D. Zeilenga 518 OpenLDAP Foundation 520 Email: Kurt@OpenLDAP.org 522 9. References 524 [[Note to the RFC Editor: please replace the citation tags used in 525 referencing Internet-Drafts with tags of the form RFCnnnn where 526 possible.]] 528 9.1. Normative References 530 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 531 3", BCP 9 (also RFC 2026), October 1996. 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 536 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 537 IANA Considerations Section in RFCs", BCP 26 (also RFC 538 2434), October 1998. 540 [RFC2578] K. McCloghrie, D. Perkins, J. Schoenwaelder, "Structure 541 of Management Information Version 2 (SMIv2)", RFC 2578 542 (STD: 58), April 1999. 543 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 544 10646", RFC 3629 (also STD 63), November 2003. 546 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 547 Specifications: ABNF", RFC 4234, October 2005. 549 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 550 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 551 progress. 553 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 554 Connection Level Security Mechanisms", 555 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 557 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 558 Models", draft-ietf-ldapbis-models-xx.txt, a work in 559 progress. 561 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 562 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 564 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 565 draft-ietf-ldapbis-url-xx.txt, a work in progress. 567 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 568 3.2.0" is defined by "The Unicode Standard, Version 3.0" 569 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 570 as amended by the "Unicode Standard Annex #27: Unicode 571 3.1" (http://www.unicode.org/reports/tr27/) and by the 572 "Unicode Standard Annex #28: Unicode 3.2" 573 (http://www.unicode.org/reports/tr28/). 575 [X.680] International Telecommunication Union - 576 Telecommunication Standardization Sector, "Abstract 577 Syntax Notation One (ASN.1) - Specification of Basic 578 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 580 9.2. Informative References 582 [RFC1779] Kille, S., "A String Representation of Distinguished 583 Names", RFC 1779, March 1995. 585 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 586 version 2 (LDAPv2) to Historic Status", RFC 3494, March 587 2003. 589 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 590 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 592 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 593 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a 594 work in progress. 596 [SASL] Melnikov, A. (Editor), "Simple Authentication and 597 Security Layer (SASL)", 598 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 600 [IANADSN] IANA, "Directory Systems Names", 601 http://www.iana.org/assignments/directory-system-names. 603 Appendix A. Registration Templates 605 This appendix provides registration templates for registering new 606 LDAP values. Note that more than one value may be requested by 607 extending the template by listing multiple values, or through use of 608 tables. 610 A.1. LDAP Object Identifier Registration Template 612 Subject: Request for LDAP OID Registration 614 Person & email address to contact for further information: 616 Specification: (I-D) 618 Author/Change Controller: 620 Comments: 622 (Any comments that the requester deems relevant to the request) 624 A.2. LDAP Protocol Mechanism Registration Template 626 Subject: Request for LDAP Protocol Mechanism Registration 628 Object Identifier: 630 Description: 632 Person & email address to contact for further information: 634 Usage: (One of Control or Extension or Feature or other) 636 Specification: (RFC, I-D, URI) 638 Author/Change Controller: 640 Comments: 642 (Any comments that the requester deems relevant to the request) 644 A.3. LDAP Syntax Registration Template 646 Subject: Request for LDAP Syntax Registration 648 Object Identifier: 650 Description: 652 Person & email address to contact for further information: 654 Specification: (RFC, I-D, URI) 656 Author/Change Controller: 658 Comments: 660 (Any comments that the requester deems relevant to the request) 662 A.4. LDAP Descriptor Registration Template 664 Subject: Request for LDAP Descriptor Registration 666 Descriptor (short name): 668 Object Identifier: 670 Person & email address to contact for further information: 672 Usage: (One of administrative role, attribute type, matching rule, 673 name form, object class, URL extension, or other) 675 Specification: (RFC, I-D, URI) 677 Author/Change Controller: 679 Comments: 681 (Any comments that the requester deems relevant to the request) 683 A.5. LDAP Attribute Description Option Registration Template 685 Subject: Request for LDAP Attribute Description Option Registration 686 Option Name: 688 Family of Options: (YES or NO) 690 Person & email address to contact for further information: 692 Specification: (RFC, I-D, URI) 694 Author/Change Controller: 696 Comments: 698 (Any comments that the requester deems relevant to the request) 700 A.6. LDAP Message Type Registration Template 702 Subject: Request for LDAP Message Type Registration 704 LDAP Message Name: 706 Person & email address to contact for further information: 708 Specification: (Approved I-D) 710 Comments: 712 (Any comments that the requester deems relevant to the request) 714 A.7. LDAP Authentication Method Registration Template 716 Subject: Request for LDAP Authentication Method Registration 718 Authentication Method Name: 720 Person & email address to contact for further information: 722 Specification: (RFC, I-D, URI) 724 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 726 Author/Change Controller: 728 Comments: 730 (Any comments that the requester deems relevant to the request) 732 A.8. LDAP Result Code Registration Template 734 Subject: Request for LDAP Result Code Registration 736 Result Code Name: 738 Person & email address to contact for further information: 740 Specification: (RFC, I-D, URI) 742 Author/Change Controller: 744 Comments: 746 (Any comments that the requester deems relevant to the request) 748 A.8. LDAP Search Scope Registration Template 750 Subject: Request for LDAP Search Scope Registration 752 Search Scope Name: 754 Filter Scope String: 756 Person & email address to contact for further information: 758 Specification: (RFC, I-D, URI) 760 Author/Change Controller: 762 Comments: 764 (Any comments that the requester deems relevant to the request) 766 A.9. LDAP Filter Choice Registration Template 768 Subject: Request for LDAP Filter Choice Registration 770 Filter Choice Name: 772 Person & email address to contact for further information: 774 Specification: (RFC, I-D, URI) 776 Author/Change Controller: 778 Comments: 780 (Any comments that the requester deems relevant to the request) 782 A.10. LDAP ModifyRequest Operation Registration Template 784 Subject: Request for LDAP ModifyRequest Operation Registration 786 ModifyRequest Operation Name: 788 Person & email address to contact for further information: 790 Specification: (RFC, I-D, URI) 792 Author/Change Controller: 794 Comments: 796 (Any comments that the requester deems relevant to the request) 798 Appendix B. Changes since RFC 3383 800 This informative appendix provides a summary of changes made since RFC 801 3383. 803 - Object Identifier Descriptors practices were updated to require 804 all descriptors defined in RFCs to be registered and 805 recommending all other descriptors (excepting those in 806 private-use name space) be registered. Additionally, all 807 requests for multiple registrations of the same descriptor are 808 now subject to Expert Review. 810 - Protocol Mechanisms practices were updated to include values of 811 the 'supportedFeatures' attribute type. 813 - LDAP Syntax, Search Scope, Filter Choice, ModifyRequest 814 operation, and authzId prefixes registries were added. 815 [[Initial values provided in Appendix C. This Appendix is to be 816 removed by the RFC Editor before publication as an RFC.]] 818 - References to RFCs comprising the LDAP technical specifications 819 have been updated to latest revisions. 821 - References to ISO 10646 have been replaced with [Unicode]. 823 - The "Assigned Values" appendix providing initial registry values 824 was removed. 826 - Numerous editorial changes were made. 828 Appendix C. Initial Values for new registries 830 This appendix provides initial values for new registries. 832 C.1. LDAP Syntaxes 834 Object Identifier Syntax Owner Reference 835 ----------------------------- -------------------------- ----- --------- 836 1.3.6.1.4.1.1466.115.121.1.3 Attribute Type Description IESG [Syntaxes] 837 1.3.6.1.4.1.1466.115.121.1.6 Bit String IESG [Syntaxes] 838 1.3.6.1.4.1.1466.115.121.1.7 Boolean IESG [Syntaxes] 839 1.3.6.1.4.1.1466.115.121.1.11 Country String IESG [Syntaxes] 840 1.3.6.1.4.1.1466.115.121.1.12 DN IESG [Syntaxes] 841 1.3.6.1.4.1.1466.115.121.1.14 Delivery Method IESG [Syntaxes] 842 1.3.6.1.4.1.1466.115.121.1.15 Directory String IESG [Syntaxes] 843 1.3.6.1.4.1.1466.115.121.1.16 DIT Content Rule Description IESG [Syntaxes] 844 1.3.6.1.4.1.1466.115.121.1.17 DIT Structure Rule Description IESG [Syntaxes] 845 1.3.6.1.4.1.1466.115.121.1.21 Enhanced Guide IESG [Syntaxes] 846 1.3.6.1.4.1.1466.115.121.1.22 Facsimile Telephone Number IESG [Syntaxes] 847 1.3.6.1.4.1.1466.115.121.1.23 Fax IESG [Syntaxes] 848 1.3.6.1.4.1.1466.115.121.1.24 Generalized Time IESG [Syntaxes] 849 1.3.6.1.4.1.1466.115.121.1.25 Guide IESG [Syntaxes] 850 1.3.6.1.4.1.1466.115.121.1.26 IA5 String IESG [Syntaxes] 851 1.3.6.1.4.1.1466.115.121.1.27 Integer IESG [Syntaxes] 852 1.3.6.1.4.1.1466.115.121.1.28 JPEG IESG [Syntaxes] 853 1.3.6.1.4.1.1466.115.121.1.30 Matching Rule Description IESG [Syntaxes] 854 1.3.6.1.4.1.1466.115.121.1.31 Matching Rule Use Description IESG [Syntaxes] 855 1.3.6.1.4.1.1466.115.121.1.34 Name And Optional UID IESG [Syntaxes] 856 1.3.6.1.4.1.1466.115.121.1.35 Name Form Description IESG [Syntaxes] 857 1.3.6.1.4.1.1466.115.121.1.36 Numeric String IESG [Syntaxes] 858 1.3.6.1.4.1.1466.115.121.1.37 Object Class Description IESG [Syntaxes] 859 1.3.6.1.4.1.1466.115.121.1.38 OID IESG [Syntaxes] 860 1.3.6.1.4.1.1466.115.121.1.39 Other Mailbox IESG [Syntaxes] 861 1.3.6.1.4.1.1466.115.121.1.40 Octet String IESG [Syntaxes] 862 1.3.6.1.4.1.1466.115.121.1.41 Postal Address IESG [Syntaxes] 863 1.3.6.1.4.1.1466.115.121.1.44 Printable String IESG [Syntaxes] 864 1.3.6.1.4.1.1466.115.121.1.50 Telephone Number IESG [Syntaxes] 865 1.3.6.1.4.1.1466.115.121.1.51 Teletex Terminal Identifier IESG [Syntaxes] 866 1.3.6.1.4.1.1466.115.121.1.52 Telex Number IESG [Syntaxes] 867 1.3.6.1.4.1.1466.115.121.1.53 UTC Time IESG [Syntaxes] 868 1.3.6.1.4.1.1466.115.121.1.54 LDAP Syntax Description IESG [Syntaxes] 869 1.3.6.1.4.1.1466.115.121.1.58 Substring Assertion IESG [Syntaxes] 871 C.2. LDAP Search Scopes 873 Name URLString Value Owner Reference 874 ---------------- --------- ----- ----- ------------------- 875 baseObject base 0 IESG [Protocol][LDAPURL] 876 singleLevel one 1 IESG [Protocol][LDAPURL] 877 wholeSubtree sub 2 IESG [Protocol][LDAPURL] 879 C.3. LDAP Filter Choices 881 Name Value Owner Reference 882 ---------------- ----- ----- --------- 883 and 0 IESG [Protocol] 884 or 1 IESG [Protocol] 885 not 2 IESG [Protocol] 886 equalityMatch 3 IESG [Protocol] 887 substrings 4 IESG [Protocol] 888 greaterOrEqual 5 IESG [Protocol] 889 lessOrEqual 6 IESG [Protocol] 890 present 7 IESG [Protocol] 891 approxMatch 8 IESG [Protocol] 892 extensibleMatch 9 IESG [Protocol] 894 C.4. LDAP ModifyRequest Operations 896 Name Value Owner Reference 897 ---------------- ----- ----- --------- 898 add 0 IESG [Protocol] 899 delete 1 IESG [Protocol] 900 replace 2 IESG [Protocol] 902 C.5. LDAP authzId prefixes 904 Name Prefix Owner Reference 905 ---------------- ------ ----- --------- 906 dnAuthzId dn: IESG [AuthMeth] 907 uAuthzId u: IESG [AuthMeth] 909 Full Copyright 911 Copyright (C) The Internet Society (2006). 913 This document is subject to the rights, licenses and restrictions 914 contained in BCP 78, and except as set forth therein, the authors 915 retain all their rights. 917 This document and the information contained herein are provided on an 918 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 919 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 920 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 921 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 922 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 923 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 925 Intellectual Property Rights 927 The IETF takes no position regarding the validity or scope of any 928 Intellectual Property Rights or other rights that might be claimed to 929 pertain to the implementation or use of the technology described in 930 this document or the extent to which any license under such rights 931 might or might not be available; nor does it represent that it has 932 made any independent effort to identify any such rights. Information 933 on the procedures with respect to rights in RFC documents can be found 934 in BCP 78 and BCP 79. 936 Copies of IPR disclosures made to the IETF Secretariat and any 937 assurances of licenses to be made available, or the result of an 938 attempt made to obtain a general license or permission for the use of 939 such proprietary rights by implementers or users of this specification 940 can be obtained from the IETF on-line IPR repository at 941 http://www.ietf.org/ipr. 943 The IETF invites any interested party to bring to its attention any 944 copyrights, patents or patent applications, or other proprietary 945 rights that may cover technology that may be required to implement 946 this standard. Please address the information to the IETF at 947 ietf-ipr@ietf.org.