idnits 2.17.00 (12 Aug 2021) /tmp/idnits61710/draft-nerenberg-imap-channel-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 (2022-05-20) 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) 2022 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 4 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 17 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (February 2001) is 7764 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) -- Looks like a reference, but probably isn't: '2' on line 132 -- Looks like a reference, but probably isn't: '1' on line 133 -- Looks like a reference, but probably isn't: '9' on line 138 ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hole 3 Internet Draft: IMAP4 Channel Transport Mechanism L. Nerenberg 4 Document: draft-nerenberg-imap-channel-00.txt ACI/Messagingdirect 5 B. Leiba 6 IBM Research 7 February 2001 9 IMAP4 Channel Transport Mechanism 11 Status of this memo 13 This document is an Internet Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet 19 Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet Drafts 24 as reference material or to cite them other than as "work in 25 progress.rq 27 The list of current Internet Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 A revised version of this draft document will be submitted to the 34 RFC editor as a Proposed Standard for the Internet Community. 35 Discussion and suggestions for improvement are requested. 36 Distribution of this draft is unlimited. 38 0. Administrivia 40 Lines prefixed with ">>>" are meta-comments. 42 1. Abstract 44 IMAP4 is being used to serve rich media content in environments 45 that extend beyond traditional text-based e-mail. One example is a 46 cellular telephone that can retrieve and send MIME-encoded audio 47 data through IMAP4. While this type of content can be exchanged 48 natively using IMAP4, some applications will work better if the 49 message content can be manipulated using schemes external to the 50 IMAP4 connection. In our cellular telephone example, it might be 51 preferable for the telephone client to retrieve the audio data 52 using RTSP. This specifications defines a mechanism for an IMAP4 53 client to request message content from a server through an external 54 scheme. 56 2. Conventions Used in this Document 58 The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" 59 in this document are to be interpreted as described in [KEYWORD]. 61 In examples, "C:" and "S:" preface lines sent by the client and the 62 server respectively. 64 3. Overview 66 4. Protocol Framework 68 This memo defines the following extensions to [IMAP4]. 70 4.1. CAPABILITY Identification 72 IMAP4 servers that support this extension MUST include a CHANNEL 73 capability response in the response list to the CAPABILITY command. 74 This entry indicates the server supports the extension, and lists 75 the external schemes available to the CHANNEL command. The capabil- 76 ity response consists of the string "CHANNEL=" followed by a comma- 77 seperated list of CHANNEL services. 79 >>> e.g. CHANNEL=rtsp,imap 80 >>> 81 >>> Is this comma-list syntax going to mess things up for 82 >>> parsers? We prefer it because it's more compact than 83 >>> CHANNEL=rtsp CHANNEL=imap (AUTH-style lists). 85 4.2. CHANNEL Command 87 The CHANNEL command requests that message data be retrieved through 88 an external scheme. The scheme is specified using a URI [URI]. 89 Clients may issue a partially-qualified URI, in which case the 90 server will determine the final connection end-point. What consti- 91 tutes a partially-qualified URI is implementation defined, however 92 every URI MUST contain at least a scheme. 94 The syntax of the CHANNEL command is: 96 tag CHANNEL uri_list msg_set 98 uri_list is a list of URIs specifying the locations where the 99 client is willing to retrieve the message data. If the list con- 100 tains more than one element the server must enumerate the list in 101 order and SHOULD return the message data via the first URI it is 102 capable of using. 104 >>> the intent is that the client can indicate a list of 105 >>> services in descending order of usefulness/quality. 107 >>> Also, there is no guarantee that a server can express 108 >>> a particular body section through all of its advertised 109 >>> schemes, thus the list provides fallback for the server 110 >>> as well as the client. 112 msg_set is a list of messages and body sections to be retrieved 113 through the specified URI. 115 >>> example syntax: 116 >>> 117 >>> 0 CHANNEL ("rtsp:" "imap:") (1 (body[2])) (3 (body[1] body[9])) 118 >>> 119 >>> asks for section 2 of message 1 and section 1 of message 120 >>> 3 via RTSP. If RTSP isn't available/usable, try IMAP. In 121 >>> either case, the server will fill in the connection end-point 122 >>> information. 124 4.3. CHANNEL Response 126 The CHANNEL response returns connection status and location infor- 127 mation to the client. One untagged response is returned for each 128 body section requested. 130 >>> example response to above command: 131 >>> 132 >>> S: * 1 CHANNEL ((body[2]) "rtsp://example.com/1441243") 133 >>> S: * 3 CHANNEL ((body[1]) 134 >>> S: "imap://user@imap.example.com:/inbox;uidvalidity=2/;uid=33") 135 >>> S: * 3 CHANNEL ((body[9]) NIL) 136 >>> S: 0 OK done 137 >>> 138 >>> The NIL response to the body[9] indicates that the part could not 139 >>> be retrieved via either of the requested schemes. This could 140 >>> be caused by the inability to convert or represent the content 141 >>> through the schemes, or because some resource was unavailable. 143 5. Formal Protocol Syntax 145 The following syntax specification uses the augmented Backus-Naur 146 Form (BNF) notation as used in [IMAP4]. 148 Except as noted otherwise, all alphabetic characters are case- 149 insensitive. The use of upper or lower case characters to define 150 token strings is for editorial clarity only. Implementations MUST 151 accept these strings in a case-insensitive fashion. 153 This syntax extends the grammar specified in [IMAP4]. 155 >>> TO BE DONE 157 6. References 159 [IMAP4] Crispin, M., "Internet Message Access Protocol Version 160 4rev1," RFC2060, University of Washington, December 1996 162 [URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): 163 Generic Syntax," RFC2396, August 1998 165 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 166 Requirement Levels," BCP 9, RFC2119, March 1997 168 7. Security Considerations 170 8. Authors' Addresses 172 Lyndon Nerenberg Steve Hole 173 ACI/MessagingDirect ACI/MessagingDirect 174 Suite 900 Suite 900 175 10117 - Jasper Avenue 10117 - Jasper Avenue 176 Edmonton, Alberta Edmonton, Alberta 177 Canada T5J 1W8 Canada T5J 1W8 179 181 Barry Leiba 182 IBM T.J. Watson Research Center 183 30 Saw Mill River Road 184 Hawthorne, NY 10532 185 187 Phone: +1 914 784 7941