1. Come leggere questo documento (How to Read This Document)
1.1 Organizzazione di questo documento (Organization of This Document)
Questo documento è scritto dal punto di vista dell'implementatore di un client o server IMAP4rev2. Oltre alla panoramica del protocollo nella sezione 2, non è ottimizzato per chi cerca di comprendere il funzionamento del protocollo. Il materiale nelle sezioni 3, 4 e 5 fornisce il contesto generale e le definizioni con cui opera IMAP4rev2.
Le sezioni 6, 7 e 9 descrivono rispettivamente i comandi (Commands), le risposte (Responses) e la sintassi (Syntax) IMAP. Le relazioni tra questi sono tali che è quasi impossibile comprenderli separatamente. In particolare, non tentare di dedurre la sintassi dei comandi solo dalla sezione dei comandi; fare invece riferimento alla "Sintassi formale" (Formal Syntax) (sezione 9).
1.2 Convenzioni utilizzate in questo documento (Conventions Used in This Document)
Le "convenzioni" sono principi o procedure di base. Le convenzioni del documento sono indicate in questa sezione.
Negli esempi, "C:" e "S:" indicano rispettivamente le righe inviate dal client e dal server. Si noti che ogni riga include il terminatore CRLF.
Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono (deve) essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.
Corrispondenza parole chiave:
- MUST = deve
- MUST NOT = non deve
- REQUIRED = richiesto
- SHALL = deve
- SHALL NOT = non deve
- SHOULD = dovrebbe
- SHOULD NOT = non dovrebbe
- RECOMMENDED = raccomandato
- NOT RECOMMENDED = non raccomandato
- MAY = può
- OPTIONAL = opzionale
La parola "can" (non "may") è usata per riferirsi a una possibile circostanza o situazione, in contrapposizione a una funzionalità facoltativa del protocollo.
"User" (utente) è usato per riferirsi a un utente umano, mentre "client" si riferisce al software eseguito dall'utente.
"Connection" (connessione) si riferisce all'intera sequenza di interazione client/server dall'instaurazione iniziale della connessione di rete fino alla sua terminazione.
"Session" (sessione) si riferisce alla sequenza di interazione client/server dal momento in cui una casella di posta viene selezionata (comando SELECT o EXAMINE) fino al momento in cui la selezione termina (SELECT o EXAMINE di un'altra casella di posta, comando CLOSE, comando UNSELECT o terminazione della connessione).
Il termine "Implicit TLS" (TLS implicito) si riferisce alla negoziazione automatica di TLS ogni volta che viene stabilita una connessione TCP su una particolare porta TCP utilizzata esclusivamente da quel server per connessioni TLS. Il termine "Implicit TLS" è inteso a contrastare con l'uso del comando STARTTLS in IMAP, utilizzato dal client e dal server per negoziare esplicitamente TLS su una connessione TCP in chiaro stabilita.
I caratteri sono UTF-8 a 8 bit (di cui US-ASCII a 7 bit è un sottoinsieme), salvo diversa indicazione. Altri set di caratteri sono indicati utilizzando un "CHARSET", come descritto in [MIME-IMT] e definito in [CHARSET]. I CHARSET hanno importanti semantiche aggiuntive oltre alla definizione di un set di caratteri; consultare questi documenti per maggiori dettagli.
Ci sono diverse convenzioni di protocollo (Protocol Conventions) in IMAP. Queste si riferiscono ad aspetti della specifica che non sono strettamente parte del protocollo IMAP ma riflettono pratiche generalmente accettate. Le implementazioni devono (devono) essere consapevoli di queste convenzioni ed evitare conflitti, indipendentemente dal fatto che implementino o meno la convenzione. Ad esempio, "&" non può (non deve) essere usato come delimitatore di gerarchia (Hierarchy Delimiter) poiché entra in conflitto con la convenzione internazionale di denominazione delle caselle di posta (Mailbox International Naming Convention), e anche altri usi di "&" nei nomi delle caselle di posta sono influenzati.
1.3 Note speciali per gli implementatori (Special Notes to Implementors)
Gli implementatori del protocollo IMAP sono fortemente incoraggiati (raccomandato) a leggere il documento di raccomandazioni per l'implementazione IMAP [IMAP-IMPLEMENTATION] in concomitanza con questo documento, per aiutare a comprendere le complessità di questo protocollo e come costruire al meglio un prodotto interoperabile.
IMAP4rev2 è progettato per essere compatibile all'indietro con i protocolli IMAP4rev1 [RFC3501], IMAP2 [IMAP2] e IMAP2bis non pubblicato [IMAP2BIS]. IMAP4rev2 è in gran parte compatibile con il protocollo IMAP4rev1 descritto in RFC 3501 e il protocollo IMAP4 descritto in [RFC1730]; l'eccezione sono alcune funzionalità aggiunte in [RFC1730] e [RFC3501] che si sono rivelate problematiche e sono state successivamente rimosse o sostituite con alternative migliori.
Altri problemi di compatibilità con IMAP2bis, la variante più comune del protocollo precedente, sono discussi in [IMAP-COMPAT]. Una discussione completa sui problemi di compatibilità con varianti rare di [IMAP2] si trova in [IMAP-HISTORICAL]; questo documento è principalmente di interesse storico.