--- /dev/null
+
+
+
+
+
+
+INTERNET-DRAFT Editor: Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires: 13 May 2002 13 November 2001
+Obsoletes: RFC 2596
+
+
+ Language Tags and Ranges in LDAP
+ draft-zeilenga-ldap-rfc2596-00.txt
+
+
+Status of Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extensions Working Group
+ (LDAPext) mailing list <ietf-ldapext@netscape.com>. Please send
+ editorial comments directly to the document editor
+ <Kurt@OpenLDAP.org>.
+
+ Internet-Drafts are working documents of the Internet Engineering Task
+ Force (IETF), its areas, and its working groups. Note that other
+ groups may also distribute working documents as Internet-Drafts.
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as ``work in progress.''
+
+ The list of current Internet-Drafts can be accessed at
+ <http://www.ietf.org/ietf/1id-abstracts.txt>. The list of
+ Internet-Draft Shadow Directories can be accessed at
+ <http://www.ietf.org/shadow.html>.
+
+ Copyright 2001, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+Abstract
+
+ This document details the use of Language Tags and Ranges in LDAP.
+ This document replaces RFC 2596.
+
+
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in BCP 14 [RFC2119].
+
+
+1. Background and Intended Use
+
+ The Lightweight Directory Access Protocol (LDAP) [LDAPTS] provides a
+ means for clients to interrogate and modify information stored in a
+ distributed directory system. The information in the directory is
+ maintained as attributes of entries. Most of these attributes have
+ syntaxes which are human-readable strings, and it is desirable to be
+ able to indicate the natural language associated with attribute
+ values.
+
+ This document describes how language tags and ranges [RFC3066] are
+ carried in LDAP and are to be interpreted by LDAP implementations.
+ All implementations MUST be prepared to accept language tags and
+ ranges in the LDAP protocol.
+
+ This document replaces RFC 2596. Appendix A summaries changes made
+ since RFC 2596.
+
+ The remainder of this section provides a summary of Langauge Tags,
+ Language Ranges, and Attribute Descriptions.
+
+
+1.1. Language Tags
+
+ Section 2 of BCP 47 [RFC3066] describes the language tag format which
+ is used in LDAP. Briefly, it is a string of ASCII alphabetic
+ characters and hyphens. Examples include "fr", "en-US" and "ja-JP".
+ Language tags are case insensitive. For example, the language tag
+ "en-us" is the same as "EN-US".
+
+ Section 2 of this document details use of language tags in LDAP.
+
+
+1.2. Language Ranges
+
+ Section 2.5 of BCP 47 [RFC3066] describes the language ranges.
+ Language ranges are used to specify sets of language tags.
+
+ A language range matches a language tag if it exactly equals the tag,
+ or if it exactly equals a prefix of the tag such that the first
+ character following the prefix is "-". The special tag "*" matches
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ all tags.
+
+ Due to restrictions upon option naming in LDAP, this document uses a
+ different language range syntax. However, the semantics of language
+ ranges in LDAP is consistent with BCP 47.
+
+ Section 3 of this document details use of language ranges in LDAP.
+
+
+1.3. Attribute Descriptions
+
+ An attribute consists of a type, a list of "subtyping" (or "tag")
+ options for that type, and a set of one or more values. The type and
+ the options are combined into the AttributeDescription, defined in
+ section 4.1.5 of RFC 2251 [RFC2251]. AttributeDescription may also
+ contain options which are not part of the attribute, but indicate some
+ function such as the transfer encoding.
+
+ In summary, an attribute with "subtyping" (or "tag") options is
+ treated as a subtype of the attribute without the options. If a
+ server does not support any of the options, the attribute is treated
+ as an unrecognized attribute.
+
+ As language tags are intended to stored with the attribute, they are
+ to treated as "subtyping" (or "tag") options. Language range are used
+ only to match against language ranges and are not stored with the
+ attribute, they are not treated "subtyping" (or "tag") options but as
+ detailed in Section 3 of this document.
+
+
+2. Use of Language Tags in LDAP
+
+ This section describes how LDAP implementations MUST interpret
+ language tags in performing operations.
+
+ Servers which support storing attributes with language tag in the DIT
+ SHOULD allow any attribute type it recognizes that has the Directory
+ String syntax to have language tag options associated with it.
+ Servers MAY allow language options to be associated with other
+ attributes types.
+
+ Clients SHOULD NOT assume servers are capable of storing attributes
+ with language tags in the directory.
+
+ Implementations MUST NOT otherwise interpret the structure of the tag
+ when comparing two tag, and MUST treat them as simply strings of
+ characters. Implementations MUST allow any arbitrary string which
+ conforms to the syntax defined in BCP 47 to be used as a language tag.
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+2.1. Language Tag Options
+
+ A language tag option associates a natural language with values for
+ that attribute. An attribute description may contain multiple
+ language tag options. An entry may contain multiple attributes with
+ same attribute type but different language tag (and other) options.
+
+ A language tag option conforms to the following ABNF [RFC2234]:
+
+ language-tag-option = "lang-" Language-Tag
+
+ where the Language-Tag production is as defined in BCP 47 [RFC3066].
+
+ A language tag option is a "subtyping" (or "tag") option [RFC2251bis].
+ A language tag option has no effect on the tranfer encoding nor on the
+ syntax of the attribute values.
+
+ Examples of valid AttributeDescription:
+
+ givenName;lang-en-US
+ CN;lang-ja
+ SN;lang-de;lang-gem-PFL
+ O;lang-i-klingon;x-foobar
+ description;x-foobar
+ CN
+
+ Notes: The last two have no language tag options. The x-foobar option
+ is fictious and used for example purposes.
+
+
+2.2. Search Filter
+
+ If langugage tag options are present in an AttributeDescription in an
+ assertion, then for each entry within scope, the values of each
+ attribute whose AttributeDescription consists of the same attribute
+ type or its subtypes and contains each of the presented (and possibly
+ other) options is to be matched.
+
+ Thus for example a filter of an equality match of type
+ "name;lang-en-US" and assertion value "Billy Ray", against the
+ following directory entry
+
+ dn: SN=Ray,DC=example,DC=com
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US: Billy Ray MATCHES
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray DOES NOT MATCH (differing lang-)
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (wrong value)
+
+ (Note that "CN" and "SN" are subtypes of "name".)
+
+ Client implementors should however note that providing a language tag
+ option in a search filter AttributeDescription will often filter out
+ desirable values where the tag does not match exactly. For example,
+ the filter (name;lang-en=Billy Ray) does NOT match the attribute
+ "name;lang-en-US: Billy Ray".
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language tag
+ option will not match as it is an unrecognized attribute type. No
+ error would be returned because of this; a presence filter would
+ evaluate to FALSE and all other assertions to Undefined.
+
+ If no options are specified in the assertion, then only the base
+ attribute type and the assertion value need match the value in the
+ directory.
+
+ Thus for example a filter of an equality match of type "name" and
+ assertion value "Billy Ray", against the following directory entry
+
+ dn: SN=Ray,DC=example,DC=net
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray MATCHES
+ name: Billy Ray MATCHES
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (wrong value)
+
+
+2.3. Requested Attributes in Search
+
+ Clients can provide language tag options in AttributeDescription in
+ the requested attribute list in a search request.
+
+ If language tag options are provided in an attribute description, then
+ only attributes in a directory entry whose attribute descriptions have
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ the same attribute type or its subtype and the provided language tags
+ options are to be returned. Thus if a client requests just the
+ attribute "name;lang-en", the server would return "name;lang-en" and
+ "CN;lang-en;lang-ja" but not "SN" nor "name;lang-fr".
+
+ Clients can provide in the attribute list multiple
+ AttributeDescription which have the same base attribute type but
+ different options. For example a client could provide both
+ "name;lang-en" and "name;lang-fr", and this would permit an attribute
+ with either language tag option to be returned. Note there would be
+ no need to provide both "name" and "name;lang-en" since all subtypes
+ of name would match "name".
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language tag options are to be ignored, just as if they were
+ unknown attribute types.
+
+ If a request is made specifying all attributes or an attribute is
+ requested without providing a language tag option, then all attribute
+ values regardless of their language tag option are returned.
+
+ For example, if the client requests a "description" attribute, and a
+ matching entry contains the following attributes:
+
+ objectclass: top
+ objectclass: organization
+ O: Software GmbH
+ description: software
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+ postalAddress: Berlin 8001 Germany
+ postalAddress;lang-de: Berlin 8001 Deutschland
+
+ The server would return:
+
+ description: software
+ description;lang-en: software products
+ description;lang-de: Softwareprodukte
+
+
+2.4. Compare
+
+ Language tag options can be present in an AttributeDescription used in
+ a compare request AttributeValueAssertion. This is to be treated by
+ servers the same as the use of language tag options in a search filter
+ with an equality match, as described in section 2.2. If there is no
+ attribute in the entry with the same subtype and language tag options,
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 6]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ the noSuchAttributeType error will be returned.
+
+ Thus for example a compare request of type "name" and assertion value
+ "Johann", against an entry containing the following attributes:
+
+ objectclass: top
+ objectclass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ would cause the server to return compareTrue.
+
+ However, if the client issued a compare request of type "name;lang-de"
+ and assertion value "Johann" against the above entry, the request
+ would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any comparison which includes a language tag
+ option will always fail to locate an attribute, and
+ noSuchAttributeType will be returned.
+
+
+ 2.5. Add Operation
+
+ Clients can provide language options in AttributeDescription in
+ attributes of a new entry to be created.
+
+ A client can provide multiple attributes with the same attribute type
+ and value, so long as each attribute has a different set of language
+ tag options.
+
+ For example, the following is a legal request.
+
+ dn: CN=John Smith,DC=example,DC=com
+ objectclass: top
+ objectclass: person
+ objectclass: residentialPerson
+ name: John Smith
+ CN: John Smith
+ CN;lang-en: John Smith
+ SN: Smith
+ SN;lang-en;lang-en-US: Smith
+ streetAddress: 1 University Street
+ streetAddress;lang-en: 1 University Street
+ streetAddress;lang-fr: 1 rue Universite
+ houseIdentifier;lang-fr: 9e etage
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 7]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ If a server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute. If the server forbids the addition of unrecognized
+ attributes then it MUST fail the add request with an appropriate
+ result code.
+
+
+2.6. Modify Operation
+
+ A client can provide language tag options in an AttributeDescription
+ as part of a modification element in the modify operation.
+
+ Attribute types and language tag options MUST match exactly against
+ values stored in the directory. For example, if the modification is a
+ "delete", then if the stored values to be deleted have language tag
+ options, then those language tag options MUST be provided in the
+ modify operation, and if the stored values to be deleted do not have
+ any language tag option, then no language tag option is to be
+ provided.
+
+ If the server does not support storing language tag options with
+ attribute values in the DIT, then it MUST treat an
+ AttributeDescription with a language tag option as an unrecognized
+ attribute, and MUST fail the request with an appropriate result code.
+
+
+3. Use of Language Ranges in LDAP
+
+ Since the publication of RFC 2596, it has become apparent that there
+ is a need to provide a mechanism for a client to request attributes
+ based upon set of language tag options whose tags all begin with the
+ same sequence of subtags.
+
+ AttributeDescriptions containing language range options are intended
+ to be used in attribute value assertions, search attribute lists, and
+ other places where the client desires to provide an attribute
+ description matching of a range of language tags associated with
+ attributes.
+
+ A language range option conforms to the following ABNF [RFC 2234]:
+
+ language-range-option = "lang-" [ Language-Tag "-" ]
+
+ where the Language-Tag production is as defined in BCP 47 [RFC3066].
+
+ A language range option matches a langugage tag option if language
+ range option less the trailing "-" matches exactly the language tag or
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 8]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ if the language range option (including the trailing "-") matches a
+ prefix of the language tag option. Note that the language range
+ option "lang-" matches all language tag options.
+
+ Examples of valid AttributeDescription containing language range
+ options:
+
+ givenName;lang-en-
+ CN;lang-
+ O;lang-x-;x-foobar
+
+ A language range option is not a "subtyping" (or "tag") option
+ [RFC2251bis]. Attributes cannot be stored with language range
+ options. Any attempt to add or update an attribute description with a
+ languague range option SHALL be treated as an undefined attribute type
+ and result in an error.
+
+ A language range option has no effect on the tranfer encoding nor on
+ the syntax of the attribute values.
+
+ Servers SHOULD support assertion of language ranges for any attribute
+ which they allow to stored with language tags.
+
+
+3.1. Search Filter
+
+ If a langugage range option is present in an AttributeDescription in
+ an assertion, then for each entry within scope, the values of each
+ attribute whose AttributeDescription consists of the same attribute
+ type or its subtypes and contains a language tag option matching the
+ language range option are to be returned.
+
+ Thus for example a filter of an equality match of type "name;lang-en-"
+ and assertion value "Billy Ray", against the following directory entry
+
+ dn: SN=Ray,DC=example,DC=com
+ objectclass: top DOES NOT MATCH (wrong type)
+ objectclass: person DOES NOT MATCH (wrong type)
+ name;lang-en-US: Billy Ray MATCHES
+ name;lang-en-US: Billy Bob DOES NOT MATCH (wrong value)
+ CN;lang-en-US: Billy Ray MATCHES
+ CN;lang-en-US;x-foobar: Billy Ray MATCHES
+ CN;lang-en;x-foobar: Billy Ray MATCHES
+ CN;x-foobar: Billy Ray DOES NOT MATCH (no lang-)
+ name: Billy Ray DOES NOT MATCH (no lang-)
+ SN;lang-en-GB;lang-en-US: Billy Ray MATCHES
+ SN: Ray DOES NOT MATCH (wrong value)
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 9]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ (Note that "CN" and "SN" are subtypes of "name".)
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any assertion which includes a language range
+ option will not match as it is an unrecognized attribute type. No
+ error would be returned because of this; a presence filter would
+ evaluate to FALSE and all other assertions to Undefined.
+
+
+3.2. Requested Attributes in Search
+
+ Clients can provide language range options in AttributeDescription in
+ the requested attribute list in a search request.
+
+ If a language range option is provided in an attribute description,
+ then only attributes in a directory entry whose attribute descriptions
+ have the same attribute type or its subtype and a language tag option
+ matching the provided language range option are to be returned. Thus
+ if a client requests just the attribute "name;lang-en-", the server
+ would return "name;lang-en-US" and "CN;lang-en;lang-ja" but not "SN"
+ nor "name;lang-fr".
+
+ Clients can provide in the attribute list multiple
+ AttributeDescription which have the same base attribute type but
+ different options. For example a client could provide both
+ "name;lang-en-" and "name;lang-fr-", and this would permit an
+ attribute whose type was name or subtype of name and with a language
+ tag option matching either language range option to be returned.
+
+ If a server does not support storing attributes with language tag
+ options in the DIT, then any attribute descriptions in the list which
+ include language range options are to be ignored, just as if they were
+ unknown attribute types.
+
+
+3.3. Compare
+
+ Language range options can be present in an AttributeDescription used
+ in a compare request AttributeValueAssertion. This is to be treated
+ by servers the same as the use of language range options in a search
+ filter with an equality match, as described in section 3.1. If there
+ is no attribute in the entry with the same subtype and a matching
+ language tag option, the noSuchAttributeType error will be returned.
+
+ Thus for example a compare request of type "name;lang-" and assertion
+ value "Johann", against the entry with the following attributes:
+
+ objectclass: top
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 10]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ objectclass: person
+ givenName;lang-de-DE: Johann
+ CN: Johann Sibelius
+ SN: Sibelius
+
+ will cause the server to return compareTrue. (Note that the language
+ range option "lang-" matches any language tag option.)
+
+ However, if the client issued a compare request of type "name;lang-de"
+ and assertion value "Sibelius" against the above entry, the request
+ would fail with the noSuchAttributeType error.
+
+ If the server does not support storing attributes with language tag
+ options in the DIT, then any comparison which includes a language
+ range option will always fail to locate an attribute, and
+ noSuchAttributeType will be returned.
+
+
+4. Discovering Language Option Support
+
+ A server SHOULD indicate that it supports storing attributes with
+ language tag options in the DIT by publishing OID.TDB as a value of
+ the supportedFeatures [FEATURES] attribute in the root DSE.
+
+ A server SHOULD indicate that it supports language range matching of
+ attributes with language tag options stored in the DIT by publishing
+ OID.TDB as a value of the supportedFeatures [FEATURES] attribute in
+ the root DSE.
+
+ A server MAY restrict use of language tag options to a subset of the
+ attribute types it recongizes. This document does not define a
+ mechanism for determining which subset of attribute types can be used
+ with language tag options.
+
+
+5. Security Considerations
+
+ There are no known security considerations for this document. See the
+ security considerations sections of [LDAPTS] for security
+ considerations of LDAP in general.
+
+
+6. Acknowledgements
+
+ This document is a revision of RFC 2596 by Mark Wahl and Tim Howes.
+ RFC 2596 was a product of the IETF ASID and LDAPEXT working groups.
+
+ This document borrows from a number of IETF documents including BCP
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 11]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ 47.
+
+
+7. References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14 (also RFC 2119), March 1997.
+
+ [RFC2234] D. Crocker, P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+ Access Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2251bis] Sermersheim, J., "Lightweight Directory Access Protocol
+ (v3)", draft-ietf-ldapbis-protocol-xx.txt (a work in
+ progress).
+
+ [RFC3066] Alvestrand, H., "Tags for the Identification of Languages",
+ BCP 47 (also RFC 3066), January 2001.
+
+ [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access
+ Protocol (v3): Technical Specification",
+ draft-ietf-ldapbis-ldapv3-ts-00.txt (a work in progress).
+
+ [FEATURES] K. Zeilenga, "Feature Discovery in LDAP",
+ draft-zeilenga-ldap-features-xx.txt (a work in progress).
+
+
+A. Differences from RFC 2596
+
+ This document adds support for language ranges, provides a mechansism
+ that a client can use to discover whether a server supports language
+ tags, and clarifies how attributes with multiple language tags are to
+ be treated. This document is a significant rewrite of RFC 2596.
+
+
+B. Differences from X.500(1997)
+
+ X.500(1997) defines a different mechanism, contexts, as the means of
+ representing language tags (codes). This section summarizes the major
+ differences in approach.
+
+ a) An X.500 operation which has specified a language code on a value
+ matches a value in the directory without a language code.
+ b) LDAP references BCP 47 [RFC3066], which allows for IANA
+ registration of new tags as well as unregistered tags.
+ c) LDAP supports language ranges.
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 12]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-rfc2596-00.txt 13 November 2001
+
+
+ d) LDAP does not allow language tags (and ranges) in distinguished
+ names.
+ e) X.500 describes subschema administration procedures to allow
+ language codes to be associated with particular attributes types.
+
+
+Copyright 2001, The Internet Society. All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga Language Tags and Ranges in LDAP [Page 13]
+\f
projects / openldap / commitdiff