imapext-2007

diff docs/rfc/rfc2088.txt @ 0:ada5e610ab86

imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
line diff
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc2088.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,115 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                           J. Myers
    1.11 +Request for Comments: 2088                               Carnegie Mellon
    1.12 +Cateogry: Standards Track                                   January 1997
    1.13 +
    1.14 +
    1.15 +                    IMAP4 non-synchronizing literals
    1.16 +
    1.17 +Status of this Memo
    1.18 +
    1.19 +   This document specifies an Internet standards track protocol for the
    1.20 +   Internet community, and requests discussion and suggestions for
    1.21 +   improvements.  Please refer to the current edition of the "Internet
    1.22 +   Official Protocol Standards" (STD 1) for the standardization state
    1.23 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.24 +
    1.25 +1.   Abstract
    1.26 +
    1.27 +   The Internet Message Access Protocol [IMAP4] contains the "literal"
    1.28 +   syntactic construct for communicating strings.  When sending a
    1.29 +   literal from client to server, IMAP4 requires the client to wait for
    1.30 +   the server to send a command continuation request between sending the
    1.31 +   octet count and the string data.  This document specifies an
    1.32 +   alternate form of literal which does not require this network round
    1.33 +   trip.
    1.34 +
    1.35 +2.   Conventions Used in this Document
    1.36 +
    1.37 +   In examples, "C:" and "S:" indicate lines sent by the client and
    1.38 +   server respectively.
    1.39 +
    1.40 +3.   Specification
    1.41 +
    1.42 +   The non-synchronizing literal is added an alternate form of literal,
    1.43 +   and may appear in communication from client to server instead of the
    1.44 +   IMAP4 form of literal.  The IMAP4 form of literal, used in
    1.45 +   communication from client to server, is referred to as a
    1.46 +   synchronizing literal.
    1.47 +
    1.48 +   Non-synchronizing literals may be used with any IMAP4 server
    1.49 +   implementation which returns "LITERAL+" as one of the supported
    1.50 +   capabilities to the CAPABILITY command.  If the server does not
    1.51 +   advertise the LITERAL+ capability, the client must use synchronizing
    1.52 +   literals instead.
    1.53 +
    1.54 +   The non-synchronizing literal is distinguished from the original
    1.55 +   synchronizing literal by having a plus ('+') between the octet count
    1.56 +   and the closing brace ('}').  The server does not generate a command
    1.57 +   continuation request in response to a non-synchronizing literal, and
    1.58 +
    1.59 +
    1.60 +
    1.61 +Myers                       Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 2088                        LITERAL                     January 1997
    1.64 +
    1.65 +
    1.66 +   clients are not required to wait before sending the octets of a non-
    1.67 +   synchronizing literal.
    1.68 +
    1.69 +   The protocol receiver of an IMAP4 server must check the end of every
    1.70 +   received line for an open brace ('{') followed by an octet count, a
    1.71 +   plus ('+'), and a close brace ('}') immediately preceeding the CRLF.
    1.72 +   If it finds this sequence, it is the octet count of a non-
    1.73 +   synchronizing literal and the server MUST treat the specified number
    1.74 +   of following octets and the following line as part of the same
    1.75 +   command.  A server MAY still process commands and reject errors on a
    1.76 +   line-by-line basis, as long as it checks for non-synchronizing
    1.77 +   literals at the end of each line.
    1.78 +
    1.79 +   Example:    C: A001 LOGIN {11+}
    1.80 +               C: FRED FOOBAR {7+}
    1.81 +               C: fat man
    1.82 +               S: A001 OK LOGIN completed
    1.83 +
    1.84 +4.   Formal Syntax
    1.85 +
    1.86 +   The following syntax specification uses the augmented Backus-Naur
    1.87 +   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
    1.88 +   Non-terminals referenced but not defined below are as defined by
    1.89 +   [IMAP4].
    1.90 +
    1.91 +   literal         ::= "{" number ["+"] "}" CRLF *CHAR8
    1.92 +                       ;; Number represents the number of CHAR8 octets
    1.93 +
    1.94 +6.   References
    1.95 +
    1.96 +   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
    1.97 +   draft-crispin-imap-base-XX.txt, University of Washington, April 1996.
    1.98 +
    1.99 +   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   1.100 +   Messages", STD 11, RFC 822.
   1.101 +
   1.102 +7.   Security Considerations
   1.103 +
   1.104 +   There are no known security issues with this extension.
   1.105 +
   1.106 +8.   Author's Address
   1.107 +
   1.108 +   John G. Myers
   1.109 +   Carnegie-Mellon University
   1.110 +   5000 Forbes Ave.
   1.111 +   Pittsburgh PA, 15213-3890
   1.112 +
   1.113 +   Email: jgm+@cmu.edu
   1.114 +
   1.115 +
   1.116 +
   1.117 +Myers                       Standards Track                     [Page 2]
   1.118 +

UW-IMAP'd extensions by yuuji