/opt/cpanel/ea-libc-client/share/docs/rfc
NameSizeModeActions
README23370644editdlrm
rfc1732.txt92760644editdlrm
rfc1733.txt62050644editdlrm
rfc2061.txt58670644editdlrm
rfc2062.txt140420644editdlrm
rfc2087.txt85420644editdlrm
rfc2088.txt40520644editdlrm
rfc2177.txt67700644editdlrm
rfc2180.txt247500644editdlrm
rfc2193.txt162480644editdlrm
rfc2195.txt104680644editdlrm
rfc2221.txt92510644editdlrm
rfc2342.txt194890644editdlrm
rfc2683.txt563000644editdlrm
rfc2971.txt146700644editdlrm
rfc3348.txt118680644editdlrm
rfc3501.txt2276380644editdlrm
rfc3502.txt133790644editdlrm
rfc3503.txt169370644editdlrm
rfc3516.txt145980644editdlrm
rfc3656.txt355090644editdlrm
rfc3691.txt84360644editdlrm
rfc4314.txt565990644editdlrm
rfc4315.txt166290644editdlrm
rfc4422.txt732060644editdlrm
rfc4466.txt337520644editdlrm
rfc4467.txt367140644editdlrm
rfc4468.txt286140644editdlrm
rfc4469.txt218220644editdlrm
rfc4505.txt165990644editdlrm
rfc4549.txt754170644editdlrm
rfc4551.txt502650644editdlrm
rfc4616.txt202700644editdlrm
rfc4731.txt154310644editdlrm
rfc4752.txt221330644editdlrm
rfc4790.txt555910644editdlrm
rfc4959.txt122840644editdlrm
rfc4978.txt175540644editdlrm
rfc5032.txt89210644editdlrm
rfc5051.txt149650644editdlrm
rfc5092.txt651970644editdlrm
rfc5161.txt122200644editdlrm
rfc5162.txt516200644editdlrm
rfc5234.txt263590644editdlrm
Edit: /opt/cpanel/ea-libc-client/share/docs/rfc/rfc2088.txt (4052B)
Network Working Group J. Myers Request for Comments: 2088 Carnegie Mellon Cateogry: Standards Track January 1997 IMAP4 non-synchronizing literals Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 1. Abstract The Internet Message Access Protocol [IMAP4] contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP4 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. 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 3. Specification The non-synchronizing literal is added an alternate form of literal, and may appear in communication from client to server instead of the IMAP4 form of literal. The IMAP4 form of literal, used in communication from client to server, is referred to as a synchronizing literal. Non-synchronizing literals may be used with any IMAP4 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 Myers Standards Track [Page 1] RFC 2088 LITERAL January 1997 clients are not required to wait before sending the octets of a non- synchronizing literal. The protocol receiver of an IMAP4 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 4. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. Non-terminals referenced but not defined below are as defined by [IMAP4]. literal ::= "{" number ["+"] "}" CRLF *CHAR8 ;; Number represents the number of CHAR8 octets 6. References [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", draft-crispin-imap-base-XX.txt, University of Washington, April 1996. [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822. 7. Security Considerations There are no known security issues with this extension. 8. Author's Address John G. Myers Carnegie-Mellon University 5000 Forbes Ave. Pittsburgh PA, 15213-3890 Email: jgm+@cmu.edu Myers Standards Track [Page 2]