5. Considerazioni operative (Operational Considerations)

Le seguenti regole sono elencate qui per garantire che tutte le implementazioni IMAP4rev2 interoperino correttamente.

5.1 Denominazione delle caselle di posta (Mailbox Naming)

In IMAP4rev2, i nomi delle caselle di posta sono codificati in Net-Unicode [NET-UNICODE] (questo differisce da IMAP4rev1). Le implementazioni client possono (possono) tentare di creare nomi di caselle di posta Net-Unicode e devono (devono) interpretare tutti i nomi di caselle di posta a 8 bit restituiti da LIST come [NET-UNICODE]. Le implementazioni server devono (devono) vietare la creazione di nomi di caselle di posta a 8 bit che non sono conformi a Net-Unicode. Tuttavia, i server possono (possono) accettare un nome di casella di posta UTF-8 denormalizzato e convertirlo in Forma di Normalizzazione Unicode C (NFC) (secondo i requisiti Net-Unicode) prima della creazione della casella di posta. I server che scelgono di accettare tali nomi di caselle di posta UTF-8 denormalizzati devono (devono) accettarli in tutti i comandi IMAP che hanno un parametro nome di casella di posta. In particolare, SELECT <name> deve aprire la stessa casella di posta che è stata creata con successo con CREATE <name>, anche se <name> è un nome di casella di posta UTF-8 denormalizzato.

Il nome di casella di posta senza distinzione tra maiuscole e minuscole INBOX è un nome speciale riservato per significare "la casella di posta principale per questo utente su questo server". (Si noti che questo nome speciale potrebbe non esistere su alcuni server per alcuni utenti, ad esempio, se l'utente non ha accesso allo spazio dei nomi personale.) L'interpretazione di tutti gli altri nomi dipende dall'implementazione.

In particolare, questa specifica non prende posizione sulla sensibilità alle maiuscole e minuscole nei nomi di caselle di posta non-INBOX. Alcune implementazioni server sono completamente sensibili alle maiuscole e minuscole nell'intervallo ASCII; altre preservano le maiuscole e minuscole di un nome appena creato ma sono altrimenti insensibili alle maiuscole e minuscole; e altre ancora forzano i nomi a una particolare combinazione di maiuscole e minuscole. Le implementazioni client devono essere in grado di interagire con tutte queste.

Ci sono alcune considerazioni del client durante la creazione di un nuovo nome di casella di posta:

1. Qualsiasi carattere che è uno degli atom-specials (vedere "Sintassi formale" nella Sezione 9) richiederà che il nome della casella di posta sia rappresentato come stringa tra virgolette o letterale.

2. CTL e altri caratteri non grafici sono difficili da rappresentare in un'interfaccia utente e sono meglio evitati. I server possono (possono) rifiutare di creare nomi di caselle di posta contenenti caratteri CTL Unicode.

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

4. Solitamente, 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 eccetto quando usati in quella convenzione. Vedere rispettivamente la Sezione 5.1.2.1 e l'Appendice A.1.

5.1.1 Denominazione gerarchica delle caselle di posta (Mailbox Hierarchy Naming)

Se si desidera esportare nomi di caselle di posta gerarchici, i nomi delle caselle di posta devono (devono) essere gerarchici da sinistra a destra, utilizzando un singolo carattere ASCII 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 Spazi dei nomi (Namespaces)

Spazio dei nomi personale (Personal Namespace): Uno spazio dei nomi che il server considera nell'ambito personale dell'utente autenticato su una particolare connessione. Tipicamente, solo l'utente autenticato ha accesso alle caselle di posta nel proprio spazio dei nomi personale. È la parte dello spazio dei nomi che appartiene all'utente ed è allocata per le caselle di posta. Se esiste un INBOX per un utente, deve (deve) apparire nello spazio dei nomi personale dell'utente. Nel caso tipico, dovrebbe (dovrebbe) esserci solo uno spazio dei nomi personale per utente su un server.

Spazio dei nomi di altri utenti (Other Users' Namespace): Uno spazio dei nomi che consiste di caselle di posta dagli spazi dei nomi personali di altri utenti. Per accedere alle caselle di posta nello spazio dei nomi di altri utenti, l'utente attualmente autenticato deve (deve) ricevere esplicitamente diritti di accesso. Ad esempio, è comune per un manager concedere al proprio personale di supporto amministrativo diritti di accesso alla propria casella di posta. Nel caso tipico, dovrebbe (dovrebbe) esserci solo uno spazio dei nomi di altri utenti per utente su un server.

Spazio dei nomi condiviso (Shared Namespace): Uno spazio dei nomi che consiste di caselle di posta che sono destinate ad essere condivise tra gli utenti e non esistono nello spazio dei nomi personale di un utente.

Gli spazi dei nomi che un server utilizza possono (possono) differire su base per utente.

5.1.2.1 Convenzione storica di denominazione dello spazio dei nomi delle caselle di posta (Historic 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" del resto del nome. Ciò rende possibile 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 accesso ai newsgroup USENET possono (possono) 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).

Gli spazi dei nomi che includono il carattere "#" non sono compatibili con gli URL IMAP [IMAP-URL] e richiedono che il carattere "#" sia rappresentato come %23 quando all'interno degli URL. In quanto tale, gli implementatori del server possono (possono) invece considerare l'uso di prefissi di spazio dei nomi che non contengono il carattere "#".

5.1.2.2 Modelli comuni di spazi dei nomi (Common Namespace Models)

La versione precedente di questo protocollo non ha definito uno spazio dei nomi del server predefinito. Sono evoluti due modelli comuni di spazi dei nomi:

Il modello "Casella di posta personale" (Personal Mailbox), in cui lo spazio dei nomi predefinito presentato consiste solo delle caselle di posta personali dell'utente. Per accedere alle caselle di posta condivise, l'utente deve utilizzare un meccanismo di escape per raggiungere un altro spazio dei nomi.

Il modello "Gerarchia completa" (Complete Hierarchy), in cui lo spazio dei nomi predefinito presentato include le caselle di posta personali dell'utente insieme a qualsiasi altra casella di posta a cui hanno accesso.

5.2 Dimensione della casella di posta e aggiornamenti 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 da questa specifica e/o estensioni. Ad esempio, agenti diversi dal server possono 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 (deve) 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 (dovrebbe) 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 riguardo alla rimozione di messaggi per prevenire errori di sincronizzazione; vedere la descrizione della risposta EXPUNGE (Sezione 7.5.1) 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 per ricordare i dati dal server, un'implementazione client deve (deve) ricordare gli aggiornamenti delle dimensioni della casella di posta. NON deve (NON deve) presumere che qualsiasi comando dopo la selezione iniziale della casella di posta restituirà la dimensione della casella di posta.

5.3 Risposta quando nessun comando è in corso (Response When No Command in Progress)

Le implementazioni server sono autorizzate a inviare una risposta non etichettata (eccetto EXPUNGE) mentre non c'è alcun comando in corso. Le implementazioni server che inviano tali risposte devono (devono) gestire considerazioni di controllo di flusso. In particolare, devono (devono) (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à che si applica alle sessioni dopo l'autenticazione, la durata di quel timer deve (deve) essere di almeno 30 minuti. La ricezione di qualsiasi comando dal client durante quell'intervallo resetta il timer di disconnessione automatica.

Si noti che questa specifica non ha alcuna restrizione su un timer di disconnessione automatica utilizzato prima dell'autenticazione riuscita del client. In particolare, i server sono autorizzati a utilizzare un timer pre-autenticazione abbreviato per proteggersi dagli attacchi Denial-of-Service.

5.5 Comandi multipli in corso (Pipelining dei comandi) (Multiple Commands in Progress / Command Pipelining)

Il client può (può) inviare un altro comando senza attendere la risposta di 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ò (può) iniziare a elaborare un altro comando prima di elaborare il comando corrente fino al completamento, soggetto a regole di ambiguità. Tuttavia, qualsiasi risposta di richiesta di continuazione del comando e continuazioni del comando devono (devono) essere negoziate prima che venga avviato qualsiasi comando successivo.

L'eccezione è se un'ambiguità risulterebbe a causa di un comando che influenzerebbe i risultati di altri comandi. Se il server rileva una possibile ambiguità, deve (deve) 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. Un esempio è un FETCH che causerebbe l'impostazione dei flag \Seen e un comando SEARCH UNSEEN.

Un'ambiguità non ovvia si verifica con i comandi che consentono una risposta EXPUNGE non etichettata (comandi diversi da FETCH, STORE e SEARCH), poiché una risposta EXPUNGE non etichettata 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 un comando diverso da FETCH, STORE o SEARCH, deve (deve) attendere la risposta di risultato di completamento prima di inviare un comando con numeri di sequenza dei messaggi.

Nota: Le risposte EXPUNGE sono consentite mentre UID FETCH, UID STORE e UID SEARCH sono in corso. Se il client invia un comando UID, deve (deve) attendere una risposta di risultato di completamento prima di inviare un comando che utilizza numeri di sequenza dei messaggi (questo può includere UID SEARCH). Qualsiasi numero di sequenza dei messaggi in un argomento di UID SEARCH è associato ai messaggi prima dell'effetto di qualsiasi risposta EXPUNGE non etichettata restituita da UID SEARCH.

Ad esempio, le seguenti sequenze di comandi senza attesa sono non valide:

---