Section 5. Operational Considerations

The following rules are listed here to ensure that all IMAP4rev2
   implementations interoperate properly.
5.1.  Mailbox Naming
   In IMAP4rev2, mailbox names are encoded in Net-Unicode [NET-UNICODE]
   (this differs from IMAP4rev1).  Client implementations MAY attempt to
   create Net-Unicode mailbox names and MUST interpret any 8-bit mailbox
   names returned by LIST as [NET-UNICODE].  Server implementations MUST
   prohibit the creation of 8-bit mailbox names that do not comply with
   Net-Unicode.  However, servers MAY accept a denormalized UTF-8
   mailbox name and convert it to Unicode Normalization Form C (NFC) (as
   per Net-Unicode requirements) prior to mailbox creation.  Servers
   that choose to accept such denormalized UTF-8 mailbox names MUST
   accept them in all IMAP commands that have a mailbox name parameter.
   In particular, SELECT <name> must open the same mailbox that was
   successfully created with CREATE <name>, even if <name> is a
   denormalized UTF-8 mailbox name.
   The case-insensitive mailbox name INBOX is a special name reserved to
   mean "the primary mailbox for this user on this server".  (Note that
   this special name might not exist on some servers for some users, for
   example, if the user has no access to personal namespace.)  The
   interpretation of all other names is implementation dependent.
   In particular, this specification takes no position on case
   sensitivity in non-INBOX mailbox names.  Some server implementations
   are fully case sensitive in ASCII range; others preserve the case of
   a newly created name but otherwise are case insensitive; and yet
   others coerce names to a particular case.  Client implementations
   must be able to interact with any of these.
   There are certain client considerations when creating a new mailbox
   name:
   1.  Any character that is one of the atom-specials (see "Formal
       Syntax" in Section 9) will require that the mailbox name be
       represented as a quoted string or literal.
   2.  CTL and other non-graphic characters are difficult to represent
       in a user interface and are best avoided.  Servers MAY refuse to
       create mailbox names containing Unicode CTL characters.
   3.  Although the list-wildcard characters ("%" and "*") are valid in
       a mailbox name, it is difficult to use such mailbox names with
       the LIST command due to the conflict with wildcard
       interpretation.
   4.  Usually, a character (determined by the server implementation) is
       reserved to delimit levels of hierarchy.
   5.  Two characters, "#" and "&", have meanings by convention and
       should be avoided except when used in that convention.  See
       Section 5.1.2.1 and Appendix A.1, respectively.
5.1.1.  Mailbox Hierarchy Naming
   If it is desired to export hierarchical mailbox names, mailbox names
   MUST be left-to-right hierarchical, using a single ASCII character to
   separate levels of hierarchy.  The same hierarchy separator character
   is used for all levels of hierarchy within a single name.
5.1.2.  Namespaces
   Personal Namespace:
      A namespace that the server considers within the personal scope of
      the authenticated user on a particular connection.  Typically,
      only the authenticated user has access to mailboxes in their
      Personal Namespace.  It is the part of the namespace that belongs
      to the user and is allocated for mailboxes.  If an INBOX exists
      for a user, it MUST appear within the user's Personal Namespace.
      In the typical case, there SHOULD be only one Personal Namespace
      per user on a server.
   Other Users' Namespace:
      A namespace that consists of mailboxes from the Personal
      Namespaces of other users.  To access mailboxes in the Other
      Users' Namespace, the currently authenticated user MUST be
      explicitly granted access rights.  For example, it is common for a
      manager to grant to their administrative support staff access
      rights to their mailbox.  In the typical case, there SHOULD be
      only one Other Users' Namespace per user on a server.
   Shared Namespace:
      A namespace that consists of mailboxes that are intended to be
      shared amongst users and do not exist within a user's Personal
      Namespace.
   The namespaces a server uses MAY differ on a per-user basis.
5.1.2.1.  Historic Mailbox Namespace Naming Convention
   By convention, the first hierarchical element of any mailbox name
   that begins with "#" identifies the "namespace" of the remainder of
   the name.  This makes it possible to disambiguate between different
   types of mailbox stores, each of which have their own namespaces.
      For example, implementations that offer access to USENET
      newsgroups MAY use the "#news" namespace to partition the USENET
      newsgroup namespace from that of other mailboxes.  Thus, the
      comp.mail.misc newsgroup would have a mailbox name of
      "#news.comp.mail.misc", and the name "comp.mail.misc" can refer to
      a different object (e.g., a user's private mailbox).
   Namespaces that include the "#" character are not IMAP URL [IMAP-URL]
   friendly and require the "#" character to be represented as %23 when
   within URLs.  As such, server implementors MAY instead consider using
   namespace prefixes that do not contain the "#" character.
5.1.2.2.  Common Namespace Models
   The previous version of this protocol did not define a default server
   namespace.  Two common namespace models have evolved:
   The "Personal Mailbox" model, in which the default namespace that is
   presented consists of only the user's personal mailboxes.  To access
   shared mailboxes, the user must use an escape mechanism to reach
   another namespace.
   The "Complete Hierarchy" model, in which the default namespace that
   is presented includes the user's personal mailboxes along with any
   other mailboxes they have access to.
5.2.  Mailbox Size and Message Status Updates
   At any time, a server can send data that the client did not request.
   Sometimes, such behavior is required by this specification and/or
   extensions.  For example, agents other than the server may add
   messages to the mailbox (e.g., new message delivery); change the
   flags of the messages in the mailbox (e.g., simultaneous access to
   the same mailbox by multiple agents); or even remove messages from
   the mailbox.  A server MUST send mailbox size updates automatically
   if a mailbox size change is observed during the processing of a
   command.  A server SHOULD send message flag updates automatically,
   without requiring the client to request such updates explicitly.
   Special rules exist for server notification of a client about the
   removal of messages to prevent synchronization errors; see the
   description of the EXPUNGE response (Section 7.5.1) for more detail.
   In particular, it is NOT permitted to send an EXISTS response that
   would reduce the number of messages in the mailbox; only the EXPUNGE
   response can do this.
   Regardless of what implementation decisions a client makes on
   remembering data from the server, a client implementation MUST
   remember mailbox size updates.  It MUST NOT assume that any command
   after the initial mailbox selection will return the size of the
   mailbox.
5.3.  Response When No Command in Progress
   Server implementations are permitted to send an untagged response
   (except for EXPUNGE) while there is no command in progress.  Server
   implementations that send such responses MUST deal with flow control
   considerations.  Specifically, they MUST either (1) verify that the
   size of the data does not exceed the underlying transport's available
   window size or (2) use non-blocking writes.
5.4.  Autologout Timer
   If a server has an inactivity autologout timer that applies to
   sessions after authentication, the duration of that timer MUST be at
   least 30 minutes.  The receipt of any command from the client during
   that interval resets the autologout timer.
   Note that this specification doesn't have any restrictions on an
   autologout timer used before successful client authentication.  In
   particular, servers are allowed to use a shortened pre-authentication
   timer to protect themselves from Denial-of-Service attacks.
5.5.  Multiple Commands in Progress (Command Pipelining)
   The client MAY send another command without waiting for the
   completion result response of a command, subject to ambiguity rules
   (see below) and flow control constraints on the underlying data
   stream.  Similarly, a server MAY begin processing another command
   before processing the current command to completion, subject to
   ambiguity rules.  However, any command continuation request responses
   and command continuations MUST be negotiated before any subsequent
   command is initiated.
   The exception is if an ambiguity would result because of a command
   that would affect the results of other commands.  If the server
   detects a possible ambiguity, it MUST execute commands to completion
   in the order given by the client.
   The most obvious example of ambiguity is when a command would affect
   the results of another command.  One example is a FETCH that would
   cause \Seen flags to be set and a SEARCH UNSEEN command.
   A non-obvious ambiguity occurs with commands that permit an untagged
   EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
   since an untagged EXPUNGE response can invalidate sequence numbers in
   a subsequent command.  This is not a problem for FETCH, STORE, or
   SEARCH commands because servers are prohibited from sending EXPUNGE
   responses while any of those commands are in progress.  Therefore, if
   the client sends any command other than FETCH, STORE, or SEARCH, it
   MUST wait for the completion result response before sending a command
   with message sequence numbers.
      Note: EXPUNGE responses are permitted while UID FETCH, UID STORE,
      and UID SEARCH are in progress.  If the client sends a UID
      command, it MUST wait for a completion result response before
      sending a command that uses message sequence numbers (this may
      include UID SEARCH).  Any message sequence numbers in an argument
      to UID SEARCH are associated with messages prior to the effect of
      any untagged EXPUNGE responses returned by the UID SEARCH.
   For example, the following non-waiting command sequences are invalid:
      FETCH + NOOP + STORE
      STORE + COPY + FETCH
      COPY + COPY
   The following are examples of valid non-waiting command sequences:
      FETCH + STORE + SEARCH + NOOP
      STORE + COPY + EXPUNGE
   UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
   command sequence, depending upon whether or not the second UID SEARCH
   contains message sequence numbers.
   Use of a SEARCH result variable (see Section 6.4.4.1) creates direct
   dependency between two commands.  See Section 6.4.4.2 for more
   considerations about pipelining such dependent commands.