RFC-XXXX extensions to the IMAP2 protocol (RFC-1176)
Mark Crispin <MRC@cac.washington.edu> Tue, 30 July 1991 23:19 UTC
Received: from dimacs.rutgers.edu by NRI.NRI.Reston.VA.US id aa03830; 30 Jul 91 19:19 EDT
Received: by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25195; Tue, 30 Jul 91 16:32:07 EDT
Received: from akbar.cac.washington.edu by dimacs.rutgers.edu (5.59/SMI4.0/RU1.4/3.08) id AA25188; Tue, 30 Jul 91 16:32:01 EDT
Received: from tomobiki-cho.cac.washington.edu by akbar.cac.washington.edu (5.65/UW-NDC Revision: 2.22 ) id AA24955; Tue, 30 Jul 91 13:31:58 -0700
Date: Tue, 30 Jul 1991 13:28:12 -0700
From: Mark Crispin <MRC@cac.washington.edu>
Sender: Mark Crispin <mrc@tomobiki-cho.cac.washington.edu>
Subject: RFC-XXXX extensions to the IMAP2 protocol (RFC-1176)
To: IETF Mail Extensions WG <ietf-822@dimacs.rutgers.edu>
Message-Id: <MailManager.680905695.7590.mrc@Tomobiki-Cho.CAC.Washington.EDU>
I've written up some specifications for extensions to the IMAP2 protocol (described in RFC-1176) to cover RFC-XXXX. There isn't a completely perfect fit, but I believe that I have more or less the function of RFC-XXXX covered. If anyone here is interested in IMAP I would appreciate comments or at least a sanity check on this specification. *DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group M. Crispin Request for Comments: ???? Washington Extends: RFC 1176 July 1991 INTERNET MESSAGE BODY EXTENSIONS TO IMAP2 Status of this Memo This RFC defines an optional extension to the IMAP2 procotol for multi-part textual and non-textual Internet messages as per the Internet DRAFT "Mechanisms for Specifying and Describing the Format of Internet Message Bodies" by Borenstein and Freed. It extends but does not obsolete RFC 1176. This RFC also clarifies the question of authentication in IMAP2. This RFC specifies an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. This specification does not purport to apply to the IMAP3 protocol described in RFC-1203. Conventions Please refer to RFC-1176 for all conventions used in this document. Authentication RFC-1176 requires authentication, although it only specifies a LOGIN command, which has the undesirable attribute of sending passwords over the network in plaintext. As noted on page 6 of RFC-1176, a LOGIN command is required "unless...[authentication] has already been accomplished through other means, e.g. Kerberos." RFC-1176 does not specify how this should be done. It is the intent of the IMAP2 specification not to specify how any particular authentication mechanism is to work. That rightfully belongs in the specification of the authentication mechanism. It is envisioned, but not required, that an externally-authenticated IMAP2 server not be started until authentication has been completed, and that the IMAP2 server recognize that authentication has already happened and immediately enter the post-login state. In the case of Kerberos, it is intended that IMAP2 should be Kerberized exactly as FTP has been. Command extensions tag FETCH sequence data The FETCH command is extended as follows: ALL.BODY Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) BODY The body of the message. The body is computed computed by the server by parsing the RFC 822 header and body into the component parts, defaulting various fields as necessary. BODY[section] The text of a particular body section. The section specification is a set of one or more part numbers delimited by periods. Single-part messages only have a part 1. Multi-part messages as assigned consecutive part numbers, as they occur in the message. If a particular part is itself multi-part, its parts must be indicated by a period followed by that part number within that nested multi-part part. It is not permitted to fetch the text of a nested multi-part part. A part of type MESSAGE also has nested parts, which are the parts of the MESSAGE part's body. Every message has at least one part. EXAMPLE: Here is a very complex message with its associated section specifications. 1 TEXT 2 BINARY 3 MESSAGE 3.1 TEXT 3.2 BINARY MULTIPART 4.1 IMAGE 4.2 MESSAGE 4.2.1 TEXT Note that there is no section specification for the Multi-part part itself. Response Extensions * number message_data FETCH data Data fetching is extended to add the following properties: BODY An S-expression format list that describes the body of a message. The body is computed by the server by parsing the RFC 822 header and body into the component parts, defaulting various fields as necessary. Multiple parts are indicated by S-expression nesting. The basic fields of the body are in the following order: body type, body subtype, body parameter list, body id, body description. Body type is an atom; the others are strings. Body types that convey data (presently, all those other than type APPLICATION) contain, immediately following the basic fields, the body encoding (an atom), and the size of the body contents in bytes. A body type of type MESSAGE contains, immediately after the data fields, the envelope of the encapsulated message and its body structure. A body type of type TEXT or TEXT-PLUS contains, immediately after the data fields, the size of the body contents in text lines. BODY[section] A string expressing the body contents of the specified section. Formal Syntax The syntax of RFC-1176 is extended with the following rules. Where a rule is already defined in RFC-1176, this rule replaces it. The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in RFC 822 with one exception; the delimiter used with the "#" construct is a single space (SP) and not a comma. body ::= "(" (body_basic / body_basic SP body_extended) ")" body_basic ::= body_type SP body_subtype SP body_parameter SP body_id SP body_description body_data ::= body_encoding SP body_size_byte body_data_msg ::= body_data SP envelope SP body body_data_text ::= body_data SP body_size_line body_encoding ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/ "QUOTEDPRINTABLE" / "X-UNKNOWN" body_extended ::= body_data / body_data_text / body_data_msg body_description::= nil / string body_id ::= nil / string body_parameter ::= nil / string body_section ::= NUMBER / NUMBER "." body_section body_size_byte ::= NUMBER body_size_line ::= NUMBER body_subtype ::= nil / string body_type ::= "TEXT" / "MULTIPART" / "TEXT-PLUS" / "MESSAGE" / "BINARY" / "APPLICATION" / "AUDIO" / "IMAGE" / "VIDEO" / "X-UNKNOWN" fetch ::= "FETCH" SP sequence SP ("ALL" / "ALL.BODY" / "FAST" / fetch_att / "(" 1#fetch_att ")") fetch_att ::= "BODY" / "BODY[" body_section "]" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" / "RFC822" / "RFC822.HEADER" / "RFC822.SIZE" / "RFC822.TEXT" msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("BODY" SP body / "BODY[" body_section "]" string / "ENVELOPE" SP envelope / "FLAGS" SP "(" 1#(recent_flag flag_list) ")" / "INTERNALDATE" SP date / "RFC822" SP string / "RFC822.HEADER" SP string / "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP string) ")" Implementation Status The University of Washington IMAP2 distribution fully supports this specification as of the August 1991 release. Refer to RFC-1176 for more information about this and other IMAP2 implementations. A Kerberized IMAP2 is in test at a few organizations, but is not yet available for public release. Design Discussion IMAP2 as specified in RFC-1176 is a 7-bit protocol. These extensions make it possible to support 8-bit textual and binary mail through the IMAP mode and offers the possibility of retiring the RFC822* fetch attributes in the future. Some thought was made on whether or not the body contents fetch should return the decoded version of BASE64 and QUOTED-PRINTABLE sections, or if there should be an option to get either the encoded or the decoded form. I eventually decided against it on these grounds: 1) It makes the extensions unimplementable in any environment where an 8-bit data stream is not possible. 2) It creates multiple ways of doing the same thing and hence exponentially multiplies the possiblity of non-interoperable implementations. 3) It introduces binary in the same data stream as commands, and hence makes the protocol more vulnerable to synchronization problems. If server-based decoding of BASE64 and QUOTED-PRINTABLE turns out to be important, I feel it should be transmitted out of band from the IMAP command stream. This would have the necessary but unfortunate effect of making the protcol more complicated. Acknowledgements My thanks to everyone in the IETF-822 group for their hard work in getting the Internet Message Bodies draft out the door, and especially to Nathaniel Borenstein and Ned Freed for putting together something we could all live with. Any mistakes, flaws, or sins of omission in this IMAP2 protocol extension are, however, strictly my own; and no endorsement on the part of anyone is implied. Security Considerations Security issues are not discussed in this memo. Author's Address Mark R. Crispin Panda Programming 6158 Lariat Loop NE Bainbridge Island, WA 98110-2098 Phone: (206) 842-2385 EMail: MRC@CAC.Washington.EDU
- RFC-XXXX extensions to the IMAP2 protocol (RFC-11… Mark Crispin