idnits 2.17.1 draft-myers-imap-literal-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 74: '...l and the server MUST treat the specif...' RFC 2119 keyword, line 76: '...mmand. A server MAY still process com...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1996) is 10147 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IMAP4' on line 98 looks like a reference -- Missing reference section? 'RFC-822' on line 101 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft Carnegie Mellon 4 Document: draft-myers-imap-literal-00.txt July 1996 6 IMAP4 non-synchroniziong literals 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``work in progress''. 21 To learn the current status of any Internet-Draft, please check the 22 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 A revised version of this draft document will be submitted to the RFC 27 editor as a Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested. This document will 29 expire before December 1996. Distribution of this draft is 30 unlimited. 32 1. Abstract 34 The Internet Message Access Protocol [IMAP4] contains the ``literal'' 35 syntactic construct for communicating strings. When sending a 36 literal from client to server, IMAP4 requires the client to wait for 37 the server to send a command continuation request between sending the 38 octet count and the string data. This document specifies an 39 alternate form of literal which does not require this network round 40 trip. 42 2. Conventions Used in this Document 44 In examples, "C:" and "S:" indicate lines sent by the client and 45 server respectively. 47 Internet DRAFT LITERAL July 9, 1996 49 3. Specification 51 The non-synchronizing literal is added an alternate form of literal, 52 and may appear in communication from client to server instead of the 53 IMAP4 form of literal. The IMAP4 form of literal, used in 54 communication from client to server, is referred to as a 55 synchronizing literal. 57 Non-synchroniziong literals may be used with any IMAP4 server 58 implementation which returns "LITERAL+" as one of the supported 59 capabilities to the CAPABILITY command. If the server does not 60 advertise the LITERAL+ capability, the client must use synchronizing 61 literals instead. 63 The non-syncronizing literal is distinguished from the original 64 synchronizing literal by having a plus ('+') between the octet count 65 and the closing brace ('}'). The server does not generate a command 66 continuation request in response to a non-syncronizing literal, and 67 clients are not required to wait before sending the octets of a non- 68 syncronizing literal. 70 The protocol receiver of an IMAP4 server must check the end of every 71 received line for an open brace ('{') followed by an octet count, a 72 plus ('+'), and a close brace ('}') immediately preceeding the CRLF. 73 If it finds this sequence, it is the octet count of a non- 74 synchronizing literal and the server MUST treat the specified number 75 of following octets and the following line as part of the same 76 command. A server MAY still process commands and reject errors on a 77 line-by-line basis, as long as it checks for non-synchronizing 78 literals at the end of each line. 80 Example: C: A001 LOGIN {11+} 81 C: FRED FOOBAR {7+} 82 C: fat man 83 S: A001 OK LOGIN completed 85 4. Formal Syntax 87 The following syntax specification uses the augmented Backus-Naur 88 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 89 Non-terminals referenced but not defined below are as defined by 90 [IMAP4]. 92 literal ::= "{" number ["+"] "}" CRLF *CHAR8 93 ;; Number represents the number of CHAR8 octets 94 Internet DRAFT LITERAL July 9, 1996 96 6. References 98 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 99 draft-crispin-imap-base-XX.txt, University of Washington, April 1996. 101 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 102 Messages", STD 11, RFC 822. 104 7. Security Considerations 106 There are no known security issues with this extension. 108 8. Author's Address 110 John G. Myers 111 Carnegie-Mellon University 112 5000 Forbes Ave. 113 Pittsburgh PA, 15213-3890 115 Email: jgm+@cmu.edu