git.sur5r.net Git - openldap/blob - doc/rfc/rfc3866.txt

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