Use of Language Codes in LDAP
obsoleted by
- rfc-3866 — Language Tags and Ranges in the Lightweight Directory Access Protocol (LDAP)
Extracted elements (22)
An attribute with a language code is treated as a subtype of the attribute without a language code. This means that a search filter or requested attribute list without a language code will match or return all values regardless of their language code, preserving backward compatibility.
Language codes are case insensitive (e.g., 'en-us' equals 'EN-US') and must not be structurally parsed beyond pattern matching. This avoids complex normalization logic and treats codes as opaque identifiers, which simplifies implementation.
Language codes have no effect on character set encoding; the UTF-8 representation of UniversalString (ISO 10646) is always used for DirectoryString syntax values. The language tag is purely metadata about the natural language, not about the encoding.
A client may provide multiple AttributeDescriptions with the same base attribute type but different language options in a search request (e.g., both 'name;lang-en' and 'name;lang-fr'), enabling retrieval of values in multiple languages in a single query.
If a server does not support storing language codes with attribute values in the DIT, any search filter including a language code will always fail to match (presence filter evaluates to FALSE, other forms to Undefined) without returning an error, since the language-coded attribute is treated as an unrecognized type.
When a language code is present in a search filter AttributeDescription, only directory attribute values matching the base attribute type or its subtype, the exact language code, and the assertion value will match. A filter for 'name;lang-en' does NOT match 'name;lang-en-US', so clients SHOULD NOT use language codes in search filter AttributeDescriptions.
When no language code is specified in a search filter, all attribute values matching the base attribute type and assertion value are returned, regardless of any language code on the stored values. A filter on 'name' matches 'name;lang-EN-US: Billy Ray'.
X.500(1997) uses a different mechanism called 'contexts' for language tags. Key differences: X.500 allows a language-coded value to match a directory value without a language code; LDAP references RFC 1766 allowing IANA registration; LDAP prohibits language codes in DNs; and X.500 has subschema administration for associating language codes with attribute types.
All LDAP implementations MUST be prepared to accept language codes in the LDAP protocols, regardless of whether the server is capable of storing attributes with language codes in the directory.
Clients MUST NOT use language codes in the attribute value or values which form the RDN of a new entry in an Add operation.
Clients SHOULD NOT use the language code option in AttributeDescription fields in search filters, as it will often filter out desirable values where the language code does not match exactly.
If a language code is provided in a requested attribute list, the server MUST NOT return attribute values with a different language code. For example, requesting 'description;lang-en' must not return 'description' or 'description;lang-fr'.
If a server does not support storing language codes and receives an Add request with an AttributeDescription containing a language code, it MUST treat that attribute as unrecognized. If the server forbids unrecognized attributes, it MUST fail the add request with the appropriate result code.
If the server does not support storing language codes and receives a Modify operation with an AttributeDescription containing a language code, it MUST treat it as an unrecognized attribute and MUST fail the request with an appropriate result code.
Implementations MUST NOT interpret the structure of a language code when comparing two codes, and MUST treat them as simply strings of characters. Client and server implementations MUST allow any arbitrary string following RFC 1766 patterns to be used as a language code.
In a compare request, if there is no attribute in the entry with the same subtype and language code as specified, the noSuchAttributeType error MUST be returned. Clients SHOULD NOT use language code options in compare request AttributeDescriptions.
In a Modify operation, attribute types and language codes MUST match exactly against values stored in the directory. If stored values have a language code, the language code MUST be provided in the modify; if stored values have no language code, none is to be provided.
Language codes MUST NOT be used in forming Distinguished Names or Relative Distinguished Names; no attribute description options are permitted in DNs or RDNs.
Servers SHOULD use only printable ASCII characters in the errorMessage field of diagnostic messages, as not all clients will be able to display the full range of Unicode.
Servers which support storing language codes in the DIT MUST allow any recognized attribute with the Directory String syntax to have a language option associated with it. Servers SHOULD allow language options to be associated with other attribute types as well.
A language option in an LDAP AttributeDescription is formed as 'lang-' followed by a lang-code (a printable ASCII code as defined in RFC 1766). Multiple language options may be present on a single attribute value. Examples: 'givenName;lang-en-US', 'CN;lang-ja'.
There are no known security considerations specific to this document. Implementors should refer to the security considerations sections of RFC 2251 (LDAPv3) and RFC 2252 (Attribute Syntax Definitions) for general LDAP security considerations.