1
2
3
4
5
6
7Network Working Group                                   K. Zeilenga, Ed.
8Request for Comments: 3866                           OpenLDAP Foundation
9Obsoletes: 2596                                                July 2004
10Category: Standards Track
11
12
13                    Language Tags and Ranges in the
14              Lightweight Directory Access Protocol (LDAP)
15
16Status 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
24Copyright Notice
25
26   Copyright (C) The Internet Society (2004).
27
28Abstract
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
361.  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
58Zeilenga                    Standards Track                     [Page 1]
59
60RFC 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
741.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
841.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
1011.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
114Zeilenga                    Standards Track                     [Page 2]
115
116RFC 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
1322.  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
1532.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
170Zeilenga                    Standards Track                     [Page 3]
171
172RFC 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
2052.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
226Zeilenga                    Standards Track                     [Page 4]
227
228RFC 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
2712.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
282Zeilenga                    Standards Track                     [Page 5]
283
284RFC 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
3252.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
338Zeilenga                    Standards Track                     [Page 6]
339
340RFC 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
3632.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
394Zeilenga                    Standards Track                     [Page 7]
395
396RFC 3866            Language Tags and Ranges in LDAP           July 2004
397
398
3992.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
4173.  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
450Zeilenga                    Standards Track                     [Page 8]
451
452RFC 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
4743.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
506Zeilenga                    Standards Track                     [Page 9]
507
508RFC 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
5173.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
5433.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
562Zeilenga                    Standards Track                    [Page 10]
563
564RFC 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
5854.  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
6015.  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
618Zeilenga                    Standards Track                    [Page 11]
619
620RFC 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
6306.  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
6397.  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
6608.  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
674Zeilenga                    Standards Track                    [Page 12]
675
676RFC 3866            Language Tags and Ranges in LDAP           July 2004
677
678
6799.  References
680
6819.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
7079.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
730Zeilenga                    Standards Track                    [Page 13]
731
732RFC 3866            Language Tags and Ranges in LDAP           July 2004
733
734
735Appendix 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
743Appendix 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
763Editor'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
786Zeilenga                    Standards Track                    [Page 14]
787
788RFC 3866            Language Tags and Ranges in LDAP           July 2004
789
790
791Full 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
805Intellectual 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
829Acknowledgement
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
842Zeilenga                    Standards Track                    [Page 15]
843
844