The RFC Archive
 The RFC Archive   RFC 2062   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 2062

Internet Message Access Protocol - Obsolete Syntax

Last modified on Tuesday, December 3rd, 1996

Permanent link to RFC 2062
Search GitHub Wiki for RFC 2062
Show other RFCs mentioning RFC 2062







Network Working Group                                         M. Crispin
Request for Comments: 2062                      University of Washington
Category: Informational                                  December 1996


           Internet Message Access Protocol - Obsolete Syntax

 Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

 Abstract

   This document describes obsolete syntax which may be encountered by
   IMAP4 implementations which deal with older versions of the Internet
   Mail Access Protocol.  IMAP4 implementations MAY implement this
   syntax in order to maximize interoperability with older
   implementations.

   This document repeats information from earlier documents, most
   notably RFC 1176 and RFC 1730.

Obsolete Commands and Fetch Data Items

   The following commands are OBSOLETE.  It is NOT required to support
   any of these commands or fetch data items in new server
   implementations.  These commands are documented here for the benefit
   of implementors who may wish to support them for compatibility with
   old client implementations.

   The section headings of these commands are intended to correspond
   with where they would be located in the main document if they were
   not obsoleted.

6.3.OBS.1.      FIND ALL.MAILBOXES Command

   Arguments:  mailbox name with possible wildcards

   Data:       untagged responses: MAILBOX

   Result:     OK - find completed
               NO - find failure: can't list that name
               BAD - command unknown or arguments invalid






Crispin                      Informational                   PAGE 1 top


RFC 2062 IMAP4 Obsolete December 1996 The FIND ALL.MAILBOXES command returns a subset of names from the complete set of all names available to the user. It returns zero or more untagged MAILBOX replies. The mailbox argument to FIND ALL.MAILBOXES is similar to that for LIST with an empty reference, except that the characters "%" and "?" match a single character. Example: C: A002 FIND ALL.MAILBOXES * S: * MAILBOX blurdybloop S: * MAILBOX INBOX S: A002 OK FIND ALL.MAILBOXES completed 6.3.OBS.2. FIND MAILBOXES Command Arguments: mailbox name with possible wildcards Data: untagged responses: MAILBOX Result: OK - find completed NO - find failure: can't list that name BAD - command unknown or arguments invalid The FIND MAILBOXES command returns a subset of names from the set of names that the user has declared as being "active" or "subscribed". It returns zero or more untagged MAILBOX replies. The mailbox argument to FIND MAILBOXES is similar to that for LSUB with an empty reference, except that the characters "%" and "?" match a single character. Example: C: A002 FIND MAILBOXES * S: * MAILBOX blurdybloop S: * MAILBOX INBOX S: A002 OK FIND MAILBOXES completed 6.3.OBS.3. SUBSCRIBE MAILBOX Command Arguments: mailbox name Data: no specific data for this command Result: OK - subscribe completed NO - subscribe failure: can't subscribe to that name BAD - command unknown or arguments invalid The SUBSCRIBE MAILBOX command is identical in effect to the SUBSCRIBE command. A server which implements this command must be able to distinguish between a SUBSCRIBE MAILBOX command and a SUBSCRIBE command with a mailbox name argument of "MAILBOX". Crispin Informational PAGE 2 top

RFC 2062 IMAP4 Obsolete December 1996 Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime completed C: A003 SUBSCRIBE MAILBOX S: A003 OK SUBSCRIBE to MAILBOX completed 6.3.OBS.4. UNSUBSCRIBE MAILBOX Command Arguments: mailbox name Data: no specific data for this command Result: OK - unsubscribe completed NO - unsubscribe failure: can't unsubscribe that name BAD - command unknown or arguments invalid The UNSUBSCRIBE MAILBOX command is identical in effect to the UNSUBSCRIBE command. A server which implements this command must be able to distinguish between a UNSUBSCRIBE MAILBOX command and an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime completed C: A003 UNSUBSCRIBE MAILBOX S: A003 OK UNSUBSCRIBE from MAILBOX completed 6.4.OBS.1 PARTIAL Command Arguments: message sequence number message data item name position of first octet number of octets Data: untagged responses: FETCH Result: OK - partial completed NO - partial error: can't fetch that data BAD - command unknown or arguments invalid The PARTIAL command is equivalent to the associated FETCH command, with the added functionality that only the specified number of octets, beginning at the specified starting octet, are returned. Only a single message can be fetched at a time. The first octet of a message, and hence the minimum for the starting octet, is octet 1. Crispin Informational PAGE 3 top

RFC 2062 IMAP4 Obsolete December 1996 The following FETCH items are valid data for PARTIAL: RFC 822, RFC 822.HEADER, RFC 822.TEXT, BODY[<section>], as well as any .PEEK forms of these. Any partial fetch that attempts to read beyond the end of the text is truncated as appropriate. If the starting octet is beyond the end of the text, an empty string is returned. The data are returned with the FETCH response. There is no indication of the range of the partial data in this response. It is not possible to stream multiple PARTIAL commands of the same data item without processing and synchronizing at each step, since streamed commands may be executed out of order. There is no requirement that partial fetches follow any sequence. For example, if a partial fetch of octets 1 through 10000 breaks in an awkward place for BASE64 decoding, it is permitted to continue with a partial fetch of 9987 through 19987, etc. The handling of the \Seen flag is the same as in the associated FETCH command. Example: C: A005 PARTIAL 4 RFC 822 1 1024 S: * 1 FETCH (RFC 822 {1024} S: Return-Path: <gray@cac.washington.edu> S: ... S: ......... FLAGS (\Seen)) S: A005 OK PARTIAL completed 6.4.5.OBS.1 Obsolete FETCH Data Items The following FETCH data items are obsolete: BODY[<...>0] A body part number of 0 is the [RFC 822] header of the message. BODY[0] is functionally equivalent to BODY[HEADER], differing in the syntax of the resulting untagged FETCH data (BODY[0] is returned). RFC 822.HEADER.LINES <header_list> Functionally equivalent to BODY.PEEK[HEADER.LINES <header_list>], differing in the syntax of the resulting untagged FETCH data (RFC 822.HEADER is returned). Crispin Informational PAGE 4 top

RFC 2062 IMAP4 Obsolete December 1996 RFC 822.HEADER.LINES.NOT <header_list> Functionally equivalent to BODY.PEEK[HEADER.LINES.NOT <header_list>], differing in the syntax of the resulting untagged FETCH data (RFC 822.HEADER is returned). RFC 822.PEEK Functionally equivalent to BODY.PEEK[], except for the syntax of the resulting untagged FETCH data (RFC 822 is returned). RFC 822.TEXT.PEEK Functionally equivalent to BODY.PEEK[TEXT], except for the syntax of the resulting untagged FETCH data (RFC 822.TEXT is returned). Obsolete Responses The following responses are OBSOLETE. Except as noted below, these responses MUST NOT be transmitted by new server implementations. Client implementations SHOULD accept these responses. The section headings of these responses are intended to correspond with where they would be located in the main document if they were not obsoleted. 7.2.OBS.1. MAILBOX Response Data: name The MAILBOX response MUST NOT be transmitted by server implementations except in response to the obsolete FIND MAILBOXES and FIND ALL.MAILBOXES commands. Client implementations that do not use these commands MAY ignore this response. It is documented here for the benefit of implementors who may wish to support it for compatibility with old client implementations. This response occurs as a result of the FIND MAILBOXES and FIND ALL.MAILBOXES commands. It returns a single name that matches the FIND specification. There are no attributes or hierarchy delimiter. Example: S: * MAILBOX blurdybloop Crispin Informational PAGE 5 top

RFC 2062 IMAP4 Obsolete December 1996 7.3.OBS.1. COPY Response Data: none The COPY response MUST NOT be transmitted by new server implementations. Client implementations MUST ignore the COPY response. It is documented here for the benefit of client implementors who may encounter this response from old server implementations. In some experimental versions of this protocol, this response was returned in response to a COPY command to indicate on a per-message basis that the message was copied successfully. Example: S: * 44 COPY 7.3.OBS.2. STORE Response Data: message data The STORE response MUST NOT be transmitted by new server implementations. Client implementations MUST treat the STORE response as equivalent to the FETCH response. It is documented here for the benefit of client implementors who may encounter this response from old server implementations. In some experimental versions of this protocol, this response was returned instead of FETCH in response to a STORE command to report the new value of the flags. Example: S: * 69 STORE (FLAGS (\Deleted)) Formal Syntax of Obsolete Commands and Responses Each obsolete syntax rule that is suffixed with "_old" is added to the corresponding name in the formal syntax. For example, command_auth_old adds the FIND command to command_auth. command_auth_old ::= find command_select_old ::= partial date_year_old ::= 2digit ;; (year - 1900) date_time_old ::= <"> date_day_fixed "-" date_month "-" date_year SPACE time "-" zone_name <"> Crispin Informational PAGE 6 top

RFC 2062 IMAP4 Obsolete December 1996 find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE list_mailbox fetch_att_old ::= "RFC 822.HEADER.LINES" [".NOT"] SPACE header_list / fetch_text_old fetch_text_old ::= "BODY" [".PEEK"] section_old / "RFC 822" [".HEADER" / ".TEXT" [".PEEK"]] msg_data_old ::= "COPY" / ("STORE" SPACE msg_att) partial ::= "PARTIAL" SPACE nz_number SPACE fetch_text_old SPACE number SPACE number section_old ::= "[" (number ["." number]) "]" subscribe_old ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox unsubscribe_old ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox zone_name ::= "UT" / "GMT" / "Z" / ;; +0000 "AST" / "EDT" / ;; -0400 "EST" / "CDT" / ;; -0500 "CST" / "MDT" / ;; -0600 "MST" / "PDT" / ;; -0700 "PST" / "YDT" / ;; -0800 "YST" / "HDT" / ;; -0900 "HST" / "BDT" / ;; -1000 "BST" / ;; -1100 "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 Security Considerations Security issues are not discussed in this memo. Crispin Informational PAGE 7 top

RFC 2062 IMAP4 Obsolete December 1996 Author's Address Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Aveneue NE Seattle, WA 98105-4527 Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU Crispin Informational PAGE 8 top

Internet Message Access Protocol - Obsolete Syntax RFC TOTAL SIZE: 14042 bytes PUBLICATION DATE: Tuesday, December 3rd, 1996 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 2062: The IETF Trust, Tuesday, December 3rd, 1996
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement