Skip to main content

6. Other Considerations

6.1. Preservation of User Information​

Syntaxes may be defined that have specific value and/or value form (representation) preservation requirements. For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented to ensure that the signature is not invalidated.

Where such requirements have not been explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned.

6.2. Short Names​

Short names, also known as descriptors, are used as more readable aliases for object identifiers and are used to identify various schema elements. However, it is not expected that LDAP implementations with human user interface would display these short names (or the object identifiers they refer to) to the user. Instead, they would most likely be performing translations (such as expressing the short name in one of the local national languages). For example, the short name "st" (stateOrProvinceName) might be displayed to a German-speaking user as "Land".

The same short name might have different meaning in different subschemas, and, within a particular subschema, the same short name might refer to different object identifiers each identifying a different kind of schema element.

Implementations MUST be prepared that the same short name might be used in a subschema to refer to the different kinds of schema elements. That is, there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema.

Implementations MUST be prepared that the same short name might be used in the different subschemas to refer to the different schema elements. That is, there might be two matching rules 'x-fubar', each in different subschemas.

Procedures for registering short names (descriptors) are detailed in BCP 64, RFC 4520 [RFC4520].

6.3. Cache and Shadowing​

Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested. Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.