5. Considerazioni operative (Operational Considerations)

2. I caratteri CTL e altri caratteri non grafici sono difficili da rappresentare in un'interfaccia utente ed è meglio evitarli.

3. Sebbene i caratteri jolly di lista ("%" e "*") siano validi in un nome di casella di posta, è difficile utilizzare tali nomi di caselle di posta con i comandi LIST e LSUB a causa del conflitto con l'interpretazione dei caratteri jolly.

4. Di solito, un carattere (determinato dall'implementazione del server) è riservato per delimitare i livelli di gerarchia.

5. Due caratteri, "#" e "&", hanno significati per convenzione e dovrebbero essere evitati tranne quando utilizzati in quella convenzione.

5.1.1. Denominazione della gerarchia delle caselle di posta (Mailbox Hierarchy Naming)

Se si desidera esportare nomi di caselle di posta gerarchici, i nomi delle caselle di posta DEVONO (MUST) essere gerarchici da sinistra a destra utilizzando un singolo carattere per separare i livelli di gerarchia. Lo stesso carattere separatore di gerarchia viene utilizzato per tutti i livelli di gerarchia all'interno di un singolo nome.

5.1.2. Convenzione di denominazione dello spazio dei nomi delle caselle di posta (Mailbox Namespace Naming Convention)

Per convenzione, il primo elemento gerarchico di qualsiasi nome di casella di posta che inizia con "#" identifica lo "spazio dei nomi (Namespace)" del resto del nome. Ciò consente di disambiguare tra diversi tipi di archivi di caselle di posta, ognuno dei quali ha i propri spazi dei nomi.

Ad esempio, le implementazioni che offrono l'accesso ai newsgroup USENET POSSONO (MAY) utilizzare lo spazio dei nomi "#news" per partizionare lo spazio dei nomi dei newsgroup USENET da quello di altre caselle di posta. Pertanto, il newsgroup comp.mail.misc avrebbe un nome di casella di posta "#news.comp.mail.misc" e il nome "comp.mail.misc" può riferirsi a un oggetto diverso (ad esempio, una casella di posta privata di un utente).

5.1.3. Convenzione di denominazione internazionale delle caselle di posta (Mailbox International Naming Convention)

Per convenzione, i nomi internazionali delle caselle di posta in IMAP4rev1 sono specificati utilizzando una versione modificata della codifica UTF-7 (Encoding) descritta in [UTF-7]. L'UTF-7 modificato può essere utilizzabile anche nei server che implementano una versione precedente di questo protocollo.

Nell'UTF-7 modificato, i caratteri US-ASCII stampabili, ad eccezione di "&", rappresentano se stessi; ovvero, i caratteri con valori di ottetto 0x20-0x25 e 0x27-0x7e. Il carattere "&" (0x26) è rappresentato dalla sequenza di due ottetti "&-".

Tutti gli altri caratteri (valori di ottetto 0x00-0x1f e 0x7f-0xff) sono rappresentati in BASE64 modificato, con un'ulteriore modifica rispetto a [UTF-7] in cui viene utilizzato "," al posto di "/". Il BASE64 modificato NON DEVE (MUST NOT) essere utilizzato per rappresentare qualsiasi carattere US-ASCII stampabile che può rappresentare se stesso.

"&" viene utilizzato per passare al BASE64 modificato e "-" per tornare a US-ASCII. Non esiste un passaggio implicito da BASE64 a US-ASCII e i passaggi nulli ("-&" in BASE64; si noti che "&-" in US-ASCII significa "&") non sono consentiti. Tuttavia, tutti i nomi iniziano in US-ASCII e DEVONO (MUST) terminare in US-ASCII; ovvero, un nome che termina con un carattere ISO-10646 non ASCII DEVE (MUST) terminare con un "-".

Lo scopo di queste modifiche è correggere i seguenti problemi con UTF-7:

1. UTF-7 utilizza il carattere "+" per il passaggio; ciò è in conflitto con l'uso comune di "+" nei nomi delle caselle di posta, in particolare nei nomi dei newsgroup USENET.

2. La codifica UTF-7 è BASE64 che utilizza il carattere "/"; ciò è in conflitto con l'uso di "/" come delimitatore di gerarchia popolare.

3. UTF-7 vieta l'uso non codificato di ""; ciò è in conflitto con l'uso di "" come delimitatore di gerarchia popolare.

4. UTF-7 vieta l'uso non codificato di ""; ciò è in conflitto con l'uso di "" in alcuni server come indicatore di directory home.

5. UTF-7 consente più forme alternative per rappresentare la stessa stringa; in particolare, i caratteri US-ASCII stampabili possono essere rappresentati in forma codificata.

Sebbene l'UTF-7 modificato sia una convenzione, stabilisce determinati requisiti sulla gestione del server di qualsiasi nome di casella di posta con un carattere "&" incorporato. In particolare, le implementazioni del server DEVONO (MUST) preservare la forma esatta della parte BASE64 modificata di un nome UTF-7 modificato e trattare quel testo come sensibile alle maiuscole, anche se i nomi sono altrimenti insensibili alle maiuscole o piegati in maiuscole/minuscole.

Le implementazioni del server DOVREBBERO (SHOULD) verificare che qualsiasi nome di casella di posta con un carattere "&" incorporato, utilizzato come argomento per CREATE, sia: nella sintassi UTF-7 modificata corretta, non abbia passaggi superflui e non abbia codifica in BASE64 modificato di alcun carattere US-ASCII stampabile che può rappresentare se stesso. Tuttavia, le implementazioni del client NON DEVONO (MUST NOT) dipendere dal server che fa questo e NON DOVREBBERO (SHOULD NOT) tentare di creare un nome di casella di posta con un carattere "&" incorporato a meno che non sia conforme alla sintassi UTF-7 modificata.

Le implementazioni del server che esportano un archivio di posta che non segue la convenzione UTF-7 modificata DEVONO (MUST) convertire in UTF-7 modificato qualsiasi nome di casella di posta che contenga caratteri non ASCII o il carattere "&".

Ad esempio, ecco un nome di casella di posta che mescola testo inglese, cinese e giapponese:
~peter/mail/&U,BTFw-/&ZeVnLIqe-

Ad esempio, la stringa "&Jjo!" non è un nome di casella di posta valido perché non contiene un passaggio a US-ASCII prima del "!". La forma corretta è "&Jjo-!". La stringa "&U,BTFw-&ZeVnLIqe-" non è consentita perché contiene un passaggio superfluo. La forma corretta è "&U,BTF2XlZyyKng-".

5.2. Aggiornamenti delle dimensioni delle caselle di posta e dello stato dei messaggi (Mailbox Size and Message Status Updates)

In qualsiasi momento, un server può inviare dati che il client non ha richiesto. A volte, tale comportamento è RICHIESTO (REQUIRED). Ad esempio, agenti diversi dal server POSSONO (MAY) aggiungere messaggi alla casella di posta (ad esempio, consegna di nuovi messaggi), modificare i flag dei messaggi nella casella di posta (ad esempio, accesso simultaneo alla stessa casella di posta da parte di più agenti) o persino rimuovere messaggi dalla casella di posta. Un server DEVE (MUST) inviare automaticamente aggiornamenti delle dimensioni della casella di posta se viene osservata una modifica delle dimensioni della casella di posta durante l'elaborazione di un comando. Un server DOVREBBE (SHOULD) inviare automaticamente aggiornamenti dei flag dei messaggi, senza richiedere che il client richieda esplicitamente tali aggiornamenti.

Esistono regole speciali per la notifica del server a un client sulla rimozione di messaggi per prevenire errori di sincronizzazione; vedere la descrizione della risposta EXPUNGE per maggiori dettagli. In particolare, NON è consentito inviare una risposta EXISTS che ridurrebbe il numero di messaggi nella casella di posta; solo la risposta EXPUNGE può farlo.

Indipendentemente dalle decisioni di implementazione che un client prende sulla memorizzazione dei dati dal server, un'implementazione del client DEVE (MUST) registrare gli aggiornamenti delle dimensioni della casella di posta. NON DEVE (MUST NOT) presupporre che qualsiasi comando dopo la selezione iniziale della casella di posta restituirà le dimensioni della casella di posta.

5.3. Risposta quando nessun comando è in corso (Response when no Command in Progress)

Le implementazioni del server sono autorizzate a inviare una risposta non contrassegnata (tranne EXPUNGE) mentre non è in corso alcun comando. Le implementazioni del server che inviano tali risposte DEVONO (MUST) gestire considerazioni sul controllo di flusso. Nello specifico, DEVONO (MUST) (1) verificare che la dimensione dei dati non superi la dimensione della finestra disponibile del trasporto sottostante, o (2) utilizzare scritture non bloccanti.

5.4. Timer di disconnessione automatica (Autologout Timer)

Se un server ha un timer di disconnessione automatica per inattività, la durata di quel timer DEVE (MUST) essere di almeno 30 minuti. La ricezione di QUALSIASI comando dal client durante quell'intervallo DOVREBBE (SHOULD) essere sufficiente per resettare il timer di disconnessione automatica.

5.5. Più comandi in corso (Multiple Commands in Progress)

Il client PUÒ (MAY) inviare un altro comando senza attendere la risposta del risultato di completamento di un comando, soggetto a regole di ambiguità (vedere sotto) e vincoli di controllo di flusso sul flusso di dati sottostante. Allo stesso modo, un server PUÒ (MAY) iniziare a elaborare un altro comando prima di completare l'elaborazione del comando corrente, soggetto a regole di ambiguità. Tuttavia, qualsiasi risposta di richiesta di continuazione del comando e continuazioni del comando DEVONO (MUST) essere negoziate prima che venga avviato qualsiasi comando successivo.

L'eccezione è se risulterebbe un'ambiguità a causa di un comando che influenzerebbe i risultati di altri comandi. I client NON DEVONO (MUST NOT) inviare più comandi senza attendere se ne risulterebbe un'ambiguità. Se il server rileva una possibile ambiguità, DEVE (MUST) eseguire i comandi fino al completamento nell'ordine dato dal client.

L'esempio più ovvio di ambiguità è quando un comando influenzerebbe i risultati di un altro comando, ad esempio un FETCH dei flag di un messaggio e uno STORE dei flag dello stesso messaggio.

Un'ambiguità non ovvia si verifica con comandi che consentono una risposta EXPUNGE non contrassegnata (comandi diversi da FETCH, STORE e SEARCH), poiché una risposta EXPUNGE non contrassegnata può invalidare i numeri di sequenza in un comando successivo. Questo non è un problema per i comandi FETCH, STORE o SEARCH perché ai server è vietato inviare risposte EXPUNGE mentre uno qualsiasi di questi comandi è in corso. Pertanto, se il client invia qualsiasi comando diverso da FETCH, STORE o SEARCH, DEVE (MUST) attendere la risposta del risultato di completamento prima di inviare un comando con numeri di sequenza dei messaggi.

Nota: UID FETCH, UID STORE e UID SEARCH sono comandi diversi da FETCH, STORE e SEARCH. Se il client invia un comando UID, deve attendere una risposta del risultato di completamento prima di inviare un comando con numeri di sequenza dei messaggi.