Network Working Group J. G. Myers Internet-Draft A. Melnikov, Ed. Obsoletes: 2088 (if approved) Isode Ltd Intended status: Standards Track April 23, 2013 Expires: October 25, 2013 IMAP4 non-synchronizing literals draft-melnikov-rfc2088bis-00.txt Abstract The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on October 25, 2013. Copyright Notice Copyright (c) 2013 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 Myers & Melnikov Expires October 25, 2013 [Page 1]
Internet-Draft IMAP4 non-synchronizing literals April 2013 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. Table of Contents 1. Specification . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 3. Considerations on when to use and not to use synchronizing literals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 4 9. Normative References . . . . . . . . . . . . . . . . . . . . 4 Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Specification The non-synchronizing literal is added an alternate form of literal, and may appear in communication from client to server instead of the IMAP [RFC3501] form of literal. The IMAP form of literal, used in communication from client to server, is referred to as a synchronizing literal. The non-synchronizing literal form MUST NOT be sent from server to client. Non-synchronizing literals may be used with any IMAP server implementation which returns "LITERAL+" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise the LITERAL+ capability, the client must use synchronizing literals instead. The non-synchronizing literal is distinguished from the original synchronizing literal by having a plus ('+') between the octet count and the closing brace ('}'). The server does not generate a command continuation request in response to a non-synchronizing literal, and clients are not required to wait before sending the octets of a non- synchronizing literal. The protocol receiver of an IMAP server must check the end of every received line for an open brace ('{') followed by an octet count, a plus ('+'), and a close brace ('}') immediately preceeding the CRLF. If it finds this sequence, it is the octet count of a non- synchronizing literal and the server MUST treat the specified number of following octets and the following line as part of the same command. A server MAY still process commands and reject errors on a Myers & Melnikov Expires October 25, 2013 [Page 2]
Internet-Draft IMAP4 non-synchronizing literals April 2013 line-by-line basis, as long as it checks for non-synchronizing literals at the end of each line. Example: C: A001 LOGIN {11+} C: FRED FOOBAR {7+} C: fat man S: A001 OK LOGIN completed 2. Requirements Notation 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 [RFC2119]. In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. 3. Considerations on when to use and not to use synchronizing literals This section is important to understand for both client and server developers of this IMAP extension. While non-synchronizing literals have clear advantages for clients, such as simplicity of use, they might be more difficilt to handle on the server side. When a non synchronizing literal is used by a client which is too big for the server to accept, a compliant LITERAL+ server implementation has to make a choice between several non optimal choices: 1. Read the number of bytes specified in the non synchronizing literal and reject the command that included the literal anyway. (The server is allowed to send the tagged BAD/NO response before reading the whole non synchronizing literal.) This is quite wasteful on bandwidth if the literal size is big. 2. Send the untagged BYE response explaining the reason for rejecting the literal and close the connection. This will force the client to reconnect or report the error to the user. In the latter case the error is unlikely to be understandable to the user. Additionally, some naive clients are known to blindly reconnect in this case and repeat the operation that caused the problem. [[Possibly also send the ALERT response code?]] Myers & Melnikov Expires October 25, 2013 [Page 3]
Internet-Draft IMAP4 non-synchronizing literals April 2013 4. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [RFC3501]. literal = "{" number ["+"] "}" CRLF *CHAR8 ; Number represents the number of CHAR8 octets CHAR8 = <defined in RFC 3501> 5. Security Considerations This document doesn't raise any new security concerns not already raised by [RFC3501]. 6. IANA Considerations IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at: http://www.iana.org/assignments/imap4-capabilities This document requests that IANA updated the above registry to include the entry for LITERAL+ capability pointing to this document. 7. To Do Advertise a limit for APPEND command? 8. Acknowledgments 9. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003. Myers & Melnikov Expires October 25, 2013 [Page 4]
Internet-Draft IMAP4 non-synchronizing literals April 2013 Appendix A. Changes since RFC 2088 Added IANA registration. Updated references. Additional implementation considerations based on the IMAP mailing list discussions. Authors' Addresses John G. Myers Email: jgm+@cmu.edu Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com Myers & Melnikov Expires October 25, 2013 [Page 5]