rfc2088.txt
上传用户:ycwykj01
上传日期:2007-01-04
资源大小:1819k
文件大小:4k
源码类别:

网络编程

开发平台:

Unix_Linux

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