Passa al contenuto principale

6.3 Comandi client - Stato autenticato (Client Commands - Authenticated State)

Nello stato autenticato, sono consentiti comandi che manipolano le caselle di posta come entità atomiche. Di questi comandi, SELECT ed EXAMINE selezioneranno una casella di posta per l'accesso ed entreranno nello stato selezionato.

Oltre ai comandi universali (CAPABILITY, NOOP e LOGOUT), i seguenti comandi sono validi nello stato autenticato: ENABLE, SELECT, EXAMINE, NAMESPACE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS, APPEND e IDLE.

6.3.1 Comando ENABLE​

Argomenti: nomi di capacità

Risposte: nessuna risposta specifica per questo comando

Risultato:

  • OK - Capacità pertinenti abilitate
  • BAD - Nessun argomento o errore di sintassi in un argomento

Diverse estensioni IMAP consentono al server di restituire risposte non richieste specifiche per queste estensioni in determinate circostanze. Tuttavia, i server non possono inviare tali risposte non richieste (con l'eccezione dei codici di risposta (vedere Sezione 7.1) inclusi nelle risposte OK/NO/BAD etichettate o non etichettate, che possono sempre essere inviate) finché non sanno che i client supportano tali estensioni e quindi saranno in grado di analizzare ed elaborare correttamente i dati di risposta dell'estensione.

Il comando ENABLE fornisce un'indicazione esplicita dal client che supporta particolari estensioni. È progettato in modo che il client possa inviare una semplice stringa costante con le estensioni che supporta, e il server abiliterà il sottoinsieme condiviso che entrambi supportano.

Il comando ENABLE accetta un elenco di nomi di capacità e richiede al server di abilitare le estensioni denominate. Una volta abilitate utilizzando ENABLE, ogni estensione rimane attiva fino alla chiusura della connessione IMAP. Per ogni argomento, il server fa quanto segue:

  • Se l'argomento non è un'estensione nota al server, il server deve (deve) ignorare l'argomento.

  • Se l'argomento è un'estensione nota al server e non è specificamente consentito abilitarla utilizzando ENABLE, il server deve (deve) ignorare l'argomento. (Si noti che conoscere un'estensione non implica necessariamente supportare quell'estensione.)

  • Se l'argomento è un'estensione supportata dal server e che deve essere abilitata, il server deve (deve) abilitare l'estensione per la durata della connessione. Si noti che una volta abilitata un'estensione, non c'è modo di disabilitarla.

Se il comando ENABLE ha successo, il server deve (deve) inviare una risposta ENABLED non etichettata (Sezione 7.2.1), che include tutte le estensioni abilitate come specificato sopra. La risposta ENABLED viene inviata anche se nessuna estensione è stata abilitata.

I client dovrebbero (dovrebbero) includere solo le estensioni che devono essere abilitate dal server. Ad esempio, un client può abilitare un comportamento specifico di IMAP4rev2 quando sia IMAP4rev1 che IMAP4rev2 sono pubblicizzati nella risposta CAPABILITY. Le future RFC possono aggiungere a questo elenco.

Il comando ENABLE è valido solo nello stato autenticato, prima che venga selezionata qualsiasi casella di posta. I client non devono (non devono) emettere ENABLE una volta che hanno SELECT/EXAMINE una casella di posta; tuttavia, le implementazioni del server non devono verificare che nessuna casella di posta sia selezionata o sia stata precedentemente selezionata durante la durata di una connessione.

Il comando ENABLE può essere emesso più volte in una sessione. È additivo; cioè, "ENABLE a b", seguito da "ENABLE c", è uguale a un singolo comando "ENABLE a b c". Quando vengono emessi più comandi ENABLE, ogni risposta ENABLED corrispondente dovrebbe (dovrebbe) contenere solo le estensioni abilitate dal comando ENABLE corrispondente, cioè, per l'esempio sopra, la risposta ENABLED a "ENABLE c" non dovrebbe contenere "a" o "b".

Non ci sono limitazioni sul pipelining di ENABLE. Ad esempio, è possibile inviare ENABLE e quindi immediatamente SELECT, o un LOGIN immediatamente seguito da ENABLE.

Il server non deve (non deve) modificare l'elenco CAPABILITY come risultato dell'esecuzione di ENABLE; cioè, un comando CAPABILITY emesso subito dopo un comando ENABLE deve (deve) elencare le stesse capacità di un comando CAPABILITY emesso prima del comando ENABLE. Questo è dimostrato nell'esempio seguente. Si noti che di seguito "X-GOOD-IDEA" è una capacità di estensione fittizia che può essere ENABLED.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t1 OK foo
C: t2 ENABLE CONDSTORE X-GOOD-IDEA
S: * ENABLED X-GOOD-IDEA
S: t2 OK foo
C: t3 CAPABILITY
S: * CAPABILITY IMAP4rev2 ID LITERAL+ X-GOOD-IDEA
S: t3 OK foo again

Nell'esempio seguente, il client abilita l'estensione Conditional Store (CONDSTORE) [RFC7162]:

C: a1 ENABLE CONDSTORE
S: * ENABLED CONDSTORE
S: a1 OK Conditional Store enabled

6.3.1.1 Nota per i progettisti di estensioni che possono utilizzare il comando ENABLE​

I progettisti di estensioni IMAP sono scoraggiati dal creare estensioni che richiedono ENABLE a meno che non ci sia una buona progettazione alternativa. In particolare, le estensioni che causano cambiamenti di comportamento potenzialmente incompatibili alle risposte del server distribuite (e quindi beneficiano di ENABLE) hanno un costo di complessità più elevato rispetto alle estensioni che non lo fanno.

Ultimo aggiornamento il