Skip to main content

IMAP4 non-synchronizing literals
draft-melnikov-rfc2088bis-03

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors John G. Myers , Alexey Melnikov
Last updated 2015-03-09
Replaced by draft-ietf-imapapnd-rfc2088bis, RFC 7888
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-melnikov-rfc2088bis-03
Network Working Group                                           J. Myers
Internet-Draft
Obsoletes: 2088 (if approved)                           A. Melnikov, Ed.
Intended status: Standards Track                               Isode Ltd
Expires: September 10, 2015                                March 9, 2015

                    IMAP4 non-synchronizing literals
                    draft-melnikov-rfc2088bis-03.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.

   This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
   The former allows the alternate form of literals in all IMAP command.
   The latter is the same as LITERAL+, but disallow the alternate form
   in IMAP APPEND.

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 September 10, 2015.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Myers & Melnikov       Expires September 10, 2015               [Page 1]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

   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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1.  Specification . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Considerations on when to use and not to use synchronizing
       literals  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  LITERAL- capability . . . . . . . . . . . . . . . . . . . . .   4
   5.  Interaction with BINARY extension . . . . . . . . . . . . . .   5
   6.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     11.2.  Informative References . . . . . . . . . . . . . . . . .   6
   Appendix A.  Changes since RFC 2088 . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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

Myers & Melnikov       Expires September 10, 2015               [Page 2]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

   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+" or "LITERAL-" as one of the
   supported capabilities to the CAPABILITY command.  If the server does
   not advertise either of the above capabilities, the client must use
   synchronizing literals instead.  The difference between "LITERAL+"
   and "LITERAL-" extensions is explained in Section 4.

   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
   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.

Myers & Melnikov       Expires September 10, 2015               [Page 3]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

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.  [[CREF1: Possibly also send the ALERT response code?]]

   The situation can be improved by implementing support for the
   APPENDLIMIT extension [I-D.jayantheesh-imap-appendlimit-extension],
   which allows a server to advertise its APPEND limit, so that well
   behaved clients can check it and avoid uploading big messages in the
   first place.

   The problem described above is most common when using the APPEND
   command, because most of commands don't need to send lots of data
   from the client to the server.  Some server implementations impose
   limits on literal (both synchronizing and non synchronizing) accepted
   from clients in order to protect from Denial Of Service attacks.
   Implementations can generally impose much lower limits on literal
   sizes for all commands other than APPEND.  In order to address
   literal size issue in APPEND, this document introduces a new
   extension "LITERAL-", described in Section 4.

4.  LITERAL- capability

   "LITERAL-" extension is almost identical to "LITERAL+", with one
   exception: when "LITERAL-" is advertised, non synchronizing literals
   used in APPEND (and extensions to APPEND such as MULTIAPPEND
   [RFC3502] and CATENATE [RFC4469]) MUST NOT be bigger than 4096 bytes.

Myers & Melnikov       Expires September 10, 2015               [Page 4]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

   When any literal used in APPEND is larger than 4096, RFC 3501
   synchronizing literals MUST be used instead.  A "LITERAL-" compliant
   server which encounters a non synchronizing literal in APPEND larget
   than 4096 bytes MUST reject such APPEND command with a tagged BAD
   response.

   Because "LITERAL-" is a more restricted version of "LITERAL+", IMAP
   servers MUST NOT advertise both of these capabilities at the same
   time.  (A server implementation can choose to have a configuration
   option to pick which one to advertise.)

5.  Interaction with BINARY extension

   RFC 4466 [RFC4466] updated the non-terminal "literal8" defined in
   [RFC3516] to allow for non-synchronizing literals if both [RFC3516]
   and "LITERAL+" (or "LITERAL-") extensions are supported by the
   server.

6.  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>

     literal8 = <defined in RFC 4466>

7.  Security Considerations

   This document doesn't raise any new security concerns not already
   raised by [RFC3501].

8.  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/imap-capabilities

   This document requests that IANA updated the above registry to
   include the entry for LITERAL+ capability pointing to this document.

Myers & Melnikov       Expires September 10, 2015               [Page 5]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

   This document also requests that IANA adds "LITERAL-" capability
   pointing to this document to the above registry.

9.  To Do

   Reference draft-jayantheesh-imap-appendlimit-extension which allows
   advertising limits for the APPEND command.

10.  Acknowledgments

   TBD

11.  References

11.1.  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.

   [RFC3516]  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              April 2003.

   [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
              ABNF", RFC 4466, April 2006.

11.2.  Informative References

   [I-D.jayantheesh-imap-appendlimit-extension]
              Bisht, N., "The IMAP APPENDLIMIT Extension", draft-
              jayantheesh-imap-appendlimit-extension-04 (work in
              progress), February 2015.

   [RFC3502]  Crispin, M., "Internet Message Access Protocol (IMAP) -
              MULTIAPPEND Extension", RFC 3502, March 2003.

   [RFC4469]  Resnick, P., "Internet Message Access Protocol (IMAP)
              CATENATE Extension", RFC 4469, April 2006.

Myers & Melnikov       Expires September 10, 2015               [Page 6]
Internet-Draft      IMAP4 non-synchronizing literals          March 2015

Appendix A.  Changes since RFC 2088

   Added IANA registration.

   Updated references.  Also updated considerations about interactions
   of IMAP extensions.

   Additional implementation considerations based on the IMAP mailing
   list discussions.

   LITERAL- capability description.

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 September 10, 2015               [Page 7]