aboutsummaryrefslogtreecommitdiffstats
path: root/RFC/rfc2062.txt
diff options
context:
space:
mode:
authorRob Funk <rfunk@funknet.net>2004-06-08 03:59:01 +0000
committerRob Funk <rfunk@funknet.net>2004-06-08 03:59:01 +0000
commitd78b61e3efaea197a6e5b2b72bf2981a9ed69461 (patch)
tree1704e13ce5d767d59868a2d5e834cb2e988ed90f /RFC/rfc2062.txt
parentd9e84e176fe538e110d9612f9832d69846e8d3e7 (diff)
downloadfetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.tar.gz
fetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.tar.bz2
fetchmail-d78b61e3efaea197a6e5b2b72bf2981a9ed69461.zip
Add files from ESR's dev directory that weren't under version control
svn path=/trunk/; revision=3881
Diffstat (limited to 'RFC/rfc2062.txt')
-rw-r--r--RFC/rfc2062.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/RFC/rfc2062.txt b/RFC/rfc2062.txt
new file mode 100644
index 00000000..865d1dad
--- /dev/null
+++ b/RFC/rfc2062.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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]
+
+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]
+
+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]
+
+RFC 2062 IMAP4 Obsolete December 1996
+
+
+ The following FETCH items are valid data for PARTIAL: RFC822,
+ RFC822.HEADER, RFC822.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 RFC822 1 1024
+ S: * 1 FETCH (RFC822 {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).
+
+ RFC822.HEADER.LINES <header_list>
+ Functionally equivalent to BODY.PEEK[HEADER.LINES
+ <header_list>], differing in the syntax of the
+ resulting untagged FETCH data (RFC822.HEADER is
+ returned).
+
+
+
+
+
+
+
+Crispin Informational [Page 4]
+
+RFC 2062 IMAP4 Obsolete December 1996
+
+
+ RFC822.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 (RFC822.HEADER is returned).
+
+ RFC822.PEEK Functionally equivalent to BODY.PEEK[], except for
+ the syntax of the resulting untagged FETCH data
+ (RFC822 is returned).
+
+ RFC822.TEXT.PEEK
+ Functionally equivalent to BODY.PEEK[TEXT], except
+ for the syntax of the resulting untagged FETCH data
+ (RFC822.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]
+
+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]
+
+RFC 2062 IMAP4 Obsolete December 1996
+
+
+ find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE
+ list_mailbox
+
+ fetch_att_old ::= "RFC822.HEADER.LINES" [".NOT"] SPACE header_list /
+ fetch_text_old
+
+ fetch_text_old ::= "BODY" [".PEEK"] section_old /
+ "RFC822" [".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]
+
+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]
+