rfc2060.txt

SIP（Session Initiation Protocol）是由IETF定义

      Note: If, instead, the server detected an error in the command, it
      sends a BAD completion response with tag matching the command (as
      described below) to reject the command and prevent the client from
      sending any more of the command.

      It is also possible for the server to send a completion response
      for some other command (if multiple commands are in progress), or
      untagged data.  In either case, the command continuation request
      is still pending; the client takes the appropriate action for the
      response, and reads another response from the server.  In all
      cases, the client MUST send a complete command (including
      receiving all command continuation request responses and command
      continuations for the command) before initiating a new command.

   The protocol receiver of an IMAP4rev1 server reads a command line
   from the client, parses the command and its arguments, and transmits
   server data and a server command completion result response.





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


2.2.2.  Server Protocol Sender and Client Protocol Receiver

   Data transmitted by the server to the client and status responses
   that do not indicate command completion are prefixed with the token
   "*", and are called untagged responses.

   Server data MAY be sent as a result of a client command, or MAY be
   sent unilaterally by the server.  There is no syntactic difference
   between server data that resulted from a specific command and server
   data that were sent unilaterally.

   The server completion result response indicates the success or
   failure of the operation.  It is tagged with the same tag as the
   client command which began the operation.  Thus, if more than one
   command is in progress, the tag in a server completion response
   identifies the command to which the response applies.  There are
   three possible server completion responses: OK (indicating success),
   NO (indicating failure), or BAD (indicating protocol error such as
   unrecognized command or command syntax error).

   The protocol receiver of an IMAP4rev1 client reads a response line
   from the server.  It then takes action on the response based upon the
   first token of the response, which can be a tag, a "*", or a "+".

   A client MUST be prepared to accept any server response at all times.
   This includes server data that was not requested.  Server data SHOULD
   be recorded, so that the client can reference its recorded copy
   rather than sending a command to the server to request the data.  In
   the case of certain server data, the data MUST be recorded.

   This topic is discussed in greater detail in the Server Responses
   section.

2.3.    Message Attributes

   In addition to message text, each message has several attributes
   associated with it.  These attributes may be retrieved individually
   or in conjunction with other attributes or message texts.

2.3.1.  Message Numbers

   Messages in IMAP4rev1 are accessed by one of two numbers; the unique
   identifier and the message sequence number.

2.3.1.1.        Unique Identifier (UID) Message Attribute

   A 32-bit value assigned to each message, which when used with the
   unique identifier validity value (see below) forms a 64-bit value



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


   that is permanently guaranteed not to refer to any other message in
   the mailbox.  Unique identifiers are assigned in a strictly ascending
   fashion in the mailbox; as each message is added to the mailbox it is
   assigned a higher UID than the message(s) which were added
   previously.

   Unlike message sequence numbers, unique identifiers are not
   necessarily contiguous.  Unique identifiers also persist across
   sessions.  This permits a client to resynchronize its state from a
   previous session with the server (e.g. disconnected or offline access
   clients); this is discussed further in [IMAP-DISC].

   Associated with every mailbox is a unique identifier validity value,
   which is sent in an UIDVALIDITY response code in an OK untagged
   response at mailbox selection time.  If unique identifiers from an
   earlier session fail to persist to this session, the unique
   identifier validity value MUST be greater than the one used in the
   earlier session.

      Note: Unique identifiers MUST be strictly ascending in the mailbox
      at all times.  If the physical message store is re-ordered by a
      non-IMAP agent, this requires that the unique identifiers in the
      mailbox be regenerated, since the former unique identifers are no
      longer strictly ascending as a result of the re-ordering.  Another
      instance in which unique identifiers are regenerated is if the
      message store has no mechanism to store unique identifiers.
      Although this specification recognizes that this may be
      unavoidable in certain server environments, it STRONGLY ENCOURAGES
      message store implementation techniques that avoid this problem.

      Another cause of non-persistance is if the mailbox is deleted and
      a new mailbox with the same name is created at a later date, Since
      the name is the same, a client may not know that this is a new
      mailbox unless the unique identifier validity is different.  A
      good value to use for the unique identifier validity value is a
      32-bit representation of the creation date/time of the mailbox.
      It is alright to use a constant such as 1, but only if it
      guaranteed that unique identifiers will never be reused, even in
      the case of a mailbox being deleted (or renamed) and a new mailbox
      by the same name created at some future time.

   The unique identifier of a message MUST NOT change during the
   session, and SHOULD NOT change between sessions.  However, if it is
   not possible to preserve the unique identifier of a message in a
   subsequent session, each subsequent session MUST have a new unique
   identifier validity value that is larger than any that was used
   previously.




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


2.3.1.2.        Message Sequence Number Message Attribute

   A relative position from 1 to the number of messages in the mailbox.
   This position MUST be ordered by ascending unique identifier.  As
   each new message is added, it is assigned a message sequence number
   that is 1 higher than the number of messages in the mailbox before
   that new message was added.

   Message sequence numbers can be reassigned during the session.  For
   example, when a message is permanently removed (expunged) from the
   mailbox, the message sequence number for all subsequent messages is
   decremented.  Similarly, a new message can be assigned a message
   sequence number that was once held by some other message prior to an
   expunge.

   In addition to accessing messages by relative position in the
   mailbox, message sequence numbers can be used in mathematical
   calculations.  For example, if an untagged "EXISTS 11" is received,
   and previously an untagged "8 EXISTS" was received, three new
   messages have arrived with message sequence numbers of 9, 10, and 11.
   Another example; if message 287 in a 523 message mailbox has UID
   12345, there are exactly 286 messages which have lesser UIDs and 236
   messages which have greater UIDs.

2.3.2.  Flags Message Attribute

   A list of zero or more named tokens associated with the message.  A
   flag is set by its addition to this list, and is cleared by its
   removal.  There are two types of flags in IMAP4rev1.  A flag of
   either type may be permanent or session-only.

   A system flag is a flag name that is pre-defined in this
   specification.  All system flags begin with "\".  Certain system
   flags (\Deleted and \Seen) have special semantics described
   elsewhere.  The currently-defined system flags are:

        \Seen       Message has been read

        \Answered   Message has been answered

        \Flagged    Message is "flagged" for urgent/special attention

        \Deleted    Message is "deleted" for removal by later EXPUNGE

        \Draft      Message has not completed composition (marked as a
                    draft).





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


        \Recent     Message is "recently" arrived in this mailbox.  This
                    session is the first session to have been notified
                    about this message; subsequent sessions will not see
                    \Recent set for this message.  This flag can not be
                    altered by the client.

                    If it is not possible to determine whether or not
                    this session is the first session to be notified
                    about a message, then that message SHOULD be
                    considered recent.

                    If multiple connections have the same mailbox
                    selected simultaneously, it is undefined which of
                    these connections will see newly-arrives messages
                    with \Recent set and which will see it without
                    \Recent set.

      A keyword is defined by the server implementation.  Keywords do
      not begin with "\".  Servers MAY permit the client to define new
      keywords in the mailbox (see the description of the
      PERMANENTFLAGS response code for more information).

      A flag may be permanent or session-only on a per-flag basis.
      Permanent flags are those which the client can add or remove
      from the message flags permanently; that is, subsequent sessions
      will see any change in permanent flags.  Changes to session
      flags are valid only in that session.

      Note: The \Recent system flag is a special case of a
      session flag.  \Recent can not be used as an argument in a
      STORE command, and thus can not be changed at all.

2.3.3.  Internal Date Message Attribute

   The internal date and time of the message on the server.  This is not
   the date and time in the [RFC-822] header, but rather a date and time
   which reflects when the message was received.  In the case of
   messages delivered via [SMTP], this SHOULD be the date and time of
   final delivery of the message as defined by [SMTP].  In the case of
   messages delivered by the IMAP4rev1 COPY command, this SHOULD be the
   internal date and time of the source message.  In the case of
   messages delivered by the IMAP4rev1 APPEND command, this SHOULD be
   the date and time as specified in the APPEND command description.
   All other cases are implementation defined.







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


2.3.4.  [RFC-822] Size Message Attribute

   The number of octets in the message, as expressed in [RFC-822]
   format.

2.3.5.  Envelope Structure Message Attribute

   A parsed representation of the [RFC-822] envelope information (not to
   be confused with an [SMTP] envelope) of the message.

2.3.6.  Body Structure Message Attribute

   A parsed representation of the [MIME-IMB] body structure information
   of the message.

2.4.    Message Texts

   In addition to being able to fetch the full [RFC-822] text of a
   message, IMAP4rev1 permits the fetching of portions of the full
   message text.  Specifically, it is possible to fetch the [RFC-822]
   message header, [RFC-822] message body, a [MIME-IMB] body part, or a
   [MIME-IMB] header.

3.      State and Flow Diagram

   An IMAP4rev1 server is in one of four states.  Most commands are
   valid in only certain states.  It is a protocol error for the client
   to attempt a command while the command is in an inappropriate state.
   In this case, a server will respond with a BAD or NO (depending upon
   server implementation) command completion result.

3.1.    Non-Authenticated State

   In non-authenticated state, the client MUST supply authentication
   credentials before most commands will be permitted.  This state is
   entered when a connection starts unless the connection has been pre-
   authenticated.

3.2.    Authenticated State

   In authenticated state, the client is authenticated and MUST select a
   mailbox to access before commands that affect messages will be
   permitted.  This state is entered when a pre-authenticated connection
   starts, when acceptable authentication credentials have been
   provided, or after an error in selecting a mailbox.






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


3.3.    Selected State

   In selected state, a mailbox has been selected to access.  This state
   is entered when a mailbox has been successfully selected.

3.4.    Logout State

   In logout state, the connection is being terminated, and the server