RFC IMAP
Sommaire How to Read This Document Protocol Overview State and Flow Diagram Data Formats Operational Considerations Client Commands Server Responses Sample IMAP4 connection Formal Syntax Author's Note Security Considerations Author's Address References

RFC du protocole IMAP : References

[ACAP] Myers, J. "ACAP -- Application Configuration Access Protocol",
Work in Progress.

[CHARSET] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
[DISPOSITION] Troost, R., and Dorner, S., "Communicating Presentation
Information in Internet Messages: The Content-Disposition Header",
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731.
Carnegie-Mellon University, December 1994.

[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with IMAP2bis", RFC
2061, University of Washington, November 1996.

[IMAP-DISC] Austein, R., "Synchronization Operations for Disconnected
IMAP4 Clients", Work in Progress.

[IMAP-HISTORICAL] Crispin, M. "IMAP4 Compatibility with IMAP2 and
IMAP2bis", RFC 1732, University of Washington, December 1994.

[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail Models in
IMAP4", RFC 1733, University of Washington, December 1994.

[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol -
Obsolete Syntax", RFC 2062, University of Washington, November 1996.

[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2",
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.

[MD5] Myers, J., and M. Rose, "The Content-MD5 Header Field", RFC
1864, October 1995.

[MIME-IMB] Freed, N., and N. Borenstein, "MIME (Multipurpose Internet
Mail Extensions) Part One: Format of Internet Message Bodies", RFC
2045, November 1996.

[MIME-IMT] Freed, N., and N. Borenstein, "MIME (Multipurpose
Internet Mail Extensions) Part Two: Media Types", RFC 2046,
November 1996.

[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", RFC
2047, November 1996.

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, University of Delaware, August 1982.

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10,
[UTF-7] Goldsmith, D., and Davis, M., "UTF-7: A Mail-Safe
Transformation Format of Unicode", RFC 1642, July 1994.

B. Changes from RFC 1730

1) The STATUS command has been added.

2) Clarify in the formal syntax that the "#" construct can never
refer to multiple spaces.

3) Obsolete syntax has been moved to a separate document.

4) The PARTIAL command has been obsoleted.

5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and
RFC822.TEXT.PEEK fetch attributes have been obsoleted.

6) The "<" origin "." size ">" suffix for BODY text attributes has
been added.

7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part
specifiers have been added.

8) Support for Content-Disposition and Content-Language has been
added.

9) The restriction on fetching nested MULTIPART parts has been
removed.

10) Body part number 0 has been obsoleted.

11) Server-supported authenticators are now identified by
capabilities.

12) The capability that identifies this protocol is now called
"IMAP4rev1".  A server that provides backwards support for RFC 1730
SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its
CAPABILITY response.  Because RFC-1730 required "IMAP4" to appear as
the first capability, it MUST listed first in the response.

13) A description of the mailbox name namespace convention has been
added.

14) A description of the international mailbox name convention has
been added.

15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT
and UIDVALIDITY.  This is a change from the IMAP STATUS
Work in Progress and not from RFC-1730

16) Add a clarification that a null mailbox name argument to the LIST
command returns an untagged LIST response with the hierarchy
delimiter and root of the reference argument.

17) Define terms such as "MUST", "SHOULD", and "MUST NOT".

18) Add a section which defines message attributes and more
thoroughly details the semantics of message sequence numbers, UIDs,
and flags.

19) Add a clarification detailing the circumstances when a client may
send multiple commands without waiting for a response, and the
circumstances in which ambiguities may result.

20) Add a recommendation on server behavior for DELETE and RENAME
when inferior hierarchical names of the given name exist.

21) Add a clarification that a mailbox name may not be unilaterally
unsubscribed by the server, even if that mailbox name no longer
exists.

22) Add a clarification that LIST should return its results quickly
without undue delay.

23) Add a clarification that the date_time argument to APPEND sets
the internal date of the message.

24) Add a clarification on APPEND behavior when the target mailbox is
the currently selected mailbox.

25) Add a clarification that external changes to flags should be
always announced via an untagged FETCH even if the current command is
a STORE with the ".SILENT" suffix.

26) Add a clarification that COPY appends to the target mailbox.

27) Add the NEWNAME response code.

28) Rewrite the description of the untagged BYE response to clarify
its semantics.

29) Change the reference for the body MD5 to refer to the proper RFC.

30) Clarify that the formal syntax contains rules which may overlap,
and that in the event of such an overlap the rule which occurs first
takes precedence.

31) Correct the definition of body_fld_param.

32) More formal syntax for capability_data.

33) Clarify that any case variant of "INBOX" must be interpreted as
INBOX.

34) Clarify that the human-readable text in resp_text should not
begin with "[" or "=".

35) Change MIME references to Draft Standard documents.

36) Clarify \Recent semantics.

37) Additional examples.
Annonces