6. Autres considérations
6.1. Préservation des informations utilisateur
Il est possible de définir des syntaxes assorties d'exigences particulières concernant la préservation de la valeur et/ou de la forme (représentation) de celle-ci. Par exemple, une syntaxe contenant des données signées numériquement peut imposer au serveur de préserver à la fois la valeur et la forme de la valeur présentée, afin que la signature ne soit pas invalidée.
Lorsque de telles exigences n'ont pas été explicitement formulées, les serveurs devraient (SHOULD) préserver la valeur des informations utilisateur, mais peuvent (MAY) la renvoyer sous une forme différente. Si un serveur ne peut (ou ne veut) pas préserver cette valeur, il doit (SHALL) veiller à renvoyer une valeur équivalente (selon la Section 2.3).
6.2. Noms courts
Les noms courts, également appelés descripteurs, servent d'alias plus lisibles aux identifiants d'objet et identifient divers éléments de schéma. Il n'est toutefois pas prévu que les mises en œuvre LDAP dotées d'une interface utilisateur humaine affichent ces noms courts (ou les identifiants d'objet qu'ils désignent) à l'utilisateur. Elles effectueront plutôt vraisemblablement des traductions (par exemple en exprimant le nom court dans l'une des langues nationales locales). Ainsi, le nom court "st" (stateOrProvinceName) pourrait être affiché sous la forme "Land" à un utilisateur germanophone.
Un même nom court peut avoir des significations différentes dans des sous-schémas différents et, au sein d'un sous-schéma donné, désigner des identifiants d'objet différents, chacun identifiant une sorte distincte d'élément de schéma.
Les mises en œuvre doivent (MUST) être préparées à ce qu'un même nom court soit utilisé dans un sous-schéma pour désigner différentes sortes d'éléments de schéma. Ainsi, un sous-schéma peut contenir une classe d'objet 'x-fubar' et un type d'attribut 'x-fubar'.
Les mises en œuvre doivent (MUST) être préparées à ce qu'un même nom court soit utilisé dans des sous-schémas différents pour désigner des éléments de schéma différents. Ainsi, deux règles de correspondance 'x-fubar' peuvent exister, chacune dans un sous-schéma différent.
Les procédures d'enregistrement des noms courts (descripteurs) sont détaillées dans le BCP 64, RFC 4520 [RFC4520].
6.3. Mise en cache et mise en miroir
Certains serveurs peuvent conserver des copies en cache ou des copies miroir d'entrées, utilisables pour répondre aux recherches et aux requêtes de comparaison, mais renvoient des références ou contactent d'autres serveurs lorsque des opérations de modification sont demandées. Les serveurs qui réalisent une mise en miroir ou une mise en cache doivent (MUST) veiller à ne violer aucune contrainte de contrôle d'accès imposée aux données par le serveur d'origine.