INTERNET-DRAFT M. Yevstifeyev Intended Status: Standards Track August 8, 2011 Expires: February 9, 2012 Post Office Protocol (POP) WRONG-STATE Response Code draft-yevstifeyev-pop-wrong-state-01 Abstract This document defines new POP response code to be used in responses to commands which mismatch the state they were given in. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Yevstifeyev Expires February 9, 2012 [Page 1] INTERNET DRAFT POP WRONG-STATE Response Code August 8, 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Response Code Definition . . . . . . . . . . . . . . . . . . . 2 2.1. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . 3 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 5. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 4 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction Post Office Protocol (POP), defined in RFC 1939 [RFC1939], is an application-layer protocol used by local e-mail clients to retrieve e-mail from a remote server over a simple TCP/IP connection. It uses the concept of states, which make management of the transaction easier; certain POP commands may only be given in the particular state. RFC 2449 [RFC2449] defines a way to extend Post Office Protocol (POP) [RFC1939] responses with additional information concerning details of processing some POP command. The mechanism was named extended POP response codes; the extended POP response, additionally to status indicator, contains the response code, which concretize the reason for giving particular response. Refer to Section 8 of RFC 2449 for further description. This document proposes new POP response code - WRONG-STATE - which is intended to be used in -ERR responses to commands given in the wrong state, e.g. STAT command given in the AUTHORIZATION state. The new response code is also capable of carrying the information regarding the current state of server. 1.1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The reader is supposed to be acquainted with RFC 1939 [RFC1939]. 2. Response Code Definition The new POP response code is defined. The name for the new response code is "WRONG-STATE". Yevstifeyev Expires February 9, 2012 [Page 2] INTERNET DRAFT POP WRONG-STATE Response Code August 8, 2011 The WRONG-STATE response code SHOULD occur in the -ERR response returned to the command given in the wrong state, if such restriction takes places. The WRONG-STATE response code MUST NOT be present in the +OK responses. The hierarchy is defined as follows. The second-level element in the WRONG-STATE response code is the current state of the server. The possible options of the server's state are "AUTHORIZATION", "TRANSACTION" and "UPDATE". The second-level element is RECOMMENDED (but not required) in the WRONG-STATE response code. The example of use of WRONG-STATE response code is given below. C: S: +OK CoolPOP Server Ready C: STAT S: -ERR [WRONG-STATE/AUTHORIZATION] Not in TRANSACTION state yet If the client's state is different from the server's one, it SHOULD be changed according to WRONG-STATE response. The client SHALL ignore the second-level element of the response code if it contains the illegal state name, e. g. [WRONG-STATE/CONNECTION]. Those servers which support WRONG-STATE response code MUST implement and advertise RESP-CODES POP capability [RFC2449]. 2.1. Formal Syntax The WRONG-STATE response code is defined using ABNF [RFC5234] in the production below. wrong-state-resp = "[" "WRONG-STATE" [ second-level ] "]" second-level = "/" server-state server-state = "AUTHORIZATION" / "TRANSACTION" / "UPDATE" The production is intended to be used in position of RFC 2449 . 3. Security Considerations The new POP response code is not believed to raise any new security considerations. 4. IANA Considerations IANA is asked to register the new WRONG-STATE POP response code in the corresponding IANA registry with reference to this document. Yevstifeyev Expires February 9, 2012 [Page 3] INTERNET DRAFT POP WRONG-STATE Response Code August 8, 2011 5. Normative References [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2449] Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension Mechanism", RFC 2449, November 1998. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Appendix A. Acknowledgments Thanks to Chris Newman for his input to this document. Author's Addresses Mykyta Yevstifeyev 8 Kuzovkov St., Apt. 25 Kotovsk Ukraine EMail: evnikita2@gmail.com Yevstifeyev Expires February 9, 2012 [Page 4]