1 2 3 4 5 6 7 Network Working Group K. Zeilenga, Ed. 8 Request for Comments: 3866 OpenLDAP Foundation 9 Obsoletes: 2596 July 2004 10 Category: Standards Track 11 12 13 Language Tags and Ranges in the 14 Lightweight Directory Access Protocol (LDAP) 15 16 Status of this Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24 Copyright Notice 25 26 Copyright (C) The Internet Society (2004). 27 28 Abstract 29 30 It is often desirable to be able to indicate the natural language 31 associated with values held in a directory and to be able to query 32 the directory for values which fulfill the user's language needs. 33 This document details the use of Language Tags and Ranges in the 34 Lightweight Directory Access Protocol (LDAP). 35 36 1. Background and Intended Use 37 38 The Lightweight Directory Access Protocol (LDAP) [RFC3377] provides a 39 means for clients to interrogate and modify information stored in a 40 distributed directory system. The information in the directory is 41 maintained as attributes of entries. Most of these attributes have 42 syntaxes which are human-readable strings, and it is desirable to be 43 able to indicate the natural language associated with attribute 44 values. 45 46 This document describes how language tags and ranges [RFC3066] are 47 carried in LDAP and are to be interpreted by LDAP implementations. 48 All LDAP implementations MUST be prepared to accept language tags and 49 ranges. 50 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in BCP 14 [RFC2119]. 54 55 56 57 58 Zeilenga Standards Track [Page 1] 59 61 RFC 3866 Language Tags and Ranges in LDAP July 2004 62 63 64 This document replaces RFC 2596. Appendix A summaries changes made 65 since RFC 2596. 66 67 Appendix B discusses differences from X.500(1997) "contexts" 68 mechanism. 69 70 Appendix A and B are provided for informational purposes only. 71 72 The remainder of this section provides a summary of Language Tags, 73 Language Ranges, and Attribute Descriptions. 74 75 1.1. Language Tags 76 77 Section 2 of BCP 47 [RFC3066] describes the language tag format which 78 is used in LDAP. Briefly, it is a string of [ASCII] letters and 79 hyphens. Examples include "fr", "en-US" and "ja-JP". Language tags 80 are case insensitive. That is, the language tag "en-us" is the same 81 as "EN-US". 82 83 Section 2 of this document details use of language tags in LDAP. 84 85 1.2. Language Ranges 86 87 Section 2.5 of BCP 47 [RFC3066] describes the language ranges. 88 Language ranges are used to specify sets of language tags. 89 90 A language range matches a language tag if it is exactly equal to the 91 tag, or if it is exactly equal to a prefix of the tag such that the 92 first character following the prefix is "-". That is, the language 93 range "de" matches the language tags "de" and "de-CH" but not "den". 94 The special language range "*" matches all language tags. 95 96 Due to attribute description option naming restrictions in LDAP, this 97 document defines a different language range syntax. However, the 98 semantics of language ranges in LDAP are consistent with BCP 47. 99 100 Section 3 of this document details use of language ranges in LDAP. 101 102 1.3. Attribute Descriptions 103 104 This section provides an overview of attribute descriptions in LDAP. 105 LDAP attributes and attribute descriptions are defined in [RFC2251]. 106 107 An attribute consists of a type, a set of zero or more associated 108 tagging options, and a set of one or more values. The type and the 109 options are combined into the AttributeDescription. 110 111 112 113 114 115 Zeilenga Standards Track [Page 2] 116 118 RFC 3866 Language Tags and Ranges in LDAP July 2004 119 120 121 AttributeDescriptions can also contain options which are not part of 122 the attribute, but indicate some other function (such as range 123 assertion or transfer encoding). 124 125 An AttributeDescription with one or more tagging options is a direct 126 subtype of each AttributeDescription of the same type with all but 127 one of the tagging options. If the AttributeDescription's type is a 128 direct subtype of some other type, then the AttributeDescription is 129 also a direct subtype of the AttributeDescription which consists of 130 the supertype and all of the tagging options. That is, 131 "CN;x-bar;x-foo" is a direct subtype of "CN;x-bar", "CN;x-foo", and 132 "name;x-bar;x-foo". Note that "CN" is a subtype of "name". 133 134 2. Use of Language Tags in LDAP 135 136 This section describes how LDAP implementations MUST interpret 137 language tags in performing operations. 138 139 Servers which support storing attributes with language tag options in 140 the Directory Information Tree (DIT) SHOULD allow any attribute type 141 it recognizes that has the Directory String, IA5 String, or other 142 textual string syntaxes to have language tag options associated with 143 it. Servers MAY allow language options to be associated with other 144 attributes types. 145 146 Clients SHOULD NOT assume servers are capable of storing attributes 147 with language tags in the directory. 148 149 Implementations MUST NOT otherwise interpret the structure of the tag 150 when comparing two tags, and MUST treat them simply as strings of 151 characters. Implementations MUST allow any arbitrary string which 152 conforms to the syntax defined in BCP 47 [RFC3066] to be used as a 153 language tag. 154 155 2.1. Language Tag Options 156 157 A language tag option associates a natural language with values of an 158 attribute. An attribute description may contain multiple language 159 tag options. An entry may contain multiple attributes with same 160 attribute type but different combinations of language tag (and other) 161 options. 162 163 A language tag option conforms to the following ABNF [RFC2234]: 164 165 language-tag-option = "lang-" Language-Tag 166 167 168 169 170 171 172 Zeilenga Standards Track [Page 3] 173 175 RFC 3866 Language Tags and Ranges in LDAP July 2004 176 177 178 where the Language-Tag production is as defined in BCP 47 [RFC3066]. 179 This production and those it imports from [RFC2234] are provided here 180 for convenience: 181 182 Language-Tag = Primary-subtag *( "-" Subtag ) 183 184 Primary-subtag = 1*8ALPHA 185 186 Subtag = 1*8(ALPHA / DIGIT) 187 188 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 189 190 DIGIT = %x30-39 ; 0-9 191 192 A language tag option is a tagging option. A language tag option has 193 no effect on the syntax of the attribute's values nor their transfer 194 encoding. 195 196 Examples of valid AttributeDescription: 197 198 givenName;lang-en-US 199 CN;lang-ja 200 SN;lang-de;lang-gem-PFL 201 O;lang-i-klingon;x-foobar 202 description;x-foobar 203 CN 204 205 Notes: The last two have no language tag options. The x-foobar 206 option is fictious and used for example purposes. 207 208 2.2. Search Filter 209 210 If language tag options are present in an AttributeDescription in an 211 assertion, then for each entry within scope, the values of each 212 attribute whose AttributeDescription consists of the same attribute 213 type or its subtypes and contains each of the presented (and possibly 214 other) options is to be matched. 215 216 Thus, for example, a filter of an equality match of type 217 "name;lang-en-US" and assertion value "Billy Ray", against the 218 following directory entry: 219 220 dn: SN=Ray,DC=example,DC=com 221 objectClass: person DOES NOT MATCH (wrong type) 222 objectClass: extensibleObject DOES NOT MATCH (wrong type) 223 name;lang-en-US: Billy Ray MATCHES 224 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 225 CN;lang-en-US: Billy Ray MATCHES 226 227 228 229 Zeilenga Standards Track [Page 4] 230 232 RFC 3866 Language Tags and Ranges in LDAP July 2004 233 234 235 CN;lang-en-US;x-foobar: Billy Ray MATCHES 236 CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-) 237 CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) 238 name: Billy Ray DOES NOT MATCH (no lang-) 239 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 240 SN: Ray DOES NOT MATCH (no lang-, 241 wrong value) 242 243 Note that "CN" and "SN" are subtypes of "name". 244 245 It is noted that providing a language tag option in a search filter 246 AttributeDescription will filter out desirable values where the tag 247 does not match exactly. For example, the filter (name;lang-en=Billy 248 Ray) does NOT match the attribute "name;lang-en-US: Billy Ray". 249 250 If the server does not support storing attributes with language tag 251 options in the DIT, then any assertion which includes a language tag 252 option will not match as such it is an unrecognized attribute type. 253 No error would be returned because of this; a presence assertion 254 would evaluate to FALSE and all other assertions to Undefined. 255 256 If no options are specified in the assertion, then only the base 257 attribute type and the assertion value need match the value in the 258 directory. 259 260 Thus, for example, a filter of an equality match of type "name" and 261 assertion value "Billy Ray", against the following directory entry: 262 263 dn: SN=Ray,DC=example,DC=com 264 objectClass: person DOES NOT MATCH (wrong type) 265 objectClass: extensibleObject DOES NOT MATCH (wrong type) 266 name;lang-en-US: Billy Ray MATCHES 267 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 268 CN;lang-en-US;x-foobar: Billy Ray MATCHES 269 CN;lang-en;x-foobar: Billy Ray MATCHES 270 CN;x-foobar: Billy Ray MATCHES 271 name: Billy Ray MATCHES 272 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 273 SN: Ray DOES NOT MATCH (wrong value) 274 275 2.3. Requested Attributes in Search 276 277 Clients can provide language tag options in each AttributeDescription 278 in the requested attribute list in a search request. 279 280 If language tag options are provided in an attribute description, 281 then only attributes in a directory entry whose attribute 282 descriptions have the same attribute type or its subtype and contains 283 284 285 286 Zeilenga Standards Track [Page 5] 287 289 RFC 3866 Language Tags and Ranges in LDAP July 2004 290 291 292 each of the presented (and possibly other) language tag options are 293 to be returned. Thus if a client requests just the attribute 294 "name;lang-en", the server would return "name;lang-en" and 295 "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr". 296 297 Clients can provide in the attribute list multiple 298 AttributeDescriptions which have the same base attribute type but 299 different options. For example, a client could provide both 300 "name;lang-en" and "name;lang-fr", and this would permit an attribute 301 with either language tag option to be returned. Note there would be 302 no need to provide both "name" and "name;lang-en" since all subtypes 303 of name would match "name". 304 305 If a server does not support storing attributes with language tag 306 options in the DIT, then any attribute descriptions in the list which 307 include language tag options are to be ignored, just as if they were 308 unknown attribute types. 309 310 If a request is made specifying all attributes or an attribute is 311 requested without providing a language tag option, then all attribute 312 values regardless of their language tag option are returned. 313 314 For example, if the client requests a "description" attribute, and a 315 matching entry contains the following attributes: 316 317 objectClass: top 318 objectClass: organization 319 O: Software GmbH 320 description: software products 321 description;lang-en: software products 322 description;lang-de: Softwareprodukte 323 324 The server would return: 325 326 description: software products 327 description;lang-en: software products 328 description;lang-de: Softwareprodukte 329 330 2.4. Compare 331 332 Language tag options can be present in an AttributeDescription used 333 in a compare request AttributeValueAssertion. This is to be treated 334 by servers the same as the use of language tag options in a search 335 filter with an equality match, as described in Section 2.2. If there 336 is no attribute in the entry with the same attribute type or its 337 subtype and contains each of the presented (or possibly other) 338 language tag options, the noSuchAttributeType error will be returned. 339 340 341 342 343 Zeilenga Standards Track [Page 6] 344 346 RFC 3866 Language Tags and Ranges in LDAP July 2004 347 348 349 Thus, for example, a compare request of type "name" and assertion 350 value "Johann", against an entry containing the following attributes: 351 352 objectClass: top 353 objectClass: person 354 givenName;lang-de-DE: Johann 355 CN: Johann Sibelius 356 SN: Sibelius 357 358 would cause the server to return compareTrue. 359 360 However, if the client issued a compare request of type 361 "name;lang-de" and assertion value "Johann" against the above entry, 362 the request would fail with the noSuchAttributeType error. 363 364 If the server does not support storing attributes with language tag 365 options in the DIT, then any comparison which includes a language tag 366 option will always fail to locate an attribute, and 367 noSuchAttributeType will be returned. 368 369 2.5. Add Operation 370 371 Clients can provide language options in AttributeDescription in 372 attributes of a new entry to be created. 373 374 A client can provide multiple attributes with the same attribute type 375 and value, so long as each attribute has a different set of language 376 tag options. 377 378 For example, the following is a valid request: 379 380 dn: CN=John Smith,DC=example,DC=com 381 objectClass: residentialPerson 382 CN: John Smith 383 CN;lang-en: John Smith 384 SN: Smith 385 SN;lang-en: Smith 386 streetAddress: 1 University Street 387 streetAddress;lang-en-US: 1 University Street 388 streetAddress;lang-fr: 1 rue Universite 389 houseIdentifier;lang-fr: 9e etage 390 391 If a server does not support storing language tag options with 392 attribute values in the DIT, then it MUST treat an 393 AttributeDescription with a language tag option as an unrecognized 394 attribute. If the server forbids the addition of unrecognized 395 attributes then it MUST fail the add request with an appropriate 396 result code. 397 398 399 400 Zeilenga Standards Track [Page 7] 401 403 RFC 3866 Language Tags and Ranges in LDAP July 2004 404 405 406 2.6. Modify Operation 407 408 A client can provide language tag options in an AttributeDescription 409 as part of a modification element in the modify operation. 410 411 Attribute types and language tag options MUST match exactly against 412 values stored in the directory. For example, if the modification is 413 a "delete", then if the stored values to be deleted have language tag 414 options, then those language tag options MUST be provided in the 415 modify operation, and if the stored values to be deleted do not have 416 any language tag option, then no language tag option is to be 417 provided. 418 419 If the server does not support storing language tag options with 420 attribute values in the DIT, then it MUST treat an 421 AttributeDescription with a language tag option as an unrecognized 422 attribute, and MUST fail the request with an appropriate result code. 423 424 3. Use of Language Ranges in LDAP 425 426 Since the publication of RFC 2596, it has become apparent that there 427 is a need to provide a mechanism for a client to request attributes 428 based upon set of language tag options whose tags all begin with the 429 same sequence of language sub-tags. 430 431 AttributeDescriptions containing language range options are intended 432 to be used in attribute value assertions, search attribute lists, and 433 other places where the client desires to provide an attribute 434 description matching of a range of language tags associated with 435 attributes. 436 437 A language range option conforms to the following ABNF [RFC2234]: 438 439 language-range-option = "lang-" [ Language-Tag "-" ] 440 441 where the Language-Tag production is as defined in BCP 47 [RFC3066]. 442 This production and those it imports from [RFC2234] are provided in 443 Section 2.1 for convenience. 444 445 A language range option matches a language tag option if the language 446 range option less the trailing "-" matches exactly the language tag 447 or if the language range option (including the trailing "-") matches 448 a prefix of the language tag option. Note that the language range 449 option "lang-" matches all language tag options. 450 451 452 453 454 455 456 457 Zeilenga Standards Track [Page 8] 458 460 RFC 3866 Language Tags and Ranges in LDAP July 2004 461 462 463 Examples of valid AttributeDescription containing language range 464 options: 465 466 givenName;lang-en- 467 CN;lang- 468 SN;lang-de-;lang-gem- 469 O;lang-x-;x-foobar 470 471 A language range option is not a tagging option. Attributes cannot 472 be stored with language range options. Any attempt to add or update 473 an attribute description with a language range option SHALL be 474 treated as an undefined attribute type and result in an error. 475 476 A language range option has no effect on the transfer encoding nor on 477 the syntax of the attribute values. 478 479 Servers SHOULD support assertion of language ranges for any attribute 480 type which they allow to be stored with language tags. 481 482 3.1. Search Filter 483 484 If a language range option is present in an AttributeDescription in 485 an assertion, then for each entry within scope, the values of each 486 attribute whose AttributeDescription consists of the same attribute 487 type or its subtypes and contains a language tag option matching the 488 language range option are to be returned. 489 490 Thus, for example, a filter of an equality match of type 491 "name;lang-en-" and assertion value "Billy Ray", against the 492 following directory entry: 493 494 dn: SN=Ray,DC=example,DC=com 495 objectClass: person DOES NOT MATCH (wrong type) 496 objectClass: extensibleObject DOES NOT MATCH (wrong type) 497 name;lang-en-US: Billy Ray MATCHES 498 name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value) 499 CN;lang-en-US: Billy Ray MATCHES 500 CN;lang-en-US;x-foobar: Billy Ray MATCHES 501 CN;lang-en;x-foobar: Billy Ray MATCHES 502 CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-) 503 name: Billy Ray DOES NOT MATCH (no lang-) 504 SN;lang-en-GB;lang-en-US: Billy Ray MATCHES 505 SN: Ray DOES NOT MATCH (no lang-, 506 wrong value) 507 508 Note that "CN" and "SN" are subtypes of "name". 509 510 511 512 513 514 Zeilenga Standards Track [Page 9] 515 517 RFC 3866 Language Tags and Ranges in LDAP July 2004 518 519 520 If the server does not support storing attributes with language tag 521 options in the DIT, then any assertion which includes a language 522 range option will not match as it is an unrecognized attribute type. 523 No error would be returned because of this; a presence filter would 524 evaluate to FALSE and all other assertions to Undefined. 525 526 3.2. Requested Attributes in Search 527 528 Clients can provide language range options in each 529 AttributeDescription in the requested attribute list in a search 530 request. 531 532 If a language range option is provided in an attribute description, 533 then only attributes in a directory entry whose attribute 534 descriptions have the same attribute type or its subtype and a 535 language tag option matching the provided language range option are 536 to be returned. Thus if a client requests just the attribute 537 "name;lang-en-", the server would return "name;lang-en-US" and 538 "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr". 539 540 Clients can provide in the attribute list multiple 541 AttributeDescriptions which have the same base attribute type but 542 different options. For example a client could provide both 543 "name;lang-en-" and "name;lang-fr-", and this would permit an 544 attribute whose type was name or subtype of name and with a language 545 tag option matching either language range option to be returned. 546 547 If a server does not support storing attributes with language tag 548 options in the DIT, then any attribute descriptions in the list which 549 include language range options are to be ignored, just as if they 550 were unknown attribute types. 551 552 3.3. Compare 553 554 Language range options can be present in an AttributeDescription used 555 in a compare request AttributeValueAssertion. This is to be treated 556 by servers the same as the use of language range options in a search 557 filter with an equality match, as described in Section 3.1. If there 558 is no attribute in the entry with the same subtype and a matching 559 language tag option, the noSuchAttributeType error will be returned. 560 561 Thus, for example, a compare request of type "name;lang-" and 562 assertion value "Johann", against the entry with the following 563 attributes: 564 565 566 567 568 569 570 571 Zeilenga Standards Track [Page 10] 572 574 RFC 3866 Language Tags and Ranges in LDAP July 2004 575 576 577 objectClass: top 578 objectClass: person 579 givenName;lang-de-DE: Johann 580 CN: Johann Sibelius 581 SN: Sibelius 582 583 will cause the server to return compareTrue. (Note that the language 584 range option "lang-" matches any language tag option.) 585 586 However, if the client issued a compare request of type 587 "name;lang-de" and assertion value "Sibelius" against the above 588 entry, the request would fail with the noSuchAttributeType error. 589 590 If the server does not support storing attributes with language tag 591 options in the DIT, then any comparison which includes a language 592 range option will always fail to locate an attribute, and 593 noSuchAttributeType will be returned. 594 595 4. Discovering Language Option Support 596 597 A server SHOULD indicate that it supports storing attributes with 598 language tag options in the DIT by publishing 1.3.6.1.4.1.4203.1.5.4 599 as a value of the root DSE. 600 601 A server SHOULD indicate that it supports language range matching of 602 attributes with language tag options stored in the DIT by publishing 603 1.3.6.1.4.1.4203.1.5.5 as a value of the "supportedFeatures" 604 [RFC3674] attribute in the root DSE. 605 606 A server MAY restrict use of language tag options to a subset of the 607 attribute types it recognizes. This document does not define a 608 mechanism for determining which subset of attribute types can be used 609 with language tag options. 610 611 5. Interoperability with Non-supporting Implementations 612 613 Implementators of this specification should take care that their use 614 of language tag options does not impede proper function of 615 implementations which do not support language tags. 616 617 Per RFC 2251, "an AttributeDescription with one or more options is 618 treated as a subtype of the attribute type without any options." A 619 non-supporting server will treat an AttributeDescription with any 620 language tag options as an unrecognized attribute type. A non- 621 supporting client will either do the same, or will treat the 622 AttributeDescription as it would any other unknown subtype. 623 Typically, non-supporting clients simply ignore unrecognized subtypes 624 (and unrecognized attribute types) of attributes they request. 625 626 627 628 Zeilenga Standards Track [Page 11] 629 631 RFC 3866 Language Tags and Ranges in LDAP July 2004 632 633 634 To ensure proper function of non-supporting clients, supporting 635 clients SHOULD ensure that entries they populate with tagged values 636 are also populated with non-tagged values. 637 638 Additionally, supporting clients SHOULD be prepared to handle entries 639 which are not populated with tagged values. 640 641 6. Security Considerations 642 643 Language tags and range options are used solely to indicate the 644 native language of values and in querying the directory for values 645 which fulfill the user's language needed. These options are not 646 known to raise specific security considerations. However, the reader 647 should consider general directory security issues detailed in the 648 LDAP technical specification [RFC3377]. 649 650 7. IANA Considerations 651 652 Registration of these protocol mechanisms [RFC3383] has been 653 completed by the IANA. 654 655 Subject: Request for LDAP Protocol Mechanism Registration 656 Object Identifier: 1.3.6.1.4.1.4203.1.5.4 657 Description: Language Tag Options 658 Object Identifier: 1.3.6.1.4.1.4203.1.5.5 659 Description: Language Range Options 660 Person & email address to contact for further information: 661 Kurt Zeilenga <kurt (a] openldap.org> 662 Usage: Feature 663 Specification: RFC 3866 664 Author/Change Controller: IESG 665 Comments: none 666 667 These OIDs were assigned [ASSIGN] by OpenLDAP Foundation, under its 668 IANA-assigned private enterprise allocation [PRIVATE], for use in 669 this specification. 670 671 8. Acknowledgments 672 673 This document is a revision of RFC 2596 by Mark Wahl and Tim Howes. 674 RFC 2596 was a product of the IETF ASID and LDAPEXT working groups. 675 This document also borrows from a number of IETF documents including 676 BCP 47 by H. Alvestrand. 677 678 679 680 681 682 683 684 685 Zeilenga Standards Track [Page 12] 686 688 RFC 3866 Language Tags and Ranges in LDAP July 2004 689 690 691 9. References 692 693 9.1. Normative References 694 695 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 696 Requirement Levels", BCP 14, RFC 2119, March 1997. 697 698 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for 699 Syntax Specifications: ABNF", RFC 2234, November 1997. 700 701 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight 702 Directory Access Protocol (v3)", RFC 2251, December 703 1997. 704 705 [RFC3066] Alvestrand, H., "Tags for the Identification of 706 Languages", BCP 47, RFC 3066, January 2001. 707 708 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 709 Protocol (v3): Technical Specification", RFC 3377, 710 September 2002. 711 712 [RFC3674] Zeilenga, K., "Feature Discovery in Lightweight 713 Directory Access Protocol (LDAP)", RFC 3674, December 714 2003. 715 716 [ASCII] Coded Character Set--7-bit American Standard Code for 717 Information Interchange, ANSI X3.4-1986. 718 719 9.2. Informative References 720 721 [X.501] International Telecommunication Union - 722 Telecommunication Standardization Sector, "The 723 Directory -- Models," X.501(1997). 724 725 [RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority 726 (IANA) Considerations for Lightweight Directory Access 727 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 728 729 [ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations", 730 http://www.openldap.org/foundation/oid-delegate.txt. 731 732 [PRIVATE] IANA, "Private Enterprise Numbers", 733 http://www.iana.org/assignments/enterprise-numbers. 734 735 736 737 738 739 740 741 742 Zeilenga Standards Track [Page 13] 743 745 RFC 3866 Language Tags and Ranges in LDAP July 2004 746 747 748 Appendix A. Differences from RFC 2596 749 750 This document adds support for language ranges, provides a mechanism 751 that a client can use to discover whether a server supports language 752 tags and ranges, and clarifies how attributes with multiple language 753 tags are to be treated. This document is a significant rewrite of 754 RFC 2596. 755 756 Appendix B. Differences from X.500(1997) 757 758 X.500(1997) [X.501] defines a different mechanism, contexts, as the 759 means of representing language tags (codes). This section summarizes 760 the major differences in approach. 761 762 a) An X.500 operation which has specified a language code on a value 763 matches a value in the directory without a language code. 764 765 b) LDAP references BCP 47 [RFC3066], which allows for IANA 766 registration of new tags as well as unregistered tags. 767 768 c) LDAP supports language ranges (new in this revision). 769 770 d) LDAP does not allow language tags (and ranges) in distinguished 771 names. 772 773 e) X.500 describes subschema administration procedures to allow 774 language codes to be associated with particular attributes types. 775 776 Editor's Address 777 778 Kurt D. Zeilenga 779 OpenLDAP Foundation 780 781 EMail: Kurt (a] OpenLDAP.org 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Zeilenga Standards Track [Page 14] 800 802 RFC 3866 Language Tags and Ranges in LDAP July 2004 803 804 805 Full Copyright Statement 806 807 Copyright (C) The Internet Society (2004). This document is subject 808 to the rights, licenses and restrictions contained in BCP 78, and 809 except as set forth therein, the authors retain all their rights. 810 811 This document and the information contained herein are provided on an 812 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 813 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 814 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 815 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 816 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 817 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 818 819 Intellectual Property 820 821 The IETF takes no position regarding the validity or scope of any 822 Intellectual Property Rights or other rights that might be claimed to 823 pertain to the implementation or use of the technology described in 824 this document or the extent to which any license under such rights 825 might or might not be available; nor does it represent that it has 826 made any independent effort to identify any such rights. Information 827 on the procedures with respect to rights in RFC documents can be 828 found in BCP 78 and BCP 79. 829 830 Copies of IPR disclosures made to the IETF Secretariat and any 831 assurances of licenses to be made available, or the result of an 832 attempt made to obtain a general license or permission for the use of 833 such proprietary rights by implementers or users of this 834 specification can be obtained from the IETF on-line IPR repository at 835 http://www.ietf.org/ipr. 836 837 The IETF invites any interested party to bring to its attention any 838 copyrights, patents or patent applications, or other proprietary 839 rights that may cover technology that may be required to implement 840 this standard. Please address the information to the IETF at ietf- 841 ipr (a] ietf.org. 842 843 Acknowledgement 844 845 Funding for the RFC Editor function is currently provided by the 846 Internet Society. 847 848 849 850 851 852 853 854 855 856 Zeilenga Standards Track [Page 15] 857 859
Indexes created Tue Sep 15 00:24:42 UTC 2026