rfc2088.txt (4052B)
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 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