Passa al contenuto principale

6. Altre considerazioni

6.1. Conservazione delle informazioni utente​

Possono essere definite sintassi con requisiti specifici per la conservazione del valore e/o della forma (rappresentazione) del valore. Ad esempio, una sintassi contenente dati firmati digitalmente può imporre al server di conservare sia il valore sia la forma del valore presentato, per garantire che la firma non venga invalidata.

Quando tali requisiti non sono stati dichiarati esplicitamente, i server dovrebbero (SHOULD) conservare il valore delle informazioni utente, ma possono (MAY) restituirlo in una forma diversa. Quando un server non è in grado (o non intende) conservare il valore delle informazioni utente, deve (SHALL) assicurare che venga restituito un valore equivalente (secondo la Sezione 2.3).

6.2. Nomi brevi​

I nomi brevi, noti anche come descrittori, sono utilizzati come alias più leggibili per gli identificatori di oggetto e per identificare vari elementi dello schema. Tuttavia, non ci si aspetta che le implementazioni LDAP dotate di un'interfaccia utente umana mostrino all'utente questi nomi brevi (o gli identificatori di oggetto a cui fanno riferimento). È invece più probabile che eseguano traduzioni, ad esempio esprimendo il nome breve in una delle lingue nazionali locali. Per esempio, il nome breve "st" (stateOrProvinceName) potrebbe essere mostrato come "Land" a un utente di lingua tedesca.

Lo stesso nome breve può avere significati diversi in sottoschemi diversi e, all'interno di un particolare sottoschema, può fare riferimento a identificatori di oggetto diversi, ciascuno dei quali identifica un tipo diverso di elemento dello schema.

Le implementazioni devono (MUST) essere preparate al fatto che lo stesso nome breve possa essere utilizzato in un sottoschema per fare riferimento a tipi diversi di elementi dello schema. In altre parole, in un sottoschema potrebbero essere presenti una classe di oggetti 'x-fubar' e un tipo di attributo 'x-fubar'.

Le implementazioni devono (MUST) essere preparate al fatto che lo stesso nome breve possa essere utilizzato in sottoschemi diversi per fare riferimento a elementi dello schema diversi. In altre parole, potrebbero esistere due regole di corrispondenza 'x-fubar', ciascuna in un sottoschema diverso.

Le procedure per la registrazione dei nomi brevi (descrittori) sono descritte in dettaglio in BCP 64, RFC 4520 [RFC4520].

6.3. Cache e shadowing​

Alcuni server possono contenere copie in cache o copie shadow delle voci, utilizzabili per rispondere a ricerche e richieste di confronto, ma restituiscono riferimenti o contattano altri server se vengono richieste operazioni di modifica. I server che eseguono shadowing o caching devono (MUST) assicurare di non violare alcun vincolo di controllo degli accessi applicato ai dati dal server di origine.