Skip to main content

IMAP Response Codes
RFC 5530

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>
Subject: Protocol Action: 'IMAP Response Codes' to Proposed 

The IESG has approved the following document:

- 'IMAP Response Codes '
   <draft-gulbrandsen-imap-response-codes-07.txt> as a Proposed Standard

This document has been reviewed in the IETF but is not the product of an
IETF Working Group. 

The IESG contact person is Chris Newman.

A URL of this Internet-Draft is:

Ballot Text

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.


  Alexey Melnikov <> is the document shepherd
  for this document.  Chris Newman has reviewed this document for the

Note to RFC Editor

Add to the list in section 6:
 NOTSAVED             RFC 5182
 ANNOTATIONS          RFC 5257
 TEMPFAIL             RFC 5259
 NOUPDATE             RFC 5267
 BADEVENT             RFC 5465
 NEWNAME              RFC 2060 (obsolete)

IANA Considerations:
  The new registry should only be extended by publishing an RFC. The
  IANA may to add placeholders for internet-drafts at its discretion.
 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
 <> (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

 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.


  Arnt Gulbrandsen will be the designated expert.

RFC Editor Note