Technical Summary
IMAP responses consist of a response type (OK, NO, BAD), an optional
machine-readable response code and a human-readable text.
This document collects and documents a variety of machine-readable
response codes, for better interoperation and error reporting.
Working Group Summary
This is not a WG document.
Nothing worth reporting.
Document Quality
The document was extensively reviewed by both IMAP client and
server implementors. There are already several implementations
of this document.
At least 10 people have reviewed the document. Majority of posted
comments were addressed in the latest revision.
Personnel
Alexey Melnikov <alexey.melnikov@isode.com> is the document shepherd
for this document. Chris Newman has reviewed this document for the
IESG.
Note to RFC Editor
Add to the list in section 6:
NOTSAVED RFC 5182
ANNOTATIONS RFC 5257
TEMPFAIL RFC 5259
MAXCONVERTMESSAGES RFC 5259
MAXCONVERTPARTS RFC 5259
NOUPDATE RFC 5267
NOTIFICATIONOVERFLOW RFC 5465
BADEVENT RFC 5465
UNDEFINED-FILTER RFC 5466
NEWNAME RFC 2060 (obsolete)
IANA Considerations:
OLD:
The new registry should only be extended by publishing an RFC. The
IANA may to add placeholders for internet-drafts at its discretion.
NEW:
The new registry can be extended by sending a registration request
to IANA. IANA will forward this request to a Designated Expert,
appointed by the responsible IESG area
director, CCing it to the IMAP Extensions mailing list
<ietf-imapext@imc.org> (or a successor designated by the Area
Director). After allowing 30 days for community input on
the IMAP Extensions Mailing list or a successful IETF Last Call,
the expert will determine
the appropriateness of the registration request and either approve
or disapprove the request, by sending a notice of the decision to
the requestor, CCing the IMAP Extensions mailing list and IANA.
A denial notice must be justified by an explanation, and in
the cases where it is possible, concrete suggestions on how
the request can be modified so as to become acceptable should be
provided.
For each response code the registry contains a list of relevant
RFCs that describe (or extend) the response code and an optional
response code status description, such as "obsolete" or
"reserved to prevent collision with deployed software".
(Note that in the latter case the RFC number can be missing).
Presence of the response code status description means that the
corresponding response code is NOT RECOMMENDED for widespread use.
The intention is that any future allocation will be accompanied
by a published RFC (including direct submissions to RFC editor).
But in order to allow for the allocation of values prior to the
RFC being approved for publication, the Designated Expert can
approve allocations once it seems clear that an RFC will be
published, for example before requesting IETF LC for the document.
The Designated Expert can also approve registrations for response
codes used in deployed software when no RFC exists. Such
registrations must be marked as "reserved to prevent collision
with deployed software".
Response code registrations may not be deleted; response codes
that are no longer believed appropriate for use (for example
if there is a problem with syntax of such response code, or
the specification describing it was moved to Historic)
should be marked "obsolete" in the registry clearly marked in
the lists published by IANA.
IANA Note
Arnt Gulbrandsen will be the designated expert.