]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3866.txt
Fix prev commit
[openldap] / 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