idnits 2.17.1 draft-zeilenga-ldap-ext-10.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 724. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 737. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 702), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Schema designers SHOULD reuse existing schema elements where appropriate. However, any reuse MUST not alter the semantics of the element. -- 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 (2 February 2006) is 6651 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 181, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Missing Reference: 'Filter' is mentioned on line 217, but not defined == Missing Reference: 'Section 4' is mentioned on line 382, but not defined == Missing Reference: 'Appendix B' is mentioned on line 383, but not defined == Unused Reference: 'Features' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'Syntaxes' is defined on line 630, but no explicit reference was found in the text == Unused Reference: 'LDAPprep' is defined on line 633, but no explicit reference was found in the text == Unused Reference: 'Filters' is defined on line 644, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3642 ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) ** 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-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-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- 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-strprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPprep' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BCP64bis' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' -- Possible downref: Non-RFC (?) normative reference: ref. 'FORMAL' -- No information found for draft-greenblatt-ldapext-style-xx - is the name correct? -- No information found for draft-ietf-tls-rfc2246-bis-xx - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 11 warnings (==), 33 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 2 February 2006 6 Considerations for LDAP Extensions 7 9 Status of this Memo 11 This document is intended to be, after appropriate review and 12 revision, submitted to the RFC Editor for publication as a BCP. 13 Distribution of this memo is unlimited. Technical discussion of this 14 document will take place on the IETF LDAP Extensions mailing list 15 . Please send editorial comments directly to the 16 author . 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware have 20 been or will be disclosed, and any of which he or she becomes aware 21 will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Copyright (C) The Internet Society (2006). All Rights Reserved. 40 Please see the Full Copyright section near the end of this document 41 for more information. 43 Abstract 45 The Lightweight Directory Access Protocol (LDAP) is extensible. It 46 provides mechanisms for adding new operations, extending existing 47 operations, and expanding user and system schema. This document 48 discusses considerations for designers of LDAP extensions. 50 Table of Contents 52 [[Page numbers to be filled in by RFC-Editor]] 54 Status of this Memo 55 Abstract 56 Table of Contents 57 1. Background and Intended Use 58 2. General Considerations 59 2.1. Scope of Extension 60 2.2. Interaction between extensions 61 2.3. Discovery Mechanism 62 2.4. International Considerations 63 2.5. use of Basic Encoding Rules 64 2.6. Use of Formal Languages 65 2.7. Examples 66 2.8. Registratin of Protocol Values 67 3. LDAP Operation Extensions 68 3.1. Controls 69 3.2. Extended Operations 70 3.3. Intermediate Responses 71 3.4. Unsolicited Notifications 72 4. Extending LDAP ASN.1 definition 73 4.1. Result Codes 74 4.2. LDAP Message Types 75 4.3. Authentication Methods 76 4.4. General ASN.1 Extensibility 77 5. Schema Extensions 78 5.1. LDAP Syntaxes 79 5.2. Matching Rules 80 5.3. Attribute Types 81 5.4. Object Classes 82 6. Other Extension Mechanisms 83 6.1. Attribute Description Options 84 6.2. Authorization Identities 85 6.3. LDAP URL Extensions 86 7. Security Considerations 87 8. Acknowledgements 88 9. Author's Address 89 10. References 90 Full Copyright 91 Intellectual Property Rights 93 1. Background and Intended Use 95 The Lightweight Directory Access Protocol (LDAP) [Roadmap] is an 96 extensible protocol. 98 LDAP allows for new operations to be added and existing operations to 99 be enhanced [Protocol]. 101 LDAP allows additional schema to be defined [Models]. This can 102 include additional object classes, attribute types, matching rules, 103 additional syntaxes, and other elements of schema. LDAP provides an 104 ability to extend attribute types with options [Models]. 106 LDAP supports a Simple Authentication and Security Layer (SASL) 107 authentication method [Protocol][AuthMeth]. SASL [SASL] is 108 extensible. LDAP may be extended to support additional authentication 109 methods [Protocol]. 111 LDAP supports establishment of Transport Layer Security (TLS) 112 [Protocol][AuthMeth]. TLS [TLS] is extensible. 114 LDAP has an extensible Uniform Resource Locator (URL) format 115 [LDAPURL]. 117 Lastly, LDAP allows for certain extensions to the protocol's Abstract 118 Syntax Notation - One (ASN.1) [X.680] definition to be made. This 119 facilitate a wide range of protocol enhancements. For example, new 120 result codes needed to support extensions to be added through 121 extension of the protocol's ASN.1 definition. 123 This document describes practices which engineers should consider when 124 designing extensions to LDAP. 126 1.1. Terminology 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in BCP 14 [RFC2119]. In 131 this document, "the specification" as used by BCP 14 refers to the 132 engineering of LDAP extensions. 134 The term "Request Control" refers to a control attached to a client 135 generated message sent to a server. The term "Response Control" 136 refers to a control attached to a server generated message sent to a 137 client. 139 DIT stands for Directory Information Tree. 140 DSA stands for Directory System Agent, a server. 141 DSE stands for DSA-Specific Entry. 142 DUA stands for Directory User Agent, a client. 143 DN stands for Distinguished Name. 145 2. General Considerations 147 2.1 Scope of Extension 149 Mutually agreeing peers may, within the confines of an extension, 150 agree to significant changes in protocol semantics. However, 151 designers MUST consider the impact of an extension upon protocol peers 152 which have not agreed to implement, or otherwise recognize and 153 support, the extension. Extensions MUST be "truly optional" 154 [RFC2119]. 156 2.2. Interaction between extensions 158 Designers SHOULD consider how extensions they engineer interaction 159 with other extensions. 161 Designers SHOULD consider extensibility of extensions they specify. 162 Extensions to LDAP SHOULD themselves be extensible. 164 Except where stated otherwise, extensibility is implied. 166 2.3. Discovery Mechanism 168 Extensions SHOULD provide adequate discovery mechanisms. 170 As LDAP design is based upon the client-request/server-response 171 paradigm, the general discovery approach is for the client to discover 172 the capabilities of the server before utilizing a particular 173 extension. Commonly, this discovery involves querying the root DSE 174 and/or other DSEs for operational information associated with the 175 extension. LDAP provides no mechanism for a server to discover the 176 capabilities of a client. 178 The 'supportedControl' attribute [Models] is used to advertised 179 supported controls. The 'supportedExtension' attribute [Models] is 180 used to advertised supported extended operations. The 181 'supportedFeatures' attribute [RFC3674] is used to advertise features. 182 Other root DSE attributes MAY be defined to advertise other 183 capabilities. 185 2.4. Internationalization Considerations 187 LDAP is designed to support the full Unicode [Unicode] repertory of 188 characters. Extensions SHOULD avoid unnecessarily restricting 189 applications to subsets of Unicode (e.g., Basic Multilingual Plane, 190 ISO 8859-1, ASCII, Printable String). 192 LDAP Language Tag options [RFC3866] provides a mechanism for tagging 193 text (and other) values with language information. Extensions which 194 define attribute types SHOULD allow use of language tags with these 195 attributes. 197 2.5. Use of the Basic Encoding Rules 199 Numerous elements of LDAP are described using ASN.1 [X.680] and are to 200 encoded using a particular subset [Protocol, Section 5.2] of the Basic 201 Encoding Rules (BER) [X.690]. To allow reuse of parsers/generators 202 used in implementing the LDAP "core" technical specification 203 [Roadmap], it is RECOMMENDED that extension elements (e.g. extension 204 specific contents of controlValue, requestValue, responseValue fields) 205 described by ASN.1 and encoded using BER be subjected to the 206 restrictions of [Protocol, Section 5.2]. 208 2.6. Use of Formal Languages 210 Formal languages SHOULD be used in specifications in accordance with 211 IESG guidelines [FORMAL]. 213 2.7. Examples 215 Example DN strings SHOULD conform to the syntax defined in [LDAPDN]. 216 Example LDAP filter strings SHOULD conform to the syntax defined in 217 [Filter]. Example LDAP URLs SHOULD conform to the syntax defined in 218 [LDAPURL]. Entries SHOULD be represented using LDIF [RFC2849]. 220 2.8. Registration of Protocol Values 222 Designers SHALL register protocol values of their LDAP extensions in 223 accordance with BCP 64 [BCP64bis]. Specifications which create new 224 extensible protocol elements SHALL extend existing or establish new 225 registries for values of these elements in accordance with BCP 64 226 [BCP64bis] and BCP 26 [RFC2434]. 228 3. LDAP Operation Extensions 230 Extensions SHOULD use controls in defining extensions which complement 231 existing operations. Where the extension to be defined does not 232 complement an existing operation, designers SHOULD consider defining 233 an extended operation instead. 235 For example, a subtree delete operation could be designed as either an 236 extension of the delete operation or as a new operation. As the 237 feature complements the existing delete operation, use of the control 238 mechanism to extend the delete operation is likely more appropriate. 240 As a counter (and contrived) example, a locate services operation (an 241 operation which would return for a DN a set of LDAP URLs to services 242 which may hold the entry named by this DN) could be designed as either 243 a search operation or a new operation. As the feature doesn't 244 complement the search operation (e.g., the operation is not contrived 245 to search for entries held in the Directory Information Tree), it is 246 likely more appropriate to define a new operation using the extended 247 operation mechanism. 249 3.1. Controls 251 Controls [Protocol, Section 4.1.11] are the RECOMMENDED mechanism for 252 extending existing operations. The existing operation can be a base 253 operation defined in [Protocol] (e.g., search, modify, etc.) or an 254 extended operation (e.g. Start TLS [Protocol], Password Modify 255 [RFC3062]), or an operation defined as an extension to a base or 256 extended operation. 258 Extensions SHOULD NOT return Response controls unless the server has 259 specific knowledge that the client can make use of the control. 260 Generally, the client requests the return of a particular response 261 control by providing a related request control. 263 An existing operation MAY be extended to return IntermediateResponse 264 messages [Protocol, Section 4.13]. 266 Specifications of controls SHALL NOT attach additional semantics to 267 criticality of controls beyond those defined in [Protocol, Section 268 4.1.11]. A specification MAY mandate the criticality take on a 269 particular value (e.g., TRUE or FALSE) where appropriate. 271 3.1.1 Extending Bind Operation with Controls 273 Controls attached to the request and response messages of a Bind 274 Operation [Protocol] are not protected by any security layers 275 established by that Bind operation. 277 Specifications detailing controls extending the Bind operation SHALL 278 detail that the Bind negotiated security layers do not protect the 279 information contained in these controls and SHALL detail how the 280 information in these controls is protected or why the information does 281 not need protection. 283 It is RECOMMENDED that designers consider alternative mechanisms for 284 providing the function. For example, an extended operation issued 285 subsequent to the Bind operation, hence protected by the security 286 layers negotiated by the Bind operation, might be used to provided the 287 desired function. 289 Additionally, designers of Bind control extensions MUST also consider 290 how the controls' semantics interact with individual steps of a multi- 291 step Bind operation. It is noted that some steps are optional and 292 hence may require special attention in the design. 294 3.1.2 Extending the Start TLS Operation with Controls 296 Controls attached to the request and response messages of a Start TLS 297 Operation [Protocol] are not protected by the security layers 298 established by the Start TLS operation. 300 Specifications detailing controls extending the Start TLS operation 301 SHALL detail that the Start TLS negotiated security layers do not 302 protect the information contained in these controls and SHALL detail 303 how the information in these controls is protected or why the 304 information does not need protection. 306 It is RECOMMENDED that designers consider alternative mechanisms for 307 providing the function. For example, an extended operation issued 308 subsequent to the Start TLS operation, hence protected by the security 309 layers negotiated by the Start TLS operation, might be used to 310 provided the desired function. 312 3.1.3 Extending the Search Operation with Controls 313 The Search operation processing has two distinct phases: 314 - finding the base object; and 315 - searching for objects at or under that base object. 317 Specifications of controls extending the Search Operation should 318 clearly state in which phase(s) the control's semantics apply. 319 Semantics of controls which are not specific to the Search Operation 320 SHOULD apply in the finding phase. 322 3.1.4 Extending the Update Operations with Controls 324 Update operations have properties of atomicity, consistency, isolation, 325 and durability ([ACID]). 326 - atomicity: all or none of the DIT changes requested are made, 327 - consistency: the resulting DIT state must be conform to schema and 328 other constraints, 329 - isolation: intermediate states are not exposed, 330 - durability: the resulting DIT state is preserved until 331 subsequently updated. 333 When defining a control which requests additional (or other) DIT 334 changes be made to the DIT, these additional changes SHOULD NOT be 335 treated as part of a separate transaction. The specification MUST be 336 clear as whether the additional DIT changes are part of the same or a 337 separate transaction as the DIT changes expressed in the request of 338 the base operation. 340 When defining a control which requests additional (or other) DIT 341 changes be made to the DIT, the specification MUST be clear as to the 342 order in which these and the base changes are to be applied to the 343 DIT. 345 3.1.4 Extending the Response-less Operations with Controls 347 The Abandon and Unbind operations do not include a response message. 348 For this reason, specifications for controls designed to be attached 349 to Abandon and Unbind requests SHOULD mandate that the control's 350 criticality be FALSE. 352 3.2. Extended Operations 354 Extended Operations [Protocol, Section 4.12] is the RECOMMENDED 355 mechanism for defining new operations. An extended operation consists 356 of an ExtendedRequest message, zero or more IntermediateResponse 357 messages, and an ExtendedResponse message. 359 3.3. Intermediate Responses 361 Extensions SHALL use IntermediateResponse messages instead of 362 ExtendedResponse messages to return intermediate results. 364 3.4. Unsolicited Notifications 366 Unsolicited notifications [Protocol, Section 4.4] offer a capability 367 for the server to notify the client of events not associated with 368 operation currently being processed. 370 Extensions SHOULD be designed such that unsolicited notifications are 371 not be returned unless the server has specific knowledge that the 372 client can make use of the notification. Generally, the client 373 requests the return of particular unsolicited notification by 374 performing a related extended operation. 376 For example, a time hack extension could be designed to return 377 unsolicited notifications at regular intervals which were enabled by 378 an extended operation (which possibly specified the desired interval). 380 4. Extending LDAP ASN.1 definition 382 LDAP allows limited extension [Protocol, Section 4] of the LDAP ASN.1 383 definition [Protocol, Appendix B] to be made. 385 4.1. Result Codes 387 Extensions which specify new operations or enhance existing operations 388 often need to define new result codes. The extension SHOULD be 389 designed such that a client has a reasonably clear indication of the 390 nature of the successful or non-successful result. 392 Extensions SHOULD use existing result codes to indicate conditions 393 which are consistent with the intended meaning [Protocol][X.511] of 394 these codes. Extensions MAY introduce new result codes [BCP64bis] 395 where no existing result code provides an adequate indication of the 396 nature of the result. 398 Extensions SHALL NOT disallow nor otherwise restrict the return of 399 general service result codes, especially those reporting a protocol, 400 service, or security problem, or indicating the server is unable or 401 unwilling to complete the operation. 403 4.2. LDAP Message Types 405 While extensions can specify new types of LDAP messages by extending 406 the protocolOp CHOICE of the LDAPMessage SEQUENCE, this is generally 407 unnecessary and inappropriate. Existing operation extension 408 mechanisms (e.g., extended operations, unsolicited notifications, and 409 intermediate responses) SHOULD be used instead. However, there may be 410 cases where an extension does not fit well into these mechanisms. In 411 such cases, a new extension mechanism SHOULD be defined which can be 412 used by multiple extensions which have similar needs. 414 4.3. Authentication Methods 416 The Bind operation currently supports two authentication methods, 417 simple and SASL. SASL [SASL] is an extensible authentication 418 framework used by multiple application-level protocols (e.g. BEEP, 419 IMAP, SMTP). It is RECOMMENDED that new authentication processes be 420 defined as SASL mechanisms. New LDAP authentication methods MAY be 421 added to support new authentication frameworks. 423 The Bind operation primary function is to establish the LDAP 424 association [AuthMeth]. No other operation SHALL be defined (or 425 extended) to establish the LDAP association. However, other 426 operations MAY be defined to establish other security associations 427 (e.g., IPSEC). 429 4.4. General ASN.1 extensibility 431 Section 4 of [Protocol] states: 432 In order to support future extensions to this protocol, 433 extensibility is implied where it is allowed per ASN.1 (i.e. 434 sequence, set, choice, and enumerated types are extensible). In 435 addition, ellipses (...) have been supplied in ASN.1 types that 436 are explicitly extensible as discussed in [BCP64bis]. Because of 437 the implied extensibility, clients and servers MUST (unless 438 otherwise specified) ignore trailing SEQUENCE components whose 439 tags they do not recognize. 441 Designers SHOULD avoid introducing extensions which rely on 442 unsuspecting implementations to ignore trailing components of SEQUENCE 443 whose tags they do not recognize. 445 5. Schema Extensions 447 Extensions defining LDAP schema elements SHALL provide schema 448 definitions conformant with syntaxes defined in [Models, Section 4.1]. 450 While provided definitions MAY be reformatted (line wrapped) for 451 readability, this SHALL be noted in the specification. 453 For definitions allow a NAME field, new schema elements SHOULD provide 454 one and only one name. The name SHOULD be short. 456 Each schema definition allows a DESC field. The DESC field, if 457 provided, SHOULD contain a short descriptive phrase. The DESC field 458 MUST be regarded as informational. That is, the specification MUST be 459 written such that its interpretation is the same with and without the 460 provided DESC fields. 462 The extension SHALL NOT mandate that implementations provide the same 463 DESC field in schema they publish. Implementors MAY replace or remove 464 the DESC field. 466 Published schema elements SHALL NOT be redefined. Replacement schema 467 elements (new OIDs, new NAMEs) SHOULD be defined as needed. 469 Schema designers SHOULD reuse existing schema elements where 470 appropriate. However, any reuse MUST not alter the semantics of the 471 element. 473 5.1. LDAP Syntaxes 475 Each LDAP syntax is defined in terms of ASN.1 [X.680]. Each extension 476 detailing an LDAP syntax MUST specify the ASN.1 data definition 477 associated with the syntax. A distinct LDAP syntax SHOULD be created 478 for each distinct ASN.1 data definition (including constraints). 480 Each LDAP syntax SHOULD have a string encoding defined for it. It is 481 RECOMMENDED that this string encoding be restricted to a UTF-8 482 [RFC3629] encoded Unicode [Unicode] characters. Use of Generic String 483 Encoding Rules (GSER) [RFC3641][RFC3642] or other generic string 484 encoding rules to provide string encodings for complex ASN.1 data 485 definitions is RECOMMENDED. Otherwise, it is RECOMMENDED that the 486 string encoding be described using a formal language (e.g., ABNF 487 [ABNF]). Formal languages SHOULD be used in specifications in 488 accordance with IESG guidelines [FORMAL]. 490 If no string encoding is defined, the extension SHALL specify how the 491 transfer encoding is to be indicated. Generally, the extension SHOULD 492 mandate use of ;binary or other transfer encoding option. 494 5.2. Matching Rules 495 Three basic kinds of matching rules (e.g., EQUALITY, ORDERING, and 496 SUBSTRING) may be associated with an attribute type. In addition, 497 LDAP provides an extensible matching rule mechanism. 499 The matching rule specification SHOULD detail which kind of matching 500 rule it is and SHOULD describe which kinds of values it can be used 501 with. 503 In addition to requirements stated in the LDAP technical 504 specification, equality matching rules SHOULD be commutative. 506 5.3. Attribute Types 508 Designers SHOULD carefully consider how the structure of values is to 509 restricted. Designers SHOULD consider that servers will only enforce 510 constraints of the attribute's syntax. That is, an attribute intended 511 to hold URIs, but which has directoryString syntax, is not restricted 512 to values which are URIs. 514 Designers SHOULD carefully consider which matching rules, if any, are 515 appropriate for the attribute type. Matching rules specified for an 516 attribute type MUST be compatible with the attribute type's syntax. 518 Extensions specifying operational attributes MUST detail how servers 519 are to maintain and/or utilize values of each operational attribute. 521 5.4. Object Classes 523 Designers SHOULD carefully consider whether each attributes of an 524 object class is required ("MUST") or allowed ("MAY"). 526 Extensions specifying object classes which allow (or require) 527 operational attributes MUST specify how servers are to maintain and/or 528 utilize entries belonging to these object classes. 530 6. Other Extension Mechanisms 532 6.1. Attribute Description Options 534 Each option is identified by a string of letters, numbers, and 535 hyphens. This string SHOULD be short. 537 6.2. Authorization Identities 538 Extensions interacting with authorization identities SHALL support the 539 LDAP authzId format [AuthMeth]. The authzId format is extensible. 541 6.3. LDAP URL Extensions 543 LDAP URL extensions are identified by a short string, a descriptor. 544 Like other descriptors, the string SHOULD be short. 546 7. Security Considerations 548 LDAP does not place undue restrictions on the kinds of extensions 549 which can be implemented. While this document attempts to outline 550 some specific issues which designers need to consider, it is not (and 551 cannot be) all encompassing. Designers MUST do their own evaluation 552 of the security considerations applicable to their extension. 554 Designers MUST NOT the assume that the LDAP "core" technical 555 specification [Roadmap] adequately addresses the specific concerns 556 surrounding their extension nor assume that their extension has no 557 specific concerns. 559 Extensions specification, however, SHOULD note whether or not security 560 considerations specific to the feature they are extending, as well as 561 general LDAP security considerations, apply to the extension. 563 8. Acknowledgments 565 The author thanks the IETF LDAP community for their thoughtful 566 comments. 568 This work builds upon "LDAP Extension Style Guide" [GUIDE] by Bruce 569 Greenblatt. 571 9. Author's Address 573 Kurt D. Zeilenga 574 OpenLDAP Foundation 576 Email: Kurt@OpenLDAP.org 578 10. References 580 [[Note to the RFC Editor: please replace the citation tags used in 581 referencing Internet-Drafts with tags of the form RFCnnnn where 582 possible.]] 584 10.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 589 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 590 IANA Considerations Section in RFCs", BCP 26 (also RFC 591 2434), October 1998. 593 [RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - 594 Technical Specification", RFC 2849, June 2000. 596 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 597 10646", RFC 3629 (also STD 63), November 2003. 599 [RFC3641] Legg, S., "Generic String Encoding Rules for ASN.1 600 Types", RFC 3641, October 2003. 602 [RFC3642] Legg, S., "Common Elements of GSER Encodings", RFC 3642, 603 October 2003. 605 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 606 December 2003. 608 [RFC3866] Zeilenga, K., Ed., "Language Tags and Ranges in the 609 Lightweight Directory Access Protocol (LDAP)", RFC 3866, 610 July 2004. 612 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 613 Specifications: ABNF", RFC 4234, October 2005. 615 [Roadmap] Zeilenga, K. (editor), "LDAP: Technical Specification 616 Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 617 progress. 619 [Models] Zeilenga, K. (editor), "LDAP: Directory Information 620 Models", draft-ietf-ldapbis-models-xx.txt, a work in 621 progress. 623 [Protocol] Sermersheim, J. (editor), "LDAP: The Protocol", 624 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 626 [AuthMeth] Harrison, R. (editor), "LDAP: Authentication Methods and 627 Connection Level Security Mechanisms", 628 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 630 [Syntaxes] Legg, S. (editor), "LDAP: Syntaxes and Matching Rules", 631 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 633 [LDAPprep] Zeilenga, K., "LDAP: Internationalized String 634 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work 635 in progress. 637 [LDAPDN] Zeilenga, K. (editor), "LDAP: String Representation of 638 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a 639 work in progress. 641 [LDAPURL] Smith, M. (editor), "LDAP: Uniform Resource Locator", 642 draft-ietf-ldapbis-url-xx.txt, a work in progress. 644 [Filters] Smith, M. (editor), LDAPbis WG, "LDAP: String 645 Representation of Search Filters", 646 draft-ietf-ldapbis-filter-xx.txt, a work in progress. 648 [BCP64bis] Zeilenga, K., "IANA Considerations for LDAP", 649 draft-ietf-ldapbis-bcp64-xx.txt, a work in progress. 651 [SASL] Melnikov, A. (Editor), "Simple Authentication and 652 Security Layer (SASL)", 653 draft-ietf-sasl-rfc2222bis-xx.txt, a work in progress. 655 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 656 3.2.0" is defined by "The Unicode Standard, Version 3.0" 657 (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 658 as amended by the "Unicode Standard Annex #27: Unicode 659 3.1" (http://www.unicode.org/reports/tr27/) and by the 660 "Unicode Standard Annex #28: Unicode 3.2" 661 (http://www.unicode.org/reports/tr28/). 663 [FORMAL] IESG, "Guidelines for the use of formal languages in 664 IETF specifications", 665 , 666 2001. 668 [X.511] International Telecommunication Union - 669 Telecommunication Standardization Sector, "The 670 Directory: Abstract Service Definition", X.511(1993) 671 (also ISO/IEC 9594-3:1993). 673 [X.680] International Telecommunication Union - 674 Telecommunication Standardization Sector, "Abstract 675 Syntax Notation One (ASN.1) - Specification of Basic 676 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 678 [X.690] International Telecommunication Union - 679 Telecommunication Standardization Sector, "Specification 680 of ASN.1 encoding rules: Basic Encoding Rules (BER), 681 Canonical Encoding Rules (CER), and Distinguished 682 Encoding Rules (DER)", X.690(2002) (also ISO/IEC 683 8825-1:2002). 685 10.2. Informative References 687 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 688 RFC 3062, February 2000. 690 [ACID] Section 4 of ISO/IEC 10026-1:1992. 692 [GUIDE] Greenblatt, B., "LDAP Extension Style Guide", 693 draft-greenblatt-ldapext-style-xx.txt, an (expired) work 694 in progress. 696 [TLS] Dierks, T. and, E. Rescorla, "The TLS Protocol Version 697 1.1", draft-ietf-tls-rfc2246-bis-xx.txt, a work in 698 progress. 700 Full Copyright 702 Copyright (C) The Internet Society (2006). 704 This document is subject to the rights, licenses and restrictions 705 contained in BCP 78, and except as set forth therein, the authors 706 retain all their rights. 708 This document and the information contained herein are provided on an 709 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 710 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 711 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 712 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 713 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 714 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 716 Intellectual Property Rights 717 The IETF takes no position regarding the validity or scope of any 718 Intellectual Property Rights or other rights that might be claimed to 719 pertain to the implementation or use of the technology described in 720 this document or the extent to which any license under such rights 721 might or might not be available; nor does it represent that it has 722 made any independent effort to identify any such rights. Information 723 on the procedures with respect to rights in RFC documents can be found 724 in BCP 78 and BCP 79. 726 Copies of IPR disclosures made to the IETF Secretariat and any 727 assurances of licenses to be made available, or the result of an 728 attempt made to obtain a general license or permission for the use of 729 such proprietary rights by implementers or users of this specification 730 can be obtained from the IETF on-line IPR repository at 731 http://www.ietf.org/ipr. 733 The IETF invites any interested party to bring to its attention any 734 copyrights, patents or patent applications, or other proprietary 735 rights that may cover technology that may be required to implement 736 this standard. Please address the information to the IETF at 737 ietf-ipr@ietf.org.