InfoMagic Internet Tools 1993 July

home *** CD-ROM | disk | FTP | other *** search

/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap-3.0 / IMAP2bis.TXT next >

Wrap

Text File | 1992-12-12 | 37.3 KB | 899 lines

*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT* Network Working Group M. Crispin Request for Comments: ???? Washington Extends: RFC 1176 December 1992 IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL Status of this Memo This RFC defines optional extensions to the IMAP2 procotol for multi-part textual and non-textual Internet messages as per the Internet DRAFT "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies" by Borenstein and Freed. This document also defines several additional optional functional enhancements to IMAP2. [ ** Delete this note upon publication as an RFC ** The extensions discussed in this document are experimental and subject to change. It documents the state of these extensions as of December 1992. It is distributed for informational purposes only. In particular, additions may be made to IMAP2bis in subsequent versions of this draft of the IMAP2bis document. Persons planning on implementing these extensions are STRONGLY URGED to get in touch with the author before embarking on such a project.] The name of the resulting protocol is IMAP2bis. IMAP2bis extends but does not obsolete the base protocol described in RFC-1176. A few changes are made to the base protocol described in RFC-1176. It is believed that no existing implementations are affected by these changes; however, implementors may wish to verify that their IMAP2 implementations are IMAP2bis compatible. Although the IMAP2bis functional extensions are separable from each other based upon function, an RFC-1176 implementation is NOT IMAP2bis compliant (as opposed to IMAP2bis compatible) unless it implements ALL of the functional extensions and changes described here. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standard" 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. I.a. MIME Command Extensions tag FETCH sequence data The FETCH command is extended as follows: FULL Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) BODY The body of the 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. 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. I.b. MIME 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. In this case, instead of a body type as the first element of the list there is a nested body. The last element of the list is the multipart subtype (mixed, digest, parallel, alternative, etc.). The basic fields of a non-multipart body are in the following order: body type - an atom giving the content type name as defined in MIME body subtype - a string giving the content subtype name as defined in MIME body parameter list - an s-expression list of attribute/value pairs [e.g. (foo bar baz rag) where `bar' is the value of `foo' and `rag' is the value of `baz'] as defined in MIME. body id - a string giving the content id as defined in MIME. body description - a string giving the content description as defined in MIME. body encoding - a string giving the content transfer encoding as defined in MIME. body size - a number giving the size of that body in bytes. Note that this size is the size in its transfer encoding and not the resulting size. A body type of type MESSAGE and subtype RFC822 contains, immediately after the basic fields, the envelope of the encapsulated message, its body structure, and its size in text lines. A body type of type TEXT contains, immediately after the basic fields, the size of the body in text lines. BODY[section] A string expressing the body contents of the specified section. This string is transmitted as 7-bit US-ASCII, encoded as according to MIME content transfer encoding. The string is interpreted according to the content transfer encoding and the body type and subtype. Note that 7-bit US-ASCII is the transport format and NOT necessarily the byte size or character set of the result. The resulting data may be 8-bit of some other character set or even binary! II.a. Mailbox Management Command Extensions The following extensions are in the area of mailbox management. They are intended to provide basic mailbox management services in a simple (single server) configuration. Mailbox management in more complex environments is dealt with by a separate distributed management protocol. tag FIND MAILBOXES pattern The FIND MAILBOXES command as described in RFC-1176 is hereby more thoroughly defined. This command returns the mailboxes that the user has declared as being "active" or "subscribed." The restriction that FIND MAILBOXES does not return the name INBOX is removed. The name INBOX is returned by FIND MAILBOXES if that name has been subscribed (see SUBSCRIBE MAILBOX below). The functionality is otherwise unchanged. The exact meaning of this is implementation-dependent, since the concept of a set of `active' or `subscribed' mailboxes that is preserved across sessions may not be meaningful for a particular server or server implementation. If the SUBSCRIBE MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then this command returns the list manipulated by those commands. tag FIND ALL.MAILBOXES pattern The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES; however, it should return a complete list of all mailboxes available to the user. Data is returned as in FIND MAILBOXES. The special name INBOX is included in the output from FIND ALL.MAILBOXES unless INBOX is not supported by this server or for this user. The criteria for omitting INBOX is whether or not SELECT INBOX will return failure; it is not relevant whether or not the user's actual INBOX resides on this or some other server (see FIND MAILBOXES and SUBSCRIBE MAILBOX for a mechanism for the user to identify that this is the real INBOX). If FIND ALL.MAILBOXES is implemented FIND MAILBOXES must also be implemented, even if it returns the same information. Also, FIND ALL.MAILBOXES must, at least, return all the mailbox names that are returned by FIND MAILBOXES. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `mailboxes available to the user' may not be meaningful for a particular server or server implementation. tag FIND BBOARDS pattern The FIND BBOARDS command as described in RFC-1176 is hereby more thoroughly defined. This command returns the bboards that the user has declared as being "active" or "subscribed." The functionality is otherwise unchanged. The exact meaning of this is implementation-dependent, since the concept of a set of `active' or `subscribed' bboards that is preserved across sessions may not be meaningful for a particular server or server implementation. If the SUBSCRIBE BBOARD and UNSUBSCRIBE BBOARD commands are implemented then this command returns the list manipulated by those commands. tag FIND ALL.BBOARDS pattern The FIND ALL.BBOARDS command is similar to FIND BBOARDS; however, it should return a complete list of all bulletin boards available to the user. Data is returned as in FIND BBOARDS. If FIND ALL.BBOARDS is implemented FIND BBOARDS must also be implemented, even if it returns the same information. Also, FIND ALL.BBOARDS must, at least, return all the bboard names that are returned by FIND BBOARDS. The exact meaning of this is implementation-dependent, since the concept of a bounded or deterministic set of `bboards available to the user' may not be meaningful for a particular server or server implementation. tag CREATE mailbox The CREATE command creates a mailbox with the given name. This command returns an OK response only if a new mailbox with that name has been created. It is an error to attempt to create a mailbox with a name that refers to an extant mailbox. Any error in creation will return a NO response. Creating INBOX is not permitted. If there is a primary or default mailbox for this user, it MUST exist and be called INBOX; hence it may not be created. Otherwise, the name INBOX can not be used; see section VI, "INBOX Requirement Loosened", for more details. tag DELETE mailbox The DELETE command deletes a mailbox with the given name. This command returns an OK response only if a mailbox with that name has been deleted. It is an error to attempt to delete a mailbox name that does not exist. Any error in deletion will return a NO response. A server SHOULD NOT attempt to test that a mailbox is empty prior to permitting deletion; this would prevent the deletion of a mailbox which for some reason can not be opened or expunged, leaving to possible denial of service problems. Any such checking should be left to the discretion of the client. Deleting INBOX is not permitted. tag RENAME oldmailbox newmailbox The RENAME command changes the name of a mailbox. This command returns an OK response only if a mailbox with the old name exists and has been successfully renamed to the new name. It is an error to attempt to rename with an old mailbox name that does not exist or a new mailbox name which already exists. Any error in renaming will return a NO response. Renaming INBOX is permitted. A new, empty INBOX is created in its place. tag SUBSCRIBE MAILBOX mailbox The SUBSCRIBE MAILBOX command adds the specified mailbox name to the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the subscription is successful. If SUBSCRIBE MAILBOX is implemented then FIND MAILBOXES must also be implemented, and FIND ALL.MAILBOXES should be implemented. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE MAILBOX mailbox The UNSUBSCRIBE MAILBOX command removes the specified mailbox name from the list of "active" or "subscribed" mailboxes as returned by the FIND MAILBOXES command. This command returns an OK response only if the unsubscription is successful. If UNSUBSCRIBE MAILBOX is implemented then SUBSCRIBE MAILBOXES and FIND MAILBOXES must also be implemented, and FIND ALL.MAILBOXES should be implemented. Unsubscriptions should be preserved between sessions. tag SUBSCRIBE BBOARD bboard The SUBSCRIBE BBOARD command adds the specified mailbox name to the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the subscription is successful. If SUBSCRIBE BBOARD is implemented then FIND BBOARDS must also be implemented, and FIND ALL.BBOARDS should be implemented. Subscriptions should be preserved between sessions. tag UNSUBSCRIBE BBOARD bboard The UNSUBSCRIBE BBOARD command removes the specified mailbox name from the list of "active" or "subscribed" bulletin boards as returned by the FIND BBOARDS command. This command returns an OK response only if the unsubscription is successful. If UNSUBSCRIBE BBOARD is implemented then SUBSCRIBE BBOARDS and FIND BBOARDS must also be implemented, and FIND ALL.BBOARDS should be implemented. Unsubscriptions should be preserved between sessions. II.b. Mailbox Management Response Extensions No response extensions are made in the area of mailbox management. III.a. Cache Management Command Extensions RFC-1176 specifies that a server is not obligated to transmit data in response to a FETCH command that it has already transmitted earlier in the session. This can place an unreasonable burden on clients which lack the resources to maintain a local copy of the state transmitted by the server during this session. To address this problem, the PURGE command has been defined. The previous exemption of texts made to this rule is hereby revoked and replaced with this new mechanism. Servers which refrain from sending data previously sent MUST implement the PURGE command. Clients which do not cache all data sent from the server MUST implement the PURGE command. It can be assumed that any server which returns BAD to any PURGE command does not exploit any caching at the client. As of this writing, the only exploitation of client caching by known server implementation is that some servers do not send EXISTS or RECENT updates in response to a CHECK command under certain circumstances. The requirement that a client cache this information is unaffected by the new PURGE functionality. PURGE STATUS sequence The PURGE STATUS command informs the server that the client has deleted all information about the status (flags, internal date, and RFC-822 size) of the specified messages from its cache. PURGE STRUCTURE sequence The PURGE STRUCTURE command informs the server that the client has deleted all information about the structure (envelope and body) of the specified messages from its cache. PURGE TEXTS sequence The PURGE TEXTS command informs the server that the client has deleted all information about the texts (header, text, or body parts) of the specified messages from its cache. PURGE ALWAYS The PURGE ALWAYS command informs the server that the client has no capability to cache any data. The server must re-send data whenever requested by the client. Note: PURGE ALWAYS does not affect information returned by the EXISTS and RECENT unsolicited responses. Such information MUST be remembered by even a non-caching client, since there is NO guarantee that ANY command will return EXISTS or RECENT information on demand. PURGE token sequence Any unknown subcommand of PURGE should be rejected with a NO response instead of a BAD response. III.b. Cache Management Response Extensions No response extensions are made in the area of cache management. IV.a. Mailbox Append Command Extensions tag APPEND mailbox string The APPEND command appends the string, which is in the format of an RFC-822 message, to the specified mailbox. If the append is unsuccessful for any reason the mailbox must be restored to its state prior to the append; no partial appending is permitted. Note that this functionality is unsuitable for message delivery, because it does not provide a mechanism to transfer RFC 821 (SMTP). envelope information. Its primary purpose is to provide for a `saved outgoing mail' mailbox which resides on the remote server. IV.b. Mailbox Append Response Extensions If the specified mailbox is open by a SELECT or BBOARD command, the normal new mail action should be taken. V.a. Partial Text Fetching Command Extensions tag PARTIAL msgno RFC822 start_byte byte_count tag PARTIAL msgno RFC822.HEADER start_byte byte_count tag PARTIAL msgno RFC822.TEXT start_byte byte_count tag PARTIAL msgno BODY[section] start_byte byte_count The PARTIAL command is equivalent to the associated FETCH command, with the added functionality that only the specified number of bytes, beginning at the specified starting byte, are returned. Note as well that only a single message can be fetched at a time. The first byte of a message, and hence the minimum for the starting byte, is byte 1. Any partial fetch which attempts to read beyond the end of the text is truncated as appropriate. If the starting byte is beyond the end of the text, an empty string is returned. The data is returned with the FETCH response. There is no indication of the range of the partial data in this response; thus it is not possible to assume caching with PARTIAL data. Any knowledge of caching from a FETCH command of that data is invalidated as with a PURGE command. It is also not possible to stream multiple PARTIAL commands of the same data item without processing and synchronizing at each step, since each PARTIAL fetch of data replaces any prior (PARTIAL) FETCH of that data. Note that when partial fetching it is possible to break in the middle of a a line or a criticial sequence such as a BASE64 quadruple or QUOTED-PRINTABLE shift. Implementations using partial fetching should keep this in mind. There is no requirement that partial fetches follow any sequence; so if it turns out that a partial fetch of bytes 1 through 10000 breaks in an awkward place, it is permitted to continue with a partial fetch of 9987 through 19987, etc. V.b. Partial Text Fetching Response Extensions No response extensions are made in the area of partial text fetching. VI. INBOX Requirement Loosened RFC-1176 required all server implementations to make available a mailbox named "INBOX" on the server to be that user's primary mailbox on that server. Examples have come up of shared mailbox or bulletin board only servers on which this requirement is unreasonable. The requirement is hereby modified as follows: SELECT's argument is implementation-dependent; however the word "INBOX" is reserved to mean a primary or default mailbox for this user, independent of any other server semantics. It is permitted for a server not to have an INBOX if there is no concept of a primary or default mailbox for this user. The name "INBOX" MUST NOT be used for any other purpose. VII. Authentication Clarification RFC-1176 specifies that "until identity and access authorization have been established, no operations other than LOGIN or LOGOUT are permitted." RFC-1176 specifies that authentication may be established through the LOGIN command, or may have "already been accomplished through other means, e.g. Kerberos." RFC-1176 does not specify these "other means" or how they are done. Pre-authentication is only possible when the connection to the IMAP2 service is made through some protocol other than a TCP connection to port 143 and this protocol provides its own authentication mechanism. Although RFC-1176 gives Kerberos as an example of an alternate means of authentication, it is not a good example of pre-authentication as Kerberos does not provide a connection service. A better example of such a protocol is the BSD "RSH" protocol which provides authentication through a "trusted host" facility. Another example would be of a manual invocation of an IMAP server from a logged-in timesharing job. A pre-authenticated IMAP server should recognize that authentication has already happened, and enter the post-login state. In its greeting message, it should use the heretofore undocumented unsolicited reply "PREAUTH" instead of "OK" to indicate that external authentication has taken place. For example, here is a pre-authentication scenario: S: * PREAUTH IMAP Server pre-authenticated as user `Smith' U: A001 SELECT INBOX S: * FLAGS (\Answered \Flagged \Deleted \Seen) S: * 19 EXISTS S: * 2 RECENT S: A001 OK SELECT complete While a connection that is not pre-authenticated is currently constrained to using the LOGIN command for establishing authentication, that does not mean that authentication systems such as Kerberos cannot be used. While the examples show the "password" argument to the LOGIN as being a short string typed in by the user, this need not be the case. If a server supports authentication via Kerberos version 4, it may accept the string "@KERBEROS:" followed by the hexadecimal representation of a Kerberos authenticator. For example, the following is a Kerberos login scenario (note that the line breaks in the sample authenticator are for editorial clarity and are not in a real authenticator): S: * OK Kerberos IMAP2 Server U: a001 LOGIN smith @KERBEROS:040700414e445245572e434d552e4544550 038202c868f3890b377fc8266acc1bedb96b80d3fa76489898e74cd1c952dc 4003ea3428f29f1c470016cf5adc22f939e6deff2747254c1815d5b0b90d4c 5a2cba21eb0abe32f9acbf568d751bf4cc13f5ba4e6d82c638a8b5421 S: a001 OK [df84a4cb8323454f] Login OK via Kerberos The token in the brackets in the OK response is the Kerberos authentication response, encrypted with the session key in network byte order and an incremented checksum as in the usual Kerberos procedure. VIII. Change to the Syntax of Dates With the impending end of the century and the necessity of having a more general syntax for timezones than presently exists, the format of IMAP2 internal dates has become inadequate. The BNF for the date syntax is hereby amended to be: date ::= date_new / date_old date_new ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz" date_old ::= string in form "dd-mmm-yy hh:mm:ss-zzz" In date_new, the year is now a 4-digit year, and the timezone is a signed four-digit value of hhmm representing hours and minutes west of Greenwich (that is, the amount that the given time differs from Universal Time). Subtracting the timezone from the given time will give the UT form. Universal Time is expressed as "+0000". date_old is hereby declared obsolete, and its usage in new software is STRONGLY discouraged. However, client implementations MUST recognize and properly parse it. RFC-1176 documents the argument to the SEARCH criteria BEFORE, ON, and SINCE as being either "date" in the text and "string" in the BNF. These SEARCH criteria arguments are hereby amended to be "day", with the following syntax: day ::= day_new / day_old day_new ::= string in form "dd-mmm-yyyy" day_old ::= string in form "dd-mmm-yy" day_old is hereby declared obsolete, and its usage in new software is STRONGLY discouraged. However, server implementations MUST recognize and properly parse it. IX. COPY Command and the Unsolicited COPY Response RFC-1176 specifies that if the destination mailbox specified by a COPY command does not exist, the server should create it. With the advent of the CREATE command, it is intended that this functionality will eventually be deprecated. Server implementations SHOULD continue to create new mailboxes as needed with a COPY command, but SHOULD also note to the user at the client, via an unsolicited OK response, that a new mailbox was created. An unsolicited COPY response is mentioned in RFC-1176's documentation of the COPY command, and in the BNF, but is not otherwise documented. This response was intended to provide status of a COPY command, and indicate how much of the COPY was done in the event of a COPY which failed midway. This response was not implemented by many servers. The definition of the COPY command is hereby amended to REQUIRE that a COPY fully complete the requested operation. If this is not possible, then COPY should do NONE of the requested operation, and back out of any partial COPY as necessary. This eliminates the ambiguity. The unsolicited COPY response is hereby declared obsolete. It MUST NOT be used in new server implementations. Clients should ignore any unsolicited COPY responses seen. X. Reiteration on the Unsolicited STORE Response Some server implementations return an unsolicted STORE response as a result of a change caused by a STORE. This was referenced in passing in RFC-1064, but had already become obsolete. The correct behavior is to return an unsolicited FETCH response for both a FETCH and a STORE. As stated in RFC-1176, the unsolicited STORE response is obsolete. It MUST NOT be used in new server implementations. Clients SHOULD treat any unsolicited STORE responses as equivalent to unsolicited FETCH. XI. Anonymous Convention Established Some servers may wish to allow non-authenticated access to certain mailboxes or bulletin boards. The means by which this is accomplished is with a LOGIN command using a userid of "anonymous". A password is still required; it is implementation-dependent what requirements, if any, are placed upon the password. It is also implementation-dependent what access restrictions are placed on anonymous users. Since this is a convention, and not strictly a protocol extension or change, implementations are NOT required to support the anonymous convention in order to be considered IMAP2bis compliant. XII. Clarification of RFC822.HEADER RFC-1176 states that the concatenation of the strings returned by fetching RFC822.HEADER and RFC822.TEXT is equivalent to the string returned by fetching RFC822. It was implicit that the delimiting blank line would be included in RFC822.HEADER, because otherwise there would be a leading blank line in RFC822.TEXT, but never explicitly stated. The string returned by RFC822.HEADER includes the empty line that delimits the header from the text in RFC-822. In other words, all non-null RFC822.HEADER strings end with a sequence of four ASCII bytes: CR LF CR LF (0C 0A 0C 0A). XIII. SEARCH string extension The BODY and TEXT qualifiers in the SEARCH are hereby extended to permit an RFC-1342 format multinational character string. Due to compatibility constraints, RFC-1432 format strings must be quoted. For example: SEARCH TEXT "=?US-ASCII?Q?leaping lizards?=" and SEARCH TEXT "leaping lizards" are equivalent. 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. append ::= "APPEND" SP mailbox SP string body ::= "(" body_structure ")" body_basic ::= body_type SP body_subtype SP body_parameter SP body_id SP body_description SP body_encoding SP body_size_byte body_description::= nil / string body_encoding ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/ "QUOTEDPRINTABLE" / "X-UNKNOWN" body_id ::= nil / string body_msg ::= body_basic SP envelope SP body body_parameter ::= nil / string body_section ::= NUMBER / NUMBER "." body_section body_size_byte ::= NUMBER body_size_line ::= NUMBER body_structure ::= body_basic / body_msg / body_text / 1#body_structure SP body_subtype body_subtype ::= nil / string body_text ::= body_basic SP body_size_line body_type ::= "TEXT" / "MULTIPART" / "MESSAGE" / "APPLICATION" / "AUDIO" / "IMAGE" / "VIDEO" / "X-UNKNOWN" create ::= "CREATE" SP mailbox date ::= date_new / date_old date_new ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz" date_old ::= string in form "dd-mmm-yy hh:mm:ss-zzz" ;; obsolete day ::= day_new / day_old day_new ::= string in form "dd-mmm-yyyy" day_old ::= string in form "dd-mmm-yy" ;; obsolete delete ::= "DELETE" SP mailbox fetch ::= "FETCH" SP sequence SP ("ALL" / "FULL" / "FAST" / fetch_att / "(" 1#fetch_att ")") fetch_att ::= fetch_att_other / fetch_att_text fetch_att_other ::= "BODY" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" / "RFC822.SIZE" fetch_att_text ::= "BODY[" body_section "]" / "RFC822" / "RFC822.HEADER" / "RFC822.TEXT" find_option ::= "MAILBOXES" / "BBOARDS" / "ALL.MAILBOXES" / "ALL.BBOARDS" istring ::= string / RFC-1342 format multinational string msg_copy ::= "COPY" ;; obsolete msg_data ::= msg_exists / msg_recent / msg_expunge / msg_fetch / msg_copy / msg_store msg_fetch ::= "FETCH" 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) ")" msg_store ::= "STORE" SP "(" 1#("FLAGS" SP "(" 1#(recent_flag flag_list) ")" ) ")" ;; obsolete partial ::= "PARTIAL" SP NUMBER SP fetch_att_text SP NUMBER SP NUMBER purge ::= "PURGE" SP ("ALWAYS" / purge_option SP sequence) purge_option ::= "STATUS" / "STRUCTURE" / "TEXTS" / token rename ::= "RENAME" SP mailbox SP string search ::= "SEARCH" SP 1#("ALL" / "ANSWERED" / "BCC" SP string / "BEFORE" SP day / "BODY" SP istring / "CC" SP string / "DELETED" / "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" / "ON" SP day / "RECENT" / "SEEN" / "SINCE" SP day / "TEXT" SP istring / "TO" SP string / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNKEYWORD" / "UNSEEN") subscribe ::= "SUBSCRIBE" SP subscribe_opt SP string subscribe_opt ::= "MAILBOX" / "BBOARD" unsubscribe ::= "UNSUBSCRIBE" SP subscribe_opt SP string userid ::= string / "anonymous" Implementation Status The University of Washington IMAP2bis distribution supports this specification. It can be obtained as mail/imap.tar.Z via anonymous FTP from host ftp.cac.washington.edu; this is a compressed UNIX `tar' format file. The University of Washington IMAP2bis distribution includes external authentication using the Unix r-protocols. Sites can enable or disable rimap at their discretion; users can control rimap behavior (provided the site has enabled it) by use of the standard .rhosts and hosts.equiv files. The anonymous convention is also included for anonymous access to newsgroups is can also be enabled or disabled on a site basis. A Kerberized IMAP2bis 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. 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. It was rejected 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, it should be transmitted out of band from the IMAP2 command stream. This would have the necessary but unfortunate effect of making the protcol more complicated. Unresolved issues The following issues are unresolved by IMAP2bis. It is anticipated that these will be dealt with in future specifications. The management capabilities of IMAP2bis are inadequate for complex distributed mail configurations. A separate specification, under development at CMU, addresses this. The SEARCH command lacks MIME awareness, regular expressions, complex logical qualifiers, etc. This should be addressed in future versions of the IMAP2 specification. It isn't clear that the RFC-1342 extensions to SEARCH are adequate for the task. Message posting is orthogonal to the scope of a mail access protocol, and it is undesirable for a number of reasons to shoehorn the two into a single protocol. However, issues of authentication and what to do with a uni-channel link (e.g. IMAP over a dialup line) have come up. The IETF-REMMAIL working group is wrestling with these issues at this writing. Envelopes do not carry information such as resend data, newsgroups, etc. Newsgroups can probably be encoded within the existing address list syntax. The question has come up as to whether or not there should be a way for the server to build client browser lines. Acknowledgements Special thanks go to John Gardiner Myers, Chris Newman, Karl Jacob, Hisao Nojima, Terry Gray, Adam Treister, Laurence Lundblade, and Mike Seibel for their hard work in reviewing the present status of IMAP2, and for reaching concensus and closure on a number of issues in record time. 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 IMAP2bis protocol extension are, however, strictly my own; and no endorsement on the part of anyone is implied. Security Considerations Security issues are discussed in this memo only as far as authentication for the purpose of accessing an IMAP2bis server are concerned. Author's Address Mark R. Crispin Networks and Distributed Computing University of Washington Seattle, WA 98105 Phone: (206) 842-2385 EMail: MRC@CAC.Washington.EDU