Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)
obsoletes
- rfc-2596 — Use of Language Codes in LDAP
Extracted elements (25)
Due to attribute description option naming restrictions in LDAP, a different language range syntax (trailing '-') was defined rather than adopting BCP 47's range syntax directly, while preserving consistent range-matching semantics.
Language ranges were added (new in this revision over RFC 2596) because it became apparent that clients needed a mechanism to request attributes based on a set of language tags all beginning with the same sequence of sub-tags.
LDAP does not allow language tags or ranges in distinguished names, unlike X.500(1997) contexts which can be used more broadly. This is an intentional scoping difference.
Unlike X.500(1997), an X.500 operation with a language code on a value matches a directory value without a language code; LDAP does not adopt this behavior, requiring explicit option matching instead.
Per RFC 2251, non-supporting servers treat an AttributeDescription with language tag options as an unrecognized attribute type. To ensure proper function of non-supporting clients, supporting clients SHOULD ensure entries populated with tagged values are also populated with non-tagged values.
Supporting clients SHOULD be prepared to handle entries not populated with tagged values, since non-supporting servers may not store or return language-tagged attributes.
All LDAP implementations MUST be prepared to accept language tags and ranges.
Any attempt to add or update an attribute description with a language range option SHALL be treated as an undefined attribute type and result in an error. Attributes cannot be stored with language range options.
If a request specifies all attributes or an attribute without a language tag option, then all attribute values regardless of their language tag options are returned.
If a server does not support storing attributes with language tag options, then any assertion including a language tag option will not match; a presence assertion evaluates to FALSE and all other assertions to Undefined. No error is returned.
If a server does not support storing language tag options with attribute values, it MUST treat an AttributeDescription with a language tag option as an unrecognized attribute in Add and Modify operations, and MUST fail the request with an appropriate result code.
Implementations MUST NOT interpret the internal structure of a language tag when comparing two tags, and MUST treat them simply as strings of characters. Implementations MUST allow any arbitrary BCP 47-conforming string as a language tag.
In a compare operation, language tag options in the AttributeDescription are treated the same as in a search filter equality match. If no attribute matches the type/subtype and language tag options, noSuchAttributeType is returned.
In a search filter assertion containing language tag options, each entry's attribute values are matched only if the attribute description has the same type or subtype and contains each of the presented (and possibly other) options.
In the Modify operation, attribute types and language tag options MUST match exactly against values stored in the directory. If stored values have language tag options, those MUST be provided in the modify operation.
Servers SHOULD support assertion of language ranges for any attribute type which they allow to be stored with language tags.
Servers which support storing attributes with language tag options SHOULD allow any attribute type with Directory String, IA5 String, or other textual string syntaxes to have language tag options. Clients SHOULD NOT assume servers can store attributes with language tags.
A language range option is formed as 'lang-' followed by an optional Language-Tag and a trailing '-'. The special range 'lang-' matches all language tag options. Language range options are not tagging options and cannot be stored with attributes.
A language tag option is formed as 'lang-' followed by a Language-Tag as defined in BCP 47 (RFC3066). It associates a natural language with attribute values and is a tagging option with no effect on syntax or transfer encoding.
A server SHOULD indicate support for language range matching by publishing OID 1.3.6.1.4.1.4203.1.5.5 as a value of the 'supportedFeatures' attribute in the root DSE.
A server SHOULD indicate support for storing attributes with language tag options by publishing OID 1.3.6.1.4.1.4203.1.5.4 as a value of the 'supportedFeatures' attribute in the root DSE.
IANA registration of two LDAP protocol mechanism OIDs: 1.3.6.1.4.1.4203.1.5.4 (Language Tag Options) and 1.3.6.1.4.1.4203.1.5.5 (Language Range Options), both registered as Feature type per RFC 3383.
Language tags and range options are used solely to indicate natural language of values and for querying. They are not known to raise specific security considerations, but implementors should consult general LDAP security issues in RFC 3377.
Language range option ABNF: language-range-option = 'lang-' [ Language-Tag '-' ]. The trailing '-' distinguishes it from a language tag option.
Language tag option ABNF: language-tag-option = 'lang-' Language-Tag, where Language-Tag = Primary-subtag *( '-' Subtag ), Primary-subtag = 1*8ALPHA, Subtag = 1*8(ALPHA / DIGIT).