GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2062

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2062.txt · Last modified: 1996/12/03 17:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki