1. Come leggere questo documento
1.1. Organizzazione del documento
Questo documento è scritto dal punto di vista dell'implementatore di un client o server IMAP4rev1. Oltre alla panoramica del protocollo nella Sezione 2, non è ottimizzato per chi voglia comprenderne il funzionamento. Il materiale nelle Sezioni da 3 a 5 fornisce il contesto generale e le definizioni con cui opera IMAP4rev1.
Le Sezioni 6, 7 e 9 descrivono rispettivamente i comandi, le risposte e la sintassi IMAP. Le loro relazioni sono tali che è quasi impossibile comprenderne una separatamente dalle altre. In particolare, non tentare di dedurre la sintassi di un comando dalla sola sezione dei comandi; fare invece riferimento alla sezione Sintassi formale.
1.2. Convenzioni usate in questo documento
Le "convenzioni" sono principi o procedure di base. Le convenzioni del documento sono indicate in questa sezione.
Negli esempi, "C:" e "S:" indicano le righe inviate rispettivamente dal client e dal server.
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [KEYWORDS].
La parola "can" (non "may") viene usata per riferirsi a una possibile circostanza o situazione, anziché a una funzionalità opzionale del protocollo.
"User" è usato per riferirsi a un utente umano, mentre "client" si riferisce al software eseguito dall'utente.
"Connection" si riferisce all'intera sequenza di interazione client/server dallo stabilimento iniziale della connessione di rete fino alla sua terminazione.
"Session" si riferisce alla sequenza di interazione client/server dal momento in cui viene selezionata una casella di posta (comando SELECT o EXAMINE) fino al termine della selezione (SELECT o EXAMINE di un'altra casella di posta, comando CLOSE o terminazione della connessione).
I caratteri sono US-ASCII a 7 bit salvo diversa indicazione. Gli altri set di caratteri sono indicati usando un "CHARSET", come descritto in [MIME-IMT] e definito in [CHARSET]. Oltre a definire il set di caratteri, i CHARSET hanno importanti semantiche aggiuntive; per maggiori dettagli fare riferimento a tali documenti.
In IMAP esistono diverse convenzioni di protocollo. Esse si riferiscono ad aspetti della specifica che non fanno strettamente parte del protocollo IMAP, ma riflettono una pratica generalmente accettata. Le implementazioni devono conoscere tali convenzioni ed evitare conflitti, indipendentemente dal fatto che le implementino. Ad esempio, "&" non può essere usato come delimitatore di gerarchia, poiché entra in conflitto con la Mailbox International Naming Convention e ne sono influenzati anche altri usi di "&" nei nomi delle caselle di posta.
1.3. Note speciali per gli implementatori
Gli implementatori del protocollo IMAP sono vivamente incoraggiati a leggere, insieme a questo documento, il documento di raccomandazioni per l'implementazione IMAP [IMAP-IMPLEMENTATION], così da comprendere le complessità del protocollo e come realizzare al meglio un prodotto interoperabile.
IMAP4rev1 è progettato per essere compatibile verso l'alto con i protocolli [IMAP2] e IMAP2bis non pubblicato. IMAP4rev1 è in gran parte compatibile con il protocollo IMAP4 descritto in RFC 1730; l'eccezione riguarda alcune funzionalità aggiunte in RFC 1730 che si sono dimostrate problematiche e sono state successivamente rimosse. Nel corso dell'evoluzione di IMAP4rev1, alcuni aspetti dei protocolli precedenti sono divenuti obsoleti. I comandi, le risposte e i formati di dati obsoleti che un'implementazione IMAP4rev1 può incontrare quando opera con un'implementazione precedente sono descritti in [IMAP-OBSOLETE].
Altri problemi di compatibilità con IMAP2bis, la variante più comune del protocollo precedente, sono trattati in [IMAP-COMPAT]. Una discussione completa dei problemi di compatibilità con varianti rare (e presumibilmente estinte) di [IMAP2] è disponibile in [IMAP-HISTORICAL]; tale documento è principalmente di interesse storico.
IMAP è stato originariamente sviluppato per il precedente standard [RFC-822] e, di conseguenza, diversi elementi di recupero in IMAP incorporano "RFC822" nel proprio nome. Salvo RFC822.SIZE, esistono sostituti più moderni; ad esempio, la versione moderna di RFC822.HEADER è BODY.PEEK[HEADER]. In ogni caso, "RFC822" dovrebbe essere interpretato come riferimento allo standard aggiornato [RFC-2822].