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: http://www.ietf.org/internet-drafts/draft-gulbrandsen-imap-response-codes-07.txt 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. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
