8. Esempio di connessione IMAP4rev1 (Sample IMAP4rev1 Connection)
Un body di tipo TEXT contiene immediatamente dopo i campi di base (basic fields) la dimensione del body in righe di testo. Si noti che questa dimensione è la dimensione nella sua codifica di trasferimento (content-transfer-encoding) e non la dimensione risultante dopo un'eventuale decodifica.
I dati di estensione (extension data) seguono i campi di base e i
campi specifici del tipo sopra elencati. I dati di estensione non
vengono mai restituiti in un fetch BODY, ma possono essere
restituiti in un fetch BODYSTRUCTURE. I dati di estensione, se
presenti, DEVONO essere nell'ordine definito.
I dati di estensione di una parte di body non multiparte (non-
multipart body part) sono nel seguente ordine:
body MD5
Una stringa che specifica il valore MD5 del body come da [MD5].
RFC 3501 IMAPv4 March 2003
body disposition
Un elenco tra parentesi con lo stesso contenuto e funzione della
disposition del body per una parte di body multiparte (multipart
body part).
body language
Una stringa o un elenco tra parentesi che specifica il valore
della lingua del body come da [LANGUAGE-TAGS].
body location
Un elenco di stringhe che specifica l'URI del contenuto del body
come da [LOCATION].
Tutti i seguenti dati di estensione non sono definiti in questa
versione del protocollo e sarebbero della forma descritta sopra
per i dati di estensione per body multiparti.
ENVELOPE
Un elenco tra parentesi che descrive la struttura della busta
(envelope structure) di un messaggio. Viene calcolata dal server
scomponendo l'intestazione [RFC-2822] nelle parti componenti,
preimpostando vari campi ove necessario.
I campi della struttura della busta sono nel seguente ordine:
date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to e
message-id. I campi date, subject, in-reply-to e message-id sono
stringhe. I campi from, sender, reply-to, to, cc e bcc sono elenchi
tra parentesi di strutture di indirizzo.
Una struttura di indirizzo è un elenco tra parentesi che descrive
un indirizzo di posta elettronica. I campi di una struttura di
indirizzo sono nel seguente ordine: nome personale, [SMTP] at-
domain-list (route di origine/source route), nome della mailbox e
nome host.
La sintassi di gruppo di [RFC-2822] è indicata da una forma
speciale della struttura di indirizzo in cui il campo nome host è
NIL. Se anche il campo nome della mailbox è NIL, si tratta di un
marcatore di fine gruppo (punto e virgola nella sintassi RFC-822).
Se il campo nome della mailbox non è NIL, si tratta di un marcatore
di inizio gruppo e il campo nome della mailbox contiene la frase
del nome di gruppo.
Se le righe di intestazione Date, Subject, In-Reply-To e Message-ID
mancano nell'intestazione [RFC-2822], il membro corrispondente della
busta è NIL; se tali righe di intestazione sono presenti ma vuote,
il membro corrispondente della busta è la stringa vuota.
RFC 3501 IMAPv4 March 2003
Nota: alcuni server restituiscono un membro di busta NIL nel
caso "presente ma vuoto". I client DOVREBBERO trattare NIL e la
stringa vuota come identici.
Nota: [RFC-2822] richiede che tutti i messaggi abbiano una
valida intestazione Date. Pertanto il membro date della busta
non può essere NIL o la stringa vuota.
Nota: [RFC-2822] richiede che le intestazioni In-Reply-To e
Message-ID, se presenti, abbiano contenuto non vuoto. Pertanto i
membri in-reply-to e message-id della busta non possono essere la
stringa vuota.
Se le righe di intestazione From, To, cc e bcc mancano
nell'intestazione [RFC-2822] o sono presenti ma vuote, il membro
corrispondente della busta è NIL.
Se le righe Sender o Reply-To mancano nell'intestazione [RFC-2822]
o sono presenti ma vuote, il server imposta il membro corrispondente
della busta allo stesso valore del membro from (non ci si aspetta
che il client lo faccia).
Nota: [RFC-2822] richiede che tutti i messaggi abbiano una
valida intestazione From. Pertanto i membri from, sender e
reply-to della busta non possono essere NIL.
FLAGS
Un elenco tra parentesi di flag impostati per questo messaggio.
INTERNALDATE
Una stringa che rappresenta la data interna (internal date) del
messaggio.
RFC822
Equivalente a BODY[].
RFC822.HEADER
Equivalente a BODY[HEADER]. Si noti che questo non ha comportato
l'impostazione di \Seen, poiché i dati di risposta RFC822.HEADER
si verificano come risultato di un FETCH di RFC822.HEADER. I dati di
risposta BODY[HEADER] si verificano come risultato di un FETCH di
BODY[HEADER] (che imposta \Seen) o BODY.PEEK[HEADER] (che non imposta
\Seen).
RFC822.SIZE
Un numero che esprime la dimensione [RFC-2822] del messaggio.
RFC 3501 IMAPv4 March 2003
RFC822.TEXT
Equivalente a BODY[TEXT].
UID
Un numero che esprime l'identificatore univoco (unique identifier)
del messaggio.
Esempio: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
7.5. Risposte del server - Richiesta di continuazione del comando (Server Responses - Command Continuation Request)
La richiesta di continuazione del comando (command continuation request) è indicata da un token "+" invece di un tag. Questa forma di risposta indica che il server è pronto ad accettare il prosieguo di un comando dal client. Il resto di questa risposta è una riga di testo.
Questa risposta è usata nel comando AUTHENTICATE per trasmettere dati del server al client e richiedere ulteriori dati del client. È usata anche quando un argomento di un qualsiasi comando è un letterale (literal).
Non è consentito al client inviare gli ottetti del letterale se il server non indica che essi sono attesi. Ciò consente al server di elaborare i comandi riga per riga e rifiutare gli errori riga per riga. Il resto del comando, incluso il CRLF che termina un comando, segue gli ottetti del letterale. Se vi sono ulteriori argomenti di comando, dopo gli ottetti del letterale seguono uno spazio e tali argomenti.
Esempio: C: A001 LOGIN \{11\} S: + Ready for additional command text C: FRED FOOBAR \{7\} S: + Ready for additional command text C: fat man S: A001 OK LOGIN completed C: A044 BLURDYBLOOP \{102856\} S: A044 BAD No such command as "BLURDYBLOOP"