idnits 2.17.1 draft-ietf-ldapbis-bcp64-04.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 3667, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 905. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 911. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 879), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (24 October 2004) is 7122 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) == Missing Reference: 'RFC3674' is mentioned on line 161, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Missing Reference: 'AuthMeth' is mentioned on line 873, but not defined == Unused Reference: 'Features' is defined on line 555, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) -- 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-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- 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-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- 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-sasl-rfc2222bis-xx - is the name correct? Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Kurt D. Zeilenga 2 Intended Category: BCP OpenLDAP Foundation 3 Expires in six months 24 October 2004 4 Obsoletes: RFC 3383 6 IANA Considerations for LDAP 7 9 Status of Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor as a Best Current Practice 13 document. This document is intended to replace RFC 3383. 14 Distribution of this memo is unlimited. Technical discussion of this 15 document will take place on the IETF LDAP Revision Working Group 16 (LDAPBIS) mailing list . Please send 17 editorial comments directly to the document editor 18 . 20 By submitting this Internet-Draft, I accept the provisions of Section 21 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 22 applicable patent or other IPR claims of which I am aware have been 23 disclosed, or will be disclosed, and any of which I become aware will 24 be disclosed, in accordance with RFC 3668. 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 . The list of 37 Internet-Draft Shadow Directories can be accessed at 38 . 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Please see the Full Copyright section near the end of this document 43 for more information. 45 Abstract 47 This document provides procedures for registering extensible elements 48 of Lightweight Directory Access Protocol (LDAP). The document also 49 provides guidelines to Internet Assigned Numbers Authority (IANA) 50 describing conditions under which new values can be assigned. 52 1. Introduction 54 The Lightweight Directory Access Protocol [Roadmap] (LDAP) is an 55 extensible protocol. LDAP supports: 57 - addition of new operations, 58 - extension of existing operations, and 59 - extensible schema. 61 This document details procedures for registering values of used to 62 unambiguously identify extensible elements of the protocol including: 64 - LDAP message types; 65 - LDAP extended operations and controls; 66 - LDAP result codes; 67 - LDAP authentication methods; 68 - LDAP attribute description options; and 69 - Object Identifier descriptors. 71 These registries are maintained by the Internet Assigned Numbers 72 Authority (IANA). 74 In addition, this document provides guidelines to IANA describing the 75 conditions under which new values can be assigned. 77 This document replaces RFC 3383. 79 2. Terminology and Conventions 81 This section details terms and conventions used in this document. 83 2.1. Policy Terminology 85 The terms "IESG Approval", "Standards Action", "IETF Consensus", 86 "Specification Required", "First Come First Served", "Expert Review", 87 and "Private Use" are used as defined in BCP 26 [RFC2434]. 89 2.2. Requirement Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14 [RFC2119]. In 94 this case, "the specification" as used by BCP 14 refers to the 95 processing of protocols being submitted to the IETF standards 96 process. 98 2.3. Common ABNF Productions 100 A number of syntaxes in this document are described using ABNF 101 [RFC2234]. These syntaxes rely on the following common productions: 103 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 104 LDIGIT = %x31-39 ; "1"-"9" 105 DIGIT = %x30 / LDIGIT ; "0"-"9" 106 HYPHEN = %x2D ; "-" 107 DOT = %x2E ; "." 108 number = DIGIT / ( LDIGIT 1*DIGIT ) 109 keychar = ALPHA / DIGIT / HYPHEN 110 leadkeychar = ALPHA 111 keystring = leadkeychar *keychar 113 A keyword is a case-insensitive string of UTF-8 [RFC3629] encoded 114 Unicode [Unicode] restricted to the production. 116 3. IANA Considerations for LDAP 118 This section details each kind of protocol value which can be 119 registered and provides IANA guidelines on how to assign new values. 121 IANA may reject obviously bogus registrations described. 123 3.1. Object Identifiers 125 Numerous LDAP schema and protocol elements are identified by Object 126 Identifiers (OIDs) [X.680]. Specifications which assign OIDs to 127 elements SHOULD state who delegated the OIDs for its use. 129 For IETF developed elements, specifications SHOULD use OIDs under 130 "Internet Directory Numbers" (1.3.6.1.1.x). For elements developed 131 by others, any properly delegated OID can be used, including those 132 under "Internet Directory Numbers" (1.3.6.1.1.x) or "Internet Private 133 Enterprise Numbers" (1.3.6.1.4.1.x). 135 Internet Directory Numbers (1.3.6.1.1.x) will be assigned upon Expert 136 Review with Specification Required. Only one OID per specification 137 will be assigned. The specification MAY then assign any number of 138 OIDs within this arc without further coordination with IANA. 140 Internet Private Enterprise Numbers (1.3.6.1.4.1.x) are assigned by 141 IANA . 143 To avoid interoperability problems between early implementations of a 144 "work in progress" and implementations of the published specification 145 (e.g., the RFC), experimental OIDs SHOULD be used in "works in 146 progress" and early implementations. OIDs under the Internet 147 Experimental OID arc (1.3.6.1.3.x) may be used for this purpose. 149 Experimental OIDs SHALL NOT be used in published specifications (e.g. 150 RFCs). 152 Practices for IANA assignment of Internet Enterprise and Experimental 153 OIDs are detailed in STD 16 [RFC1155]. 155 3.2 Protocol Mechanisms 157 LDAP provides a number of Root DSE attributes for discovery of 158 protocol mechanisms identified by OIDs, including: 159 - supportedControl [Models], 160 - supportedExtension [Models], and 161 - supportedFeatures [RFC3674], 163 A registry of OIDs used for discover of protocol mechanisms is 164 provided to allow implementors and others to locate the technical 165 specification for these protocol mechanisms. Future specifications 166 of additional Root DSE attributes holding values identifying protocol 167 mechanisms MAY extend this registry for their values. 169 OIDs associated with discoverable protocol mechanisms SHOULD be 170 registered. These are be considered on a First Come First Served 171 with Specification Required basis. 173 OIDs associated with Standard Track mechanisms MUST be registered and 174 require Standards Action. 176 3.3 LDAP Syntaxes 178 This registry provides a listing of LDAP syntaxes [Models]. Each 179 LDAP syntax is identified by an object identifier (OID). This 180 registry is provided to allow implementors and others to locate the 181 technical specification describing a particular LDAP Syntax. 183 OIDs used to identify LDAP syntaxes SHOULD be registered. These are 184 be considered on a First Come First Served with Specification 185 Required basis. 187 OIDs associated with Standard Track LDAP syntaxes MUST be registered 188 and require Standards Action. 190 Note: unlike object classes, attribute types and various other kinds 191 of schema elements, descriptors are not used in LDAP to identify LDAP 192 syntaxes. 194 3.4. Object Identifier Descriptors 196 LDAP allows short descriptive names (or descriptors) to be used 197 instead of a numeric Object Identifier to identify select protocol 198 extensions [Protocol], schema elements [Models], LDAP URL [LDAPURL] 199 extensions, and other objects. 201 Descriptors SHOULD be registered unless in private-use name space 202 (e.g., they begin with "x-"). Descriptors defined in RFCs MUST be 203 registered. 205 While the protocol allows the same descriptor to refer to different 206 object identifiers in certain cases and the registry supports 207 multiple registrations of the same descriptor (each indicating a 208 different kind of schema element and different object identifier), 209 multiple registrations of the same descriptor are to be avoided. All 210 such registration requests require Expert Review. 212 Descriptors are restricted to strings of UTF-8 encoded Unicode 213 characters restricted by the following ABNF: 215 name = keystring 217 Descriptors are case-insensitive. 219 Multiple names may be assigned to a given OID. For purposes of 220 registration, an OID is to be represented in numeric OID form (e.g., 221 1.1.0.23.40) conforming to the ABNF: 223 numericoid = number 1*( DOT number ) 225 While the protocol places no maximum length restriction upon 226 descriptors, they should be short. Descriptors longer than 48 227 characters may be viewed as too long to register. 229 A value ending with a hyphen ("-") reserves all descriptors which 230 start with that value. For example, the registration of the option 231 "descrFamily-" reserves all options which start with "descrFamily-" 232 for some related purpose. 234 Descriptors beginning with "x-" are for Private Use and cannot be 235 registered. 237 Descriptors beginning with "e-" are reserved for experiments and will 238 be registered on a First Come First Served basis. 240 All other descriptors require Expert Review to be registered. 242 The registrant need not "own" the OID being named. 244 The OID name space is managed by The ISO/IEC Joint Technical 245 Committee 1 - Subcommittee 6. 247 3.5. AttributeDescription Options 249 An AttributeDescription [Models] can contain zero or more options 250 specifying additional semantics. An option SHALL be restricted to a 251 string UTF-8 encoded Unicode characters limited by the following 252 ABNF: 254 option = keystring 256 Options are case-insensitive. 258 While the protocol places no maximum length restriction upon option 259 strings, they should be short. Options longer than 24 characters may 260 be viewed as too long to register. 262 Values ending with a hyphen ("-") reserve all option names which 263 start with the name. For example, the registration of the option 264 "optionFamily-" reserves all options which start with "optionFamily-" 265 for some related purpose. 267 Options beginning with "x-" are for Private Use and cannot be 268 registered. 270 Options beginning with "e-" are reserved for experiments and will be 271 registered on a First Come First Served basis. 273 All other options require Standards Action or Expert Review with 274 Specification Required to be registered. 276 3.6. LDAP Message Types 278 Each protocol message is encapsulated in an LDAPMessage envelope 279 [Protocol]. The protocolOp CHOICE indicates the type of message 280 encapsulated. Each message type consists of an ASN.1 identifier in 281 the form of a keyword and a non-negative choice number. The choice 282 number is combined with the class (APPLICATION) and data type 283 (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the message's 284 encoding. The choice numbers for existing protocol messages are 285 implicit in the protocol's ASN.1 defined in [Protocol]. 287 New values will be registered upon Standards Action. 289 Note: LDAP provides extensible messages which reduces, but does not 290 eliminate, the need to add new message types. 292 3.7. LDAP Authentication Method 294 The LDAP Bind operation supports multiple authentication methods 295 [Protocol]. Each authentication choice consists of an ASN.1 296 identifier in the form of a keyword and a non-negative integer. 298 The registrant SHALL classify the authentication method usage using 299 one of the following terms: 301 COMMON - method is appropriate for common use on the 302 Internet, 303 LIMITED USE - method is appropriate for limited use, 304 OBSOLETE - method has been deprecated or otherwise found to 305 be inappropriate for any use. 307 Methods without publicly available specifications SHALL NOT be 308 classified as COMMON. New registrations of class OBSOLETE cannot be 309 registered. 311 New authentication method integers in the range 0-1023 require 312 Standards Action to be registered. New authentication method 313 integers in the range 1024-4095 require Expert Review with 314 Specification Required. New authentication method integers in the 315 range 4096-16383 will be registered on a First Come First Served 316 basis. Keywords associated with integers in the range 0-4095 SHALL 317 NOT start with "e-" or "x-". Keywords associated with integers in 318 the range 4096-16383 SHALL start with "e-". Values greater than or 319 equal to 16384 and keywords starting with "x-" are for Private Use 320 and cannot be registered. 322 Note: LDAP supports Simple Authentication and Security Layers [SASL] 323 as an authentication choice. SASL is an extensible 324 authentication framework. 326 3.8. LDAP Result Codes 328 LDAP result messages carry an resultCode enumerated value to indicate 329 the outcome of the operation [Protocol]. Each result code consists 330 of a ASN.1 identifier in the form of a keyword and a non-negative 331 integer. 333 New resultCodes integers in the range 0-1023 require Standards Action 334 to be registered. New resultCode integers in the range 1024-4095 335 require Expert Review with Specification Required. New resultCode 336 integers in the range 4096-16383 will be registered on a First Come 337 First Served basis. Keywords associated with integers in the range 338 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 339 integers in the range 4096-16383 SHALL start with "e-". Values 340 greater than or equal to 16384 and keywords starting with "x-" are 341 for Private Use and cannot be registered. 343 3.9. LDAP Search Scope 345 LDAP SearchRequest messages carry a scope enumerated value to 346 indicate the extend of search within the DIT [Protocol] Each search 347 value consists of a ASN.1 identifier in the form of a keyword and a 348 non-negative integer. 350 New scope integers in the range 0-1023 require Standards Action to be 351 registered. New scope integers in the range 1024-4095 require Expert 352 Review with Specification Required. New scope integers in the range 353 4096-16383 will be registered on a First Come First Served basis. 354 Keywords associated with integers in the range 0-4095 SHALL NOT start 355 with "e-" or "x-". Keywords associated with integers in the range 356 4096-16383 SHALL start with "e-". Values greater than or equal to 357 16384 and keywords starting with "x-" are for Private Use and cannot 358 be registered. 360 3.10. LDAP Filter Choice 362 LDAP filters are used in making assertions against an object 363 represented in the directory [Protocol]. The Filter CHOICE indicates 364 a type of assertion. Each Filter CHOICE consists of an ASN.1 365 identifier in the form of a keyword and a non-negative choice number. 366 The choice number is combined with the class (APPLICATION) and data 367 type (CONSTRUCTED or PRIMITIVE) to construct the BER tag in the 368 message's encoding. 370 New values will be registered upon Standards Action. 372 Note: LDAP provides the extensibleMatching choice which reduces, but 373 does not eliminate, the need to add new filter choices. 375 3.11. LDAP ModifyRequest Operation Type 377 The LDAP ModifyRequest carries a sequence of modification operations 378 [Protocol]. Each kind (e.g., add, delete, replace) of operation is 379 consists of a ASN.1 identifier in the form of a keyword and a 380 non-negative integer. 382 New operation integers in the range 0-1023 require Standards Action 383 to be registered. New operation integers in the range 1024-4095 384 require Expert Review with Specification Required. New integer 385 integers in the range 4096-16383 will be registered on a First Come 386 First Served basis. Keywords associated with integers in the range 387 0-4095 SHALL NOT start with "e-" or "x-". Keywords associated with 388 integers in the range 4096-16383 SHALL start with "e-". Values 389 greater than or equal to 16384 and keywords starting with "x-" are 390 for Private Use and cannot be registered. 392 3.12. LDAP authzId Prefixes 394 Authorization Identities in LDAP are strings conforming to the 395 production [AuthMeth]. This production is extensible. 396 Each new specific authorization form is identified by a prefix string 397 conforming to the following ABNF: 399 prefix = keystring COLON 400 COLON = %x3A ; COLON (":" U+003A) 402 Prefixes are case-insensitive. 404 While the protocol places no maximum length restriction upon option 405 strings, they should be short. Options longer than 12 characters may 406 be viewed as too long to register. 408 Options beginning with "x-" are for Private Use and cannot be 409 registered. 411 Options beginning with "e-" are reserved for experiments and will be 412 registered on a First Come First Served basis. 414 All other options require Standards Action or Expert Review with 415 Specification Required to be registered. 417 3.13. Directory Systems Names 419 The IANA-maintained "Directory Systems Names" registry [IANADSN] of 420 valid keywords for well known attributes was used in the LDAPv2 421 string representation of a distinguished name [RFC1779]. LDAPv2 is 422 now Historic [RFC3494]. 424 Directory systems names are not known to be used in any other 425 context. LDAPv3 uses Object Identifier Descriptors [Section 3.2] 426 (which have a different syntax than directory system names). 428 New Directory System Names will no longer be accepted. For 429 historical purposes, the current list of registered names should 430 remain publicly available. 432 4. Registration Procedure 434 The procedure given here MUST be used by anyone who wishes to use a 435 new value of a type described in Section 3 of this document. 437 The first step is for the requester to fill out the appropriate form. 438 Templates are provided in Appendix A. 440 If the policy is Standards Action, the completed form SHOULD be 441 provided to the IESG with the request for Standards Action. Upon 442 approval of the Standards Action, the IESG SHALL forward the request 443 (possibly revised) to IANA. The IESG SHALL be viewed as the owner of 444 all values requiring Standards Action. 446 If the policy is Expert Review, the requester SHALL post the 447 completed form to the mailing list for 448 public review. The review period is two (2) weeks. If a revised 449 form is later submitted, the review period is restarted. Anyone may 450 subscribe to this list by sending a request to 451 . During the review, objections may 452 be raised by anyone (including the Expert) on the list. After 453 completion of the review, the Expert, based upon public comments, 454 SHALL either approve the request and forward it to the IESG OR deny 455 the request. In either case, the Expert SHALL promptly notify the 456 requester of the action. Actions of the Expert may be appealed 457 [RFC2026]. The Expert is appointed by Applications Area Director(s). 458 The requester is viewed as the owner of values registered under 459 Expert Review. 461 If the policy is First Come First Served, the requester SHALL submit 462 the completed form directly to the IANA: . The 463 requester is viewed as the owner of values registered under First 464 Come First Served. 466 Neither the Expert nor IANA will take position on the claims of 467 copyright or trademarks issues regarding completed forms. 469 Prior to submission of the Internet Draft (I-D) to the RFC Editor but 470 after IESG review and tentative approval, the document editor SHOULD 471 revise the I-D to use registered values. 473 5. Registration Maintenance 475 This section discusses maintenance of registrations. 477 5.1. Lists of Registered Values 479 IANA makes lists of registered values readily available to the 480 Internet community on their web site: . 482 5.2. Change Control 484 The registration owner MAY update the registration subject to the 485 same constraints and review as with new registrations. In cases 486 where the owner is not unable or unwilling to make necessary updates, 487 the IESG MAY assert ownership in order to update the registration. 489 5.3. Comments 491 For cases where others (anyone other than the owner) have significant 492 objections to the claims in a registration and the owner does not 493 agree to change the registration, comments MAY be attached to a 494 registration upon Expert Review. For registrations owned by the 495 IESG, the objections SHOULD be addressed by initiating a request for 496 Expert Review. 498 The form to these requests is ad hoc, but MUST include the specific 499 objections to be reviewed and SHOULD contain (directly or by 500 reference) materials supporting the objections. 502 6. Security Considerations 503 The security considerations detailed in BCP 26 [RFC2434] are 504 generally applicable to this document. Additional security 505 considerations specific to each name space are discussed in Section 3 506 where appropriate. 508 Security considerations for LDAP are discussed in documents 509 comprising the technical specification [Roadmap]. 511 7. Acknowledgment 513 This document is a product of the IETF LDAP Revision (LDAPBIS) 514 Working Group (WG). This document is a revision of RFC 3383, also a 515 product of the LDAPBIS WG. 517 This document includes text borrowed from "Guidelines for Writing an 518 IANA Considerations Section in RFCs" [RFC2434] by Thomas Narten and 519 Harald Alvestrand. 521 8. Author's Address 523 Kurt D. Zeilenga 524 OpenLDAP Foundation 526 Email: Kurt@OpenLDAP.org 528 9. References 530 [[Note to the RFC Editor: please replace the citation tags used in 531 referencing Internet-Drafts with tags of the form RFCnnnn.]] 533 9.1. Normative References 535 [RFC1155] Rose, M. and K. McCloghrie, "Structure and 536 Identification of Management Information for TCP/IP- 537 based Internets", STD 16 (also RFC 1155), May 1990. 539 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 540 3", BCP 9 (also RFC 2026), October 1996. 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 545 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 546 Specifications: ABNF", RFC 2234, November 1997. 548 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 549 IANA Considerations Section in RFCs", BCP 26 (also RFC 550 2434), October 1998. 552 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 553 10646", RFC 3629 (also STD 63), November 2003. 555 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 556 December 2003. 558 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 559 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 560 progress. 562 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 563 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 565 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 566 Models", draft-ietf-ldapbis-models-xx.txt, a work in 567 progress. 569 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 570 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 572 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 573 draft-ietf-ldapbis-url-xx.txt, a work in progress. 575 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 576 3.2.0" is defined by "The Unicode Standard, Version 3.0" 577 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 578 as amended by the "Unicode Standard Annex #27: Unicode 579 3.1" (http://www.unicode.org/reports/tr27/) and by the 580 "Unicode Standard Annex #28: Unicode 3.2" 581 (http://www.unicode.org/reports/tr28/). 583 [X.680] International Telecommunication Union - 584 Telecommunication Standardization Sector, "Abstract 585 Syntax Notation One (ASN.1) - Specification of Basic 586 Notation", X.680(1997) (also ISO/IEC 8824-1:1998). 588 9.2. Informative References 590 [RFC1779] Kille, S., "A String Representation of Distinguished 591 Names", RFC 1779, March 1995. 593 [RFC3494] Zeilenga, K., "Lightweight Directory Access Protocol 594 version 2 (LDAPv2) to Historic Status", RFC 3494, March 595 2003. 597 [SASL] Melnikov, A. (Editor), "Simple Authentication and 598 Security Layer (SASL)", 599 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 601 [IANADSN] IANA, "Directory Systems Names", 602 http://www.iana.org/assignments/directory-system-names. 604 Appendix A. Registration Templates 606 This appendix provides registration templates for registering new 607 LDAP values. Note that more than one value may be requested by 608 extending the template by listing multiple values, or through use of 609 tables. 611 A.1. LDAP Object Identifier Registration Template 613 Subject: Request for LDAP OID Registration 615 Person & email address to contact for further information: 617 Specification: (I-D) 619 Author/Change Controller: 621 Comments: 623 (Any comments that the requester deems relevant to the request) 625 A.2. LDAP Protocol Mechanism Registration Template 627 Subject: Request for LDAP Protocol Mechanism Registration 629 Object Identifier: 631 Description: 633 Person & email address to contact for further information: 635 Usage: (One of Control or Extension or Feature or other) 637 Specification: (RFC, I-D, URI) 639 Author/Change Controller: 641 Comments: 643 (Any comments that the requester deems relevant to the request) 645 A.3. LDAP Syntax Registration Template 647 Subject: Request for LDAP Syntax Registration 649 Object Identifier: 651 Description: 653 Person & email address to contact for further information: 655 Specification: (RFC, I-D, URI) 657 Author/Change Controller: 659 Comments: 661 (Any comments that the requester deems relevant to the request) 663 A.4. LDAP Descriptor Registration Template 665 Subject: Request for LDAP Descriptor Registration 667 Descriptor (short name): 669 Object Identifier: 671 Person & email address to contact for further information: 673 Usage: (One of administrative role, attribute type, matching rule, 674 name form, object class, URL extension, or other) 676 Specification: (RFC, I-D, URI) 678 Author/Change Controller: 680 Comments: 682 (Any comments that the requester deems relevant to the request) 684 A.5. LDAP Attribute Description Option Registration Template 685 Subject: Request for LDAP Attribute Description Option Registration 687 Option Name: 689 Family of Options: (YES or NO) 691 Person & email address to contact for further information: 693 Specification: (RFC, I-D, URI) 695 Author/Change Controller: 697 Comments: 699 (Any comments that the requester deems relevant to the request) 701 A.6. LDAP Message Type Registration Template 703 Subject: Request for LDAP Message Type Registration 705 LDAP Message Name: 707 Person & email address to contact for further information: 709 Specification: (Approved I-D) 711 Comments: 713 (Any comments that the requester deems relevant to the request) 715 A.7. LDAP Authentication Method Registration Template 717 Subject: Request for LDAP Authentication Method Registration 719 Authentication Method Name: 721 Person & email address to contact for further information: 723 Specification: (RFC, I-D, URI) 725 Intended Usage: (One of COMMON, LIMITED-USE, OBSOLETE) 727 Author/Change Controller: 729 Comments: 731 (Any comments that the requester deems relevant to the request) 733 A.8. LDAP Result Code Registration Template 735 Subject: Request for LDAP Result Code Registration 737 Result Code Name: 739 Person & email address to contact for further information: 741 Specification: (RFC, I-D, URI) 743 Author/Change Controller: 745 Comments: 747 (Any comments that the requester deems relevant to the request) 749 A.8. LDAP Search Scope Registration Template 751 Subject: Request for LDAP Search Scope Registration 753 Search Scope Name: 755 Filter Scope String: 757 Person & email address to contact for further information: 759 Specification: (RFC, I-D, URI) 761 Author/Change Controller: 763 Comments: 765 (Any comments that the requester deems relevant to the request) 767 A.9. LDAP Filter Choice Registration Template 769 Subject: Request for LDAP Filter Choice Registration 771 Filter Choice Name: 773 Person & email address to contact for further information: 775 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 is to be removed by the RFC Editor before publication as 831 an RFC. 833 C.1. LDAP Syntaxes 835 See [Syntaxes]. 837 C.2. LDAP Search Scopes 839 Name URLString Value Owner Reference 840 ---------------- --------- ----- ----- ------------------- 841 baseObject base 0 IESG [Protocol][LDAPURL] 842 singleLevel one 1 IESG [Protocol][LDAPURL] 843 wholeSubtree sub 2 IESG [Protocol][LDAPURL] 845 C.3. LDAP Filter Choices 847 Name Value Owner Reference 848 ---------------- ----- ----- --------- 849 and 0 IESG [Protocol] 850 or 1 IESG [Protocol] 851 not 2 IESG [Protocol] 852 equalityMatch 3 IESG [Protocol] 853 substrings 4 IESG [Protocol] 854 greaterOrEqual 5 IESG [Protocol] 855 lessOrEqual 6 IESG [Protocol] 856 present 7 IESG [Protocol] 857 approxMatch 8 IESG [Protocol] 858 extensibleMatch 9 IESG [Protocol] 860 C.4. LDAP ModifyRequest Operations 862 Name Value Owner Reference 863 ---------------- ----- ----- --------- 864 add 0 IESG [Protocol] 865 delete 1 IESG [Protocol] 866 replace 2 IESG [Protocol] 868 C.5. LDAP authzId prefixes 870 Name Prefix Owner Reference 871 ---------------- ------ ----- --------- 872 dnAuthzId dn: IESG [AuthMeth] 873 uAuthzId u: IESG [AuthMeth] 875 Full Copyright 877 Copyright (C) The Internet Society (2004). This document is subject 878 to the rights, licenses and restrictions contained in BCP 78, and 879 except as set forth therein, the authors retain all their rights. 881 This document and the information contained herein are provided on an 882 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 883 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 884 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 885 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 886 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 887 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 889 Intellectual Property Rights 891 The IETF takes no position regarding the validity or scope of any 892 Intellectual Property Rights or other rights that might be claimed to 893 pertain to the implementation or use of the technology described in 894 this document or the extent to which any license under such rights 895 might or might not be available; nor does it represent that it has 896 made any independent effort to identify any such rights. Information 897 on the procedures with respect to rights in RFC documents can be found 898 in BCP 78 and BCP 79. 900 Copies of IPR disclosures made to the IETF Secretariat and any 901 assurances of licenses to be made available, or the result of an 902 attempt made to obtain a general license or permission for the use of 903 such proprietary rights by implementers or users of this specification 904 can be obtained from the IETF on-line IPR repository at 905 http://www.ietf.org/ipr. 907 The IETF invites any interested party to bring to its attention any 908 copyrights, patents or patent applications, or other proprietary 909 rights that may cover technology that may be required to implement 910 this standard. Please address the information to the IETF at 911 ietf-ipr@ietf.org.