rfc2060.txt

SIP（Session Initiation Protocol）是由IETF定义

Network Working Group                                        M. Crispin
Request for Comments: 2060                     University of Washington
Obsoletes: 1730                                           December 1996
Category: Standards Track


            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
   allows a client to access and manipulate electronic mail messages on
   a server.  IMAP4rev1 permits manipulation of remote message folders,
   called "mailboxes", in a way that is functionally equivalent to local
   mailboxes.  IMAP4rev1 also provides the capability for an offline
   client to resynchronize with the server (see also [IMAP-DISC]).

   IMAP4rev1 includes operations for creating, deleting, and renaming
   mailboxes; checking for new messages; permanently removing messages;
   setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
   searching; and selective fetching of message attributes, texts, and
   portions thereof.  Messages in IMAP4rev1 are accessed by the use of
   numbers.  These numbers are either message sequence numbers or unique
   identifiers.

   IMAP4rev1 supports a single server.  A mechanism for accessing
   configuration information to support multiple IMAP4rev1 servers is
   discussed in [ACAP].

   IMAP4rev1 does not specify a means of posting mail; this function is
   handled by a mail transfer protocol such as [SMTP].

   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
   unpublished IMAP2bis protocols.  In the course of the evolution of
   IMAP4rev1, some aspects in the earlier protocol have become obsolete.
   Obsolete commands, responses, and data formats which an IMAP4rev1
   implementation may encounter when used with an earlier implementation
   are described in [IMAP-OBSOLETE].





Crispin                     Standards Track                     [Page 1]

RFC 2060                       IMAP4rev1                   December 1996


   Other compatibility issues with IMAP2bis, the most common variant of
   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
   discussion of compatibility issues with rare (and presumed extinct)
   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
   primarily of historical interest.

Table of Contents

IMAP4rev1 Protocol Specification ..................................    4
1.      How to Read This Document .................................    4
1.1.    Organization of This Document .............................    4
1.2.    Conventions Used in This Document .........................    4
2.      Protocol Overview .........................................    5
2.1.    Link Level ................................................    5
2.2.    Commands and Responses ....................................    6
2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    6
2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    7
2.3.    Message Attributes ........................................    7
2.3.1.  Message Numbers ...........................................    7
2.3.1.1.        Unique Identifier (UID) Message Attribute .........    7
2.3.1.2.        Message Sequence Number Message Attribute .........    9
2.3.2.  Flags Message Attribute ....................................   9
2.3.3.  Internal Date Message Attribute ...........................   10
2.3.4.  [RFC-822] Size Message Attribute ..........................   11
2.3.5.  Envelope Structure Message Attribute ......................   11
2.3.6.  Body Structure Message Attribute ..........................   11
2.4.    Message Texts .............................................   11
3.      State and Flow Diagram ....................................   11
3.1.    Non-Authenticated State ...................................   11
3.2.    Authenticated State .......................................   11
3.3.    Selected State ............................................   12
3.4.    Logout State ..............................................   12
4.      Data Formats ..............................................   12
4.1.    Atom ......................................................   13
4.2.    Number ....................................................   13
4.3.    String .....................................................  13
4.3.1.  8-bit and Binary Strings ..................................   13
4.4.    Parenthesized List ........................................   14
4.5.    NIL .......................................................   14
5.      Operational Considerations ................................   14
5.1.    Mailbox Naming ............................................   14
5.1.1.  Mailbox Hierarchy Naming ..................................   14
5.1.2.  Mailbox Namespace Naming Convention .......................   14
5.1.3.  Mailbox International Naming Convention ...................   15
5.2.    Mailbox Size and Message Status Updates ...................   16
5.3.    Response when no Command in Progress ......................   16
5.4.    Autologout Timer ..........................................   16
5.5.    Multiple Commands in Progress .............................   17



Crispin                     Standards Track                     [Page 2]

RFC 2060                       IMAP4rev1                   December 1996


6.      Client Commands ...........................................   17
6.1.    Client Commands - Any State ...............................   18
6.1.1.  CAPABILITY Command ........................................   18
6.1.2.  NOOP Command ..............................................   19
6.1.3.  LOGOUT Command ............................................   20
6.2.    Client Commands - Non-Authenticated State .................   20
6.2.1.  AUTHENTICATE Command ......................................   21
6.2.2.  LOGIN Command .............................................   22
6.3.    Client Commands - Authenticated State .....................   22
6.3.1.  SELECT Command ............................................   23
6.3.2.  EXAMINE Command ...........................................   24
6.3.3.  CREATE Command ............................................   25
6.3.4.  DELETE Command ............................................   26
6.3.5.  RENAME Command ............................................   27
6.3.6.  SUBSCRIBE Command .........................................   29
6.3.7.  UNSUBSCRIBE Command .......................................   30
6.3.8.  LIST Command ..............................................   30
6.3.9.  LSUB Command ..............................................   32
6.3.10. STATUS Command ............................................   33
6.3.11. APPEND Command ............................................   34
6.4.    Client Commands - Selected State ..........................   35
6.4.1.  CHECK Command .............................................   36
6.4.2.  CLOSE Command .............................................   36
6.4.3.  EXPUNGE Command ...........................................   37
6.4.4.  SEARCH Command ............................................   37
6.4.5.  FETCH Command .............................................   41
6.4.6.  STORE Command .............................................   45
6.4.7.  COPY Command ..............................................   46
6.4.8.  UID Command ...............................................   47
6.5.    Client Commands - Experimental/Expansion ..................   48
6.5.1.  X<atom> Command ...........................................   48
7.      Server Responses ..........................................   48
7.1.    Server Responses - Status Responses .......................   49
7.1.1.  OK Response ...............................................   51
7.1.2.  NO Response ...............................................   51
7.1.3.  BAD Response ..............................................   52
7.1.4.  PREAUTH Response ..........................................   52
7.1.5.  BYE Response ..............................................   52
7.2.    Server Responses - Server and Mailbox Status ..............   53
7.2.1.  CAPABILITY Response .......................................   53
7.2.2.  LIST Response ..............................................  54
7.2.3.  LSUB Response .............................................   55
7.2.4   STATUS Response ...........................................   55
7.2.5.  SEARCH Response ...........................................   55
7.2.6.  FLAGS Response ............................................   56
7.3.    Server Responses - Mailbox Size ...........................   56
7.3.1.  EXISTS Response ...........................................   56
7.3.2.  RECENT Response ...........................................   57



Crispin                     Standards Track                     [Page 3]

RFC 2060                       IMAP4rev1                   December 1996


7.4.    Server Responses - Message Status .........................   57
7.4.1.  EXPUNGE Response ..........................................   57
7.4.2.  FETCH Response ............................................   58
7.5.    Server Responses - Command Continuation Request ...........   63
8.      Sample IMAP4rev1 connection ...............................   63
9.      Formal Syntax .............................................   64
10.     Author's Note .............................................   74
11.     Security Considerations ...................................   74
12.     Author's Address ..........................................   75
Appendices ........................................................   76
A.      References ................................................   76
B.      Changes from RFC 1730 .....................................   77
C.      Key Word Index ............................................   79


IMAP4rev1 Protocol Specification

1.      How to Read This Document

1.1.    Organization of This Document

   This document is written from the point of view of the implementor of
   an IMAP4rev1 client or server.  Beyond the protocol overview in
   section 2, it is not optimized for someone trying to understand the
   operation of the protocol.  The material in sections 3 through 5
   provides the general context and definitions with which IMAP4rev1
   operates.

   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, do not attempt to deduce command syntax from the command
   section alone; instead refer to the Formal Syntax section.

1.2.    Conventions Used in This Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

   The following terms are used in this document to signify the
   requirements of this specification.

   1) MUST, or the adjective REQUIRED, means that the definition is
      an absolute requirement of the specification.

   2) MUST NOT that the definition is an absolute prohibition of the
      specification.




Crispin                     Standards Track                     [Page 4]

RFC 2060                       IMAP4rev1                   December 1996


   3) SHOULD means that there may exist valid reasons in particular
      circumstances to ignore a particular item, but the full
      implications MUST be understood and carefully weighed before
      choosing a different course.

   4) SHOULD NOT means that there may exist valid reasons in
      particular circumstances when the particular behavior is
      acceptable or even useful, but the full implications SHOULD be
      understood and the case carefully weighed before implementing
      any behavior described with this label.

   5) MAY, or the adjective OPTIONAL, means that an item is truly
      optional.  One vendor may choose to include the item because a
      particular marketplace requires it or because the vendor feels
      that it enhances the product while another vendor may omit the
      same item.  An implementation which does not include a
      particular option MUST be prepared to interoperate with another
      implementation which does include the option.

      "Can" is used instead of "may" when referring to a possible
      circumstance or situation, as opposed to an optional facility of
      the protocol.

      "User" is used to refer to a human user, whereas "client" refers
      to the software being run by the user.

      "Connection" refers to the entire sequence of client/server
      interaction from the initial establishment of the network
      connection until its termination.  "Session" refers to the
      sequence of client/server interaction from the time that a mailbox
      is selected (SELECT or EXAMINE command) until the time that
      selection ends (SELECT or EXAMINE of another mailbox, CLOSE
      command, or connection termination).

       Characters are 7-bit US-ASCII unless otherwise specified.  Other
       character sets are indicated using a "CHARSET", as described in
       [MIME-IMT] and defined in [CHARSET].  CHARSETs have important
       additional semantics in addition to defining character set; refer
       to these documents for more detail.

2.      Protocol Overview

2.1.    Link Level

   The IMAP4rev1 protocol assumes a reliable data stream such as
   provided by TCP.  When TCP is used, an IMAP4rev1 server listens on
   port 143.




Crispin                     Standards Track                     [Page 5]

RFC 2060                       IMAP4rev1                   December 1996


2.2.    Commands and Responses

   An IMAP4rev1 connection consists of the establishment of a
   client/server network connection, an initial greeting from the
   server, and client/server interactions.  These client/server
   interactions consist of a client command, server data, and a server
   completion result response.

   All interactions transmitted by client and server are in the form of
   lines; that is, strings that end with a CRLF.  The protocol receiver
   of an IMAP4rev1 client or server is either reading a line, or is
   reading a sequence of octets with a known count followed by a line.

2.2.1.  Client Protocol Sender and Server Protocol Receiver

   The client command begins an operation.  Each client command is
   prefixed with an identifier (typically a short alphanumeric string,
   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
   generated by the client for each command.

   There are two cases in which a line from the client does not
   represent a complete command.  In one case, a command argument is
   quoted with an octet count (see the description of literal in String
   under Data Formats); in the other case, the command arguments require
   server feedback (see the AUTHENTICATE command).  In either case, the
   server sends a command continuation request response if it is ready
   for the octets (if appropriate) and the remainder of the command.
   This response is prefixed with the token "+".