3. Modello del protocollo (Protocol Model)
Il modello generale adottato da questo protocollo è quello di client che eseguono operazioni di protocollo contro server. In questo modello, un client trasmette una richiesta di protocollo che descrive l'operazione da eseguire a un server. Il server è quindi responsabile dell'esecuzione delle operazioni necessarie nella directory. Al completamento di un'operazione, il server tipicamente restituisce una risposta contenente i dati appropriati al client richiedente.
Le operazioni di protocollo sono generalmente indipendenti l'una dall'altra. Ogni operazione è elaborata come un'azione atomica, lasciando la directory in uno stato coerente.
Sebbene i server siano tenuti (required) a restituire risposte ogni volta che tali risposte sono definite nel protocollo, non vi è alcun requisito di comportamento sincrono da parte dei client o dei server. Le richieste e le risposte per più operazioni possono generalmente essere scambiate tra un client e un server in qualsiasi ordine. Se richiesto, il comportamento sincrono può essere controllato dalle applicazioni client.
Le operazioni di protocollo di base definite in questo documento possono essere mappate su un sottoinsieme del servizio astratto di directory X.500 (1993) [X.511]. Tuttavia, non esiste una mappatura uno-a-uno tra le operazioni LDAP e le operazioni del protocollo di accesso alle directory X.500 (Directory Access Protocol, DAP). Le implementazioni di server che fungono da gateway per le directory X.500 potrebbero dover effettuare più richieste DAP per servire una singola richiesta LDAP.
3.1. Operation and LDAP Message Layer Relationship (Relazione tra operazioni e livello di messaggio LDAP)
Le operazioni di protocollo vengono scambiate al livello di messaggio LDAP. Quando la connessione di trasporto viene chiusa, tutte le operazioni incomplete al livello di messaggio LDAP vengono abbandonate (quando possibile) o completate senza trasmissione della risposta (quando non è possibile abbandonarle). Inoltre, quando la connessione di trasporto viene chiusa, il client non deve (MUST NOT) assumere che le operazioni di aggiornamento incomplete abbiano avuto successo o fallito.