idnits 2.17.1 draft-zeilenga-ldap-rfc2596-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 == Line 687 has weird spacing: '...for the purpo...' == 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 (15 February 2004) is 7376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3674' is mentioned on line 516, but not defined ** Obsolete undefined reference: RFC 3674 (Obsoleted by RFC 4512) == Unused Reference: 'Features' is defined on line 607, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 3066 (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 3377 (Obsoleted by RFC 4510) ** Obsolete normative reference: RFC 3674 (ref. 'Features') (Obsoleted by RFC 4512) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' -- Obsolete informational reference (is this intentional?): RFC 3383 (Obsoleted by RFC 4520) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 15 February 2004 5 Obsoletes: RFC 2596 7 Language Tags and Ranges in LDAP 8 draft-zeilenga-ldap-rfc2596-05.txt 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extensions (LDAPEXT) mailing 19 list . Please send editorial comments directly to 20 the document editor . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 . The list of 32 Internet-Draft Shadow Directories can be accessed at 33 . 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Please see the Full Copyright section near the end of this document 38 for more information. 40 Abstract 42 It is often desirable to to be able to indicate the natural language 43 associated with values held in a directory and to be able to query the 44 directory for values which fulfill the user's language needs. This 45 document details the use of Language Tags and Ranges in the 46 Lightweight Directory Access Protocol (LDAP). 48 Conventions 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in BCP 14 [RFC2119]. 54 1. Background and Intended Use 56 The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a 57 means for clients to interrogate and modify information stored in a 58 distributed directory system. The information in the directory is 59 maintained as attributes of entries. Most of these attributes have 60 syntaxes which are human-readable strings, and it is desirable to be 61 able to indicate the natural language associated with attribute 62 values. 64 This document describes how language tags and ranges [RFC3066] are 65 carried in LDAP and are to be interpreted by LDAP implementations. 66 All LDAP implementations MUST be prepared to accept language tags and 67 ranges. 69 This document replaces RFC 2596. Appendix A summaries changes made 70 since RFC 2596. 72 Appendix B discusses differences from X.500(1997) "contexts" 73 mechanism. 75 Appendix A and B are provided for informational purposes only. 77 The remainder of this section provides a summary of Language Tags, 78 Language Ranges, and Attribute Descriptions. 80 1.1. Language Tags 82 Section 2 of BCP 47 [RFC3066] describes the language tag format which 83 is used in LDAP. Briefly, it is a string of [ASCII] letters and 84 hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags 85 are case insensitive. That is, the language tag "en-us" is the same 86 as "EN-US". 88 Section 2 of this document details use of language tags in LDAP. 90 1.2. Language Ranges 92 Section 2.5 of BCP 47 [RFC3066] describes the language ranges. 94 Language ranges are used to specify sets of language tags. 96 A language range matches a language tag if it is exactly equal to the 97 tag, or if it is exactly equal to a prefix of the tag such that the 98 first character following the prefix is "-". That is, the language 99 range "de" matches the language tags "de" and "de-CH" but not "den". 100 The special language range "*" matches all language tags. 102 Due to attribute description option naming restrictions in LDAP, this 103 document defines a different language range syntax. However, the 104 semantics of language ranges in LDAP is consistent with BCP 47. 106 Section 3 of this document details use of language ranges in LDAP. 108 1.3. Attribute Descriptions 110 This section provides an overview of attribute descriptions in LDAP. 111 LDAP attributes and attribute descriptions are defined in [RFC2251]. 113 An attribute consists of a type, a set of zero or more associated 114 tagging options, and a set of one or more values. The type and the 115 options are combined into the AttributeDescription. 116 AttributeDescriptions can also contain options which are not part of 117 the attribute, but indicate some other function (such as range 118 assertion or transfer encoding). 120 An AttributeDescription with one or more tagging options is a direct 121 subtype of each AttributeDescription of the same type with all but one 122 of the tagging options. If the AttributeDescription's type is a 123 direct subtype of some other type, then the AttributeDescription is 124 also a direct subtype of the AttributeDescription which consists of 125 the supertype and all of the tagging options. That is, 126 "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and 127 "name;x-bar;x-foo". Note that "CN" is a subtype of "name". 129 2. Use of Language Tags in LDAP 131 This section describes how LDAP implementations MUST interpret 132 language tags in performing operations. 134 Servers which support storing attributes with language tag options in 135 the Directory Information Tree (DIT) SHOULD allow any attribute type 136 it recognizes that has the Directory String, IA5 String, or other 137 textual string syntaxes to have language tag options associated with 138 it. Servers MAY allow language options to be associated with other 139 attributes types. 141 Clients SHOULD NOT assume servers are capable of storing attributes 142 with language tags in the directory. 144 Implementations MUST NOT otherwise interpret the structure of the tag 145 when comparing two tag, and MUST treat them simply as strings of 146 characters. Implementations MUST allow any arbitrary string which 147 conforms to the syntax defined in BCP 47 [RFC3066] to be used as a 148 language tag. 150 2.1. Language Tag Options 152 A language tag option associates a natural language with values of an 153 attribute. An attribute description may contain multiple language tag 154 options. An entry may contain multiple attributes with same attribute 155 type but different combinations of language tag (and other) options. 157 A language tag option conforms to the following ABNF [RFC2234]: 159 language-tag-option = "lang-" Language-Tag 161 where the Language-Tag production is as defined in BCP 47 [RFC3066]. 162 This production and those it imports from [RFC2234] are provided here 163 for convenience: 165 Language-Tag = Primary-subtag *( "-" Subtag ) 167 Primary-subtag = 1*8ALPHA 169 Subtag = 1*8(ALPHA / DIGIT) 171 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 173 DIGIT = %x30-39 ; 0-9 175 A language tag option is a tagging option. A language tag option has 176 no effect on the syntax of the attribute's values nor their transfer 177 encoding. 179 Examples of valid AttributeDescription: 181 givenName;lang-en-US 182 CN;lang-ja 183 SN;lang-de;lang-gem-PFL 184 O;lang-i-klingon;x-foobar 185 description;x-foobar 186 CN 188 Notes: The last two have no language tag options. The x-foobar option 189 is fictious and used for example purposes. 191 2.2. Search Filter 193 If language tag options are present in an AttributeDescription in an 194 assertion, then for each entry within scope, the values of each 195 attribute whose AttributeDescription consists of the same attribute 196 type or its subtypes and contains each of the presented (and possibly 197 other) options is to be matched. 199 Thus, for example, a filter of an equality match of type 200 "name;lang-en-US" and assertion value "Billy Ray", against the 201 following directory entry: 203 dn: SN=Ray,DC=example,DC=com 204 objectClass: person DOES NOT MATCH (wrong type) 205 objectClass: extensibleObject DOES NOT MATCH (wrong type) 206 name;lang-en-US: Billy Ray MATCHES 207 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 208 CN;lang-en-US: Billy Ray MATCHES 209 CN;lang-en-US;x-foobar: Billy Ray MATCHES 210 CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-) 211 CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) 212 name: Billy Ray DOES NOT MATCH (no lang-) 213 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 214 SN: Ray DOES NOT MATCH (no lang-, 215 wrong value) 217 Note that "CN" and "SN" are subtypes of "name". 219 It is noted that providing a language tag option in a search filter 220 AttributeDescription will filter out desirable values where the tag 221 does not match exactly. For example, the filter (name;lang-en=Billy 222 Ray) does NOT match the attribute "name;lang-en-US: Billy Ray". 224 If the server does not support storing attributes with language tag 225 options in the DIT, then any assertion which includes a language tag 226 option will not match as such it is an unrecognized attribute type. 227 No error would be returned because of this; a presence assertion would 228 evaluate to FALSE and all other assertions to Undefined. 230 If no options are specified in the assertion, then only the base 231 attribute type and the assertion value need match the value in the 232 directory. 234 Thus, for example, a filter of an equality match of type "name" and 235 assertion value "Billy Ray", against the following directory entry: 237 dn: SN=Ray,DC=example,DC=com 238 objectClass: person DOES NOT MATCH (wrong type) 239 objectClass: extensibleObject DOES NOT MATCH (wrong type) 240 name;lang-en-US: Billy Ray MATCHES 241 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 242 CN;lang-en-US;x-foobar: Billy Ray MATCHES 243 CN;lang-en;x-foobar: Billy Ray MATCHES 244 CN;x-foobar: Billy Ray MATCHES 245 name: Billy Ray MATCHES 246 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 247 SN: Ray DOES NOT MATCH (wrong value) 249 2.3. Requested Attributes in Search 251 Clients can provide language tag options in each AttributeDescription 252 in the requested attribute list in a search request. 254 If language tag options are provided in an attribute description, then 255 only attributes in a directory entry whose attribute descriptions have 256 the same attribute type or its subtype and contains each of the 257 presented (and possibly other) language tag options are to be 258 returned. Thus if a client requests just the attribute 259 "name;lang-en", the server would return "name;lang-en" and 260 "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr". 262 Clients can provide in the attribute list multiple 263 AttributeDescriptions which have the same base attribute type but 264 different options. For example, a client could provide both 265 "name;lang-en" and "name;lang-fr", and this would permit an attribute 266 with either language tag option to be returned. Note there would be 267 no need to provide both "name" and "name;lang-en" since all subtypes 268 of name would match "name". 270 If a server does not support storing attributes with language tag 271 options in the DIT, then any attribute descriptions in the list which 272 include language tag options are to be ignored, just as if they were 273 unknown attribute types. 275 If a request is made specifying all attributes or an attribute is 276 requested without providing a language tag option, then all attribute 277 values regardless of their language tag option are returned. 279 For example, if the client requests a "description" attribute, and a 280 matching entry contains the following attributes: 282 objectClass: top 283 objectClass: organization 284 O: Software GmbH 285 description: software products 286 description;lang-en: software products 287 description;lang-de: Softwareprodukte 289 The server would return: 291 description: software products 292 description;lang-en: software products 293 description;lang-de: Softwareprodukte 295 2.4. Compare 297 Language tag options can be present in an AttributeDescription used in 298 a compare request AttributeValueAssertion. This is to be treated by 299 servers the same as the use of language tag options in a search filter 300 with an equality match, as described in Section 2.2. If there is no 301 attribute in the entry with the same attribute type or its subtype and 302 and contains each of the presented (or possibly other) language tag 303 options, the noSuchAttributeType error will be returned. 305 Thus, for example, a compare request of type "name" and assertion 306 value "Johann", against an entry containing the following attributes: 308 objectClass: top 309 objectClass: person 310 givenName;lang-de-DE: Johann 311 CN: Johann Sibelius 312 SN: Sibelius 314 would cause the server to return compareTrue. 316 However, if the client issued a compare request of type "name;lang-de" 317 and assertion value "Johann" against the above entry, the request 318 would fail with the noSuchAttributeType error. 320 If the server does not support storing attributes with language tag 321 options in the DIT, then any comparison which includes a language tag 322 option will always fail to locate an attribute, and 323 noSuchAttributeType will be returned. 325 2.5. Add Operation 327 Clients can provide language options in AttributeDescription in 328 attributes of a new entry to be created. 330 A client can provide multiple attributes with the same attribute type 331 and value, so long as each attribute has a different set of language 332 tag options. 334 For example, the following is a valid request: 336 dn: CN=John Smith,DC=example,DC=com 337 objectClass: residentialPerson 338 CN: John Smith 339 CN;lang-en: John Smith 340 SN: Smith 341 SN;lang-en: Smith 342 streetAddress: 1 University Street 343 streetAddress;lang-en-US: 1 University Street 344 streetAddress;lang-fr: 1 rue Universite 345 houseIdentifier;lang-fr: 9e etage 347 If a server does not support storing language tag options with 348 attribute values in the DIT, then it MUST treat an 349 AttributeDescription with a language tag option as an unrecognized 350 attribute. If the server forbids the addition of unrecognized 351 attributes then it MUST fail the add request with an appropriate 352 result code. 354 2.6. Modify Operation 356 A client can provide language tag options in an AttributeDescription 357 as part of a modification element in the modify operation. 359 Attribute types and language tag options MUST match exactly against 360 values stored in the directory. For example, if the modification is a 361 "delete", then if the stored values to be deleted have language tag 362 options, then those language tag options MUST be provided in the 363 modify operation, and if the stored values to be deleted do not have 364 any language tag option, then no language tag option is to be 365 provided. 367 If the server does not support storing language tag options with 368 attribute values in the DIT, then it MUST treat an 369 AttributeDescription with a language tag option as an unrecognized 370 attribute, and MUST fail the request with an appropriate result code. 372 3. Use of Language Ranges in LDAP 373 Since the publication of RFC 2596, it has become apparent that there 374 is a need to provide a mechanism for a client to request attributes 375 based upon set of language tag options whose tags all begin with the 376 same sequence of language sub-tags. 378 AttributeDescriptions containing language range options are intended 379 to be used in attribute value assertions, search attribute lists, and 380 other places where the client desires to provide an attribute 381 description matching of a range of language tags associated with 382 attributes. 384 A language range option conforms to the following ABNF [RFC2234]: 386 language-range-option = "lang-" [ Language-Tag "-" ] 388 where the Language-Tag production is as defined in BCP 47 [RFC3066]. 389 This production and those it imports from [RFC2234] are provided in 390 Section 2.1 for convenience. 392 A language range option matches a language tag option if the language 393 range option less the trailing "-" matches exactly the language tag or 394 if the language range option (including the trailing "-") matches a 395 prefix of the language tag option. Note that the language range 396 option "lang-" matches all language tag options. 398 Examples of valid AttributeDescription containing language range 399 options: 401 givenName;lang-en- 402 CN;lang- 403 SN;lang-de-;lang-gem- 404 O;lang-x-;x-foobar 406 A language range option is not a tagging option. Attributes cannot be 407 stored with language range options. Any attempt to add or update an 408 attribute description with a language range option SHALL be treated as 409 an undefined attribute type and result in an error. 411 A language range option has no effect on the transfer encoding nor on 412 the syntax of the attribute values. 414 Servers SHOULD support assertion of language ranges for any attribute 415 type which they allow to be stored with language tags. 417 3.1. Search Filter 419 If a language range option is present in an AttributeDescription in an 420 assertion, then for each entry within scope, the values of each 421 attribute whose AttributeDescription consists of the same attribute 422 type or its subtypes and contains a language tag option matching the 423 language range option are to be returned. 425 Thus, for example, a filter of an equality match of type 426 "name;lang-en-" and assertion value "Billy Ray", against the following 427 directory entry: 429 dn: SN=Ray,DC=example,DC=com 430 objectClass: person DOES NOT MATCH (wrong type) 431 objectClass: extensibleObject DOES NOT MATCH (wrong type) 432 name;lang-en-US: Billy Ray MATCHES 433 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 434 CN;lang-en-US: Billy Ray MATCHES 435 CN;lang-en-US;x-foobar: Billy Ray MATCHES 436 CN;lang-en;x-foobar: Billy Ray MATCHES 437 CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) 438 name: Billy Ray DOES NOT MATCH (no lang-) 439 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 440 SN: Ray DOES NOT MATCH (no lang-, 441 wrong value) 443 Note that "CN" and "SN" are subtypes of "name". 445 If the server does not support storing attributes with language tag 446 options in the DIT, then any assertion which includes a language range 447 option will not match as it is an unrecognized attribute type. No 448 error would be returned because of this; a presence filter would 449 evaluate to FALSE and all other assertions to Undefined. 451 3.2. Requested Attributes in Search 453 Clients can provide language range options in each 454 AttributeDescription in the requested attribute list in a search 455 request. 457 If a language range option is provided in an attribute description, 458 then only attributes in a directory entry whose attribute descriptions 459 have the same attribute type or its subtype and a language tag option 460 matching the provided language range option are to be returned. Thus 461 if a client requests just the attribute "name;lang-en-", the server 462 would return "name;lang-en-US" and "CN;lang-en;lang-ja" but not "SN" 463 nor "name;lang-fr". 465 Clients can provide in the attribute list multiple 466 AttributeDescriptions which have the same base attribute type but 467 different options. For example a client could provide both 468 "name;lang-en-" and "name;lang-fr-", and this would permit an 469 attribute whose type was name or subtype of name and with a language 470 tag option matching either language range option to be returned. 472 If a server does not support storing attributes with language tag 473 options in the DIT, then any attribute descriptions in the list which 474 include language range options are to be ignored, just as if they were 475 unknown attribute types. 477 3.3. Compare 479 Language range options can be present in an AttributeDescription used 480 in a compare request AttributeValueAssertion. This is to be treated 481 by servers the same as the use of language range options in a search 482 filter with an equality match, as described in Section 3.1. If there 483 is no attribute in the entry with the same subtype and a matching 484 language tag option, the noSuchAttributeType error will be returned. 486 Thus, for example, a compare request of type "name;lang-" and 487 assertion value "Johann", against the entry with the following 488 attributes: 490 objectClass: top 491 objectClass: person 492 givenName;lang-de-DE: Johann 493 CN: Johann Sibelius 494 SN: Sibelius 496 will cause the server to return compareTrue. (Note that the language 497 range option "lang-" matches any language tag option.) 499 However, if the client issued a compare request of type "name;lang-de" 500 and assertion value "Sibelius" against the above entry, the request 501 would fail with the noSuchAttributeType error. 503 If the server does not support storing attributes with language tag 504 options in the DIT, then any comparison which includes a language 505 range option will always fail to locate an attribute, and 506 noSuchAttributeType will be returned. 508 4. Discovering Language Option Support 510 A server SHOULD indicate that it supports storing attributes with 511 language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4 512 as a value of the root DSE. 514 A server SHOULD indicate that it supports language range matching of 515 attributes with language tag options stored in the DIT by publishing 516 1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures" [RFC3674] 517 attribute in the root DSE. 519 A server MAY restrict use of language tag options to a subset of the 520 attribute types it recognizes. This document does not define a 521 mechanism for determining which subset of attribute types can be used 522 with language tag options. 524 5. Interoperability with Non-supporting Implementations 526 Implementators of this specifcation should take care that their use of 527 language tag options does not impede proper function of 528 implementations which do not support language tags. 530 Per RFC 2251, "an AttributeDescription with one or more options is 531 treated as a subtype of the attribute type without any options." A 532 non-supporting server will treat an AttributeDescription with any 533 language tag options as an unrecognized attribute type. A 534 non-supporting client will either do the same, or will treat the 535 AttributeDescription as it would any other unknown subtype. 536 Typically, non-supporting clients simply ignore unrecognized subtypes 537 (and unrecognized attribute types) of attributes they request. 539 To ensure proper function of non-supporting clients, supporting 540 clients SHOULD ensure that entries they populate with tagged values 541 are also populated with non-tagged values. 543 Additionally, supporting clients SHOULD be prepared to handle entries 544 which are not populated with tagged values. 546 6. Security Considerations 548 Language tags and range options are used solely to indicate the native 549 language of values and in querying the directory for values which 550 fulfill the user's language needed. These options are not known to 551 raise specific security considerations. However, the reader should 552 consider general directory security issues detailed in the LDAP 553 technical specification [RFC3377]. 555 7. IANA Considerations 557 Registration of these protocol mechanisms [RFC3383] is requested. 559 Subject: Request for LDAP Protocol Mechanism Registration 560 Object Identifier: 1.3.6.1.4.1.4203.1.5.4 561 Description: Language Tag Options 562 Object Identifier: 1.3.6.1.4.1.4203.1.5.5 563 Description: Language Range Options 564 Person & email address to contact for further information: 565 Kurt Zeilenga 566 Usage: Feature 567 Specification: RFC XXXX 568 Author/Change Controller: IESG 569 Comments: none 571 These OIDs were assigned [ASSIGN] by OpenLDAP Foundation, under its 572 IANA-assigned private enterprise allocation [PRIVATE], for use in this 573 specification. 575 8. Acknowledgments 577 This document is a revision of RFC 2596 by Mark Wahl and Tim Howes. 578 RFC 2596 was a product of the IETF ASID and LDAPEXT working groups. 579 This document also borrows from a number of IETF documents including 580 BCP 47 by H. Alvestrand. 582 9. Editor's Address 584 Kurt D. Zeilenga 585 OpenLDAP Foundation 587 Email: Kurt@OpenLDAP.org 589 10. Normative References 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14 (also RFC 2119), March 1997. 594 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 595 Specifications: ABNF", RFC 2234, November 1997. 597 [RFC2251] Wahl, M., T. Howes and S. Kille, "Lightweight Directory 598 Access Protocol (v3)", RFC 2251, December 1997. 600 [RFC3066] Alvestrand, H., "Tags for the Identification of 601 Languages", BCP 47 (also RFC 3066), January 2001. 603 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 604 Protocol (v3): Technical Specification", RFC 3377, 605 September 2002. 607 [Features] Zeilenga, K., "Feature Discovery in LDAP", RFC 3674, 608 December 2003. 610 [ASCII] Coded Character Set--7-bit American Standard Code for 611 Information Interchange, ANSI X3.4-1986. 613 11. Informative References 615 [X.501] International Telecommunication Union - 616 Telecommunication Standardization Sector, "The Directory 617 -- Models," X.501(1997). 619 [RFC3383] Zeilenga, K., "IANA Considerations for LDAP", BCP 64 620 (also RFC 3383), September 2002. 622 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 623 http://www.openldap.org/foundation/oid-delegate.txt. 625 [PRIVATE] IANA, "Private Enterprise Numbers", 626 http://www.iana.org/assignments/enterprise-numbers. 628 Appendix A. Differences from RFC 2596 630 This document adds support for language ranges, provides a mechanism 631 that a client can use to discover whether a server supports language 632 tags and ranges, and clarifies how attributes with multiple language 633 tags are to be treated. This document is a significant rewrite of RFC 634 2596. 636 Appendix B. Differences from X.500(1997) 638 X.500(1997) [X.501] defines a different mechanism, contexts, as the 639 means of representing language tags (codes). This section summarizes 640 the major differences in approach. 642 a) An X.500 operation which has specified a language code on a value 643 matches a value in the directory without a language code. 644 b) LDAP references BCP 47 [RFC3066], which allows for IANA 645 registration of new tags as well as unregistered tags. 646 c) LDAP supports language ranges (new in this revision). 647 d) LDAP does not allow language tags (and ranges) in distinguished 648 names. 650 e) X.500 describes subschema administration procedures to allow 651 language codes to be associated with particular attributes types. 653 Intellectual Property Rights 655 The IETF takes no position regarding the validity or scope of any 656 intellectual property or other rights that might be claimed to pertain 657 to the implementation or use of the technology described in this 658 document or the extent to which any license under such rights might or 659 might not be available; neither does it represent that it has made any 660 effort to identify any such rights. Information on the IETF's 661 procedures with respect to rights in standards-track and 662 standards-related documentation can be found in BCP-11. Copies of 663 claims of rights made available for publication and any assurances of 664 licenses to be made available, or the result of an attempt made to 665 obtain a general license or permission for the use of such proprietary 666 rights by implementors or users of this specification can be obtained 667 from the IETF Secretariat. 669 The IETF invites any interested party to bring to its attention any 670 copyrights, patents or patent applications, or other proprietary 671 rights which may cover technology that may be required to practice 672 this standard. Please address the information to the IETF Executive 673 Director. 675 Full Copyright 677 Copyright (C) The Internet Society (2004). All Rights Reserved. 679 This document and translations of it may be copied and furnished to 680 others, and derivative works that comment on or otherwise explain it 681 or assist in its implementation may be prepared, copied, published and 682 distributed, in whole or in part, without restriction of any kind, 683 provided that the above copyright notice and this paragraph are 684 included on all such copies and derivative works. However, this 685 document itself may not be modified in any way, such as by removing 686 the copyright notice or references to the Internet Society or other 687 Internet organizations, except as needed for the purpose of 688 developing Internet standards in which case the procedures for 689 copyrights defined in the Internet Standards process must be followed, 690 or as required to translate it into languages other than English.