imap/docs/rfc/rfc2088.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           J. Myers
   8 Request for Comments: 2088                               Carnegie Mellon
   9 Cateogry: Standards Track                                   January 1997
  10
  11
  12                     IMAP4 non-synchronizing literals
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 1.   Abstract
  23
  24    The Internet Message Access Protocol [IMAP4] contains the "literal"
  25    syntactic construct for communicating strings.  When sending a
  26    literal from client to server, IMAP4 requires the client to wait for
  27    the server to send a command continuation request between sending the
  28    octet count and the string data.  This document specifies an
  29    alternate form of literal which does not require this network round
  30    trip.
  31
  32 2.   Conventions Used in this Document
  33
  34    In examples, "C:" and "S:" indicate lines sent by the client and
  35    server respectively.
  36
  37 3.   Specification
  38
  39    The non-synchronizing literal is added an alternate form of literal,
  40    and may appear in communication from client to server instead of the
  41    IMAP4 form of literal.  The IMAP4 form of literal, used in
  42    communication from client to server, is referred to as a
  43    synchronizing literal.
  44
  45    Non-synchronizing literals may be used with any IMAP4 server
  46    implementation which returns "LITERAL+" as one of the supported
  47    capabilities to the CAPABILITY command.  If the server does not
  48    advertise the LITERAL+ capability, the client must use synchronizing
  49    literals instead.
  50
  51    The non-synchronizing literal is distinguished from the original
  52    synchronizing literal by having a plus ('+') between the octet count
  53    and the closing brace ('}').  The server does not generate a command
  54    continuation request in response to a non-synchronizing literal, and
  55
  56
  57
  58 Myers                       Standards Track                     [Page 1]
  59 \f
  60 RFC 2088                        LITERAL                     January 1997
  61
  62
  63    clients are not required to wait before sending the octets of a non-
  64    synchronizing literal.
  65
  66    The protocol receiver of an IMAP4 server must check the end of every
  67    received line for an open brace ('{') followed by an octet count, a
  68    plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
  69    If it finds this sequence, it is the octet count of a non-
  70    synchronizing literal and the server MUST treat the specified number
  71    of following octets and the following line as part of the same
  72    command.  A server MAY still process commands and reject errors on a
  73    line-by-line basis, as long as it checks for non-synchronizing
  74    literals at the end of each line.
  75
  76    Example:    C: A001 LOGIN {11+}
  77                C: FRED FOOBAR {7+}
  78                C: fat man
  79                S: A001 OK LOGIN completed
  80
  81 4.   Formal Syntax
  82
  83    The following syntax specification uses the augmented Backus-Naur
  84    Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
  85    Non-terminals referenced but not defined below are as defined by
  86    [IMAP4].
  87
  88    literal         ::= "{" number ["+"] "}" CRLF *CHAR8
  89                        ;; Number represents the number of CHAR8 octets
  90
  91 6.   References
  92
  93    [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
  94    draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
  95
  96    [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
  97    Messages", STD 11, RFC 822.
  98
  99 7.   Security Considerations
 100
 101    There are no known security issues with this extension.
 102
 103 8.   Author's Address
 104
 105    John G. Myers
 106    Carnegie-Mellon University
 107    5000 Forbes Ave.
 108    Pittsburgh PA, 15213-3890
 109
 110    Email: jgm+@cmu.edu
 111
 112
 113
 114 Myers                       Standards Track                     [Page 2]
 115 \f