5. Operational Considerations
5.1. Mailbox Naming
The interpretation of mailbox names is implementation-dependent.
However, the case-insensitive mailbox name INBOX is a special name
reserved to mean "the primary mailbox for this user on this server".
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 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. Mailbox Namespace Naming Convention
By convention, the first hierarchical element of any mailbox name
which 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 which 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 an mailbox name of
"#news.comp.mail.misc", and the name "comp.mail.misc" could refer
to a different object (e.g. a user's private mailbox).
5.1.3. Mailbox International Naming Convention
By convention, international mailbox names are specified using a
modified version of the UTF-7 encoding described in [UTF-7]. The
purpose of these modifications is to correct the following problems
with UTF-7:
1) UTF-7 uses the "+" character for shifting; this conflicts with
the common use of "+" in mailbox names, in particular USENET
newsgroup names.
2) UTF-7's encoding is BASE64 which uses the "/" character; this
conflicts with the use of "/" as a popular hierarchy delimiter.
3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
the use of "\" as a popular hierarchy delimiter.
4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
the use of "~" in some servers as a home directory indicator.
5) UTF-7 permits multiple alternate forms to represent the same
string; in particular, printable US-ASCII chararacters can be
represented in encoded form.
In modified UTF-7, printable US-ASCII characters except for "&"
represent themselves; that is, characters with octet values 0x20-0x25
and 0x27-0x7e. The character "&" (0x26) is represented by the two-
octet sequence "&-".
All other characters (octet values 0x00-0x1f, 0x7f-0xff, and all
Unicode 16-bit octets) are represented in modified BASE64, with a
further modification from [UTF-7] that "," is used instead of "/".
Modified BASE64 MUST NOT be used to represent any printing US-ASCII
character which can represent itself.
"&" is used to shift to modified BASE64 and "-" to shift back to US-
ASCII. All names start in US-ASCII, and MUST end in US-ASCII (that
is, a name that ends with a Unicode 16-bit octet MUST end with a "-
").
For example, here is a mailbox name which mixes English, Japanese,
and Chinese text: ~peter/mail/&ZeVnLIqe-/&U,BTFw-
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. For example, agents other than
the server MAY add messages to the mailbox (e.g. new mail delivery),
change the flags of message 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
Regardless of what implementation decisions a client makes on
remembering data from the server, a client implementation MUST record
mailbox size updates. It MUST NOT assume that any command after
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 timer MUST be of
at least 30 minutes' duration. The receipt of ANY command from the
client during that interval SHOULD suffice to reset the autologout
timer.
5.5. Multiple Commands in Progress
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. Clients MUST NOT
send multiple commands without waiting if an ambiguity would result.
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; for example, a FETCH of a message's
flags and a STORE of that same message's flags.
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 a response before sending a command with message
sequence numbers.
For example, the following non-waiting command sequences are invalid:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
The following are examples of valid non-waiting command sequences:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
|
