idnits 2.17.00 (12 Aug 2021) /tmp/idnits62735/draft-nerenberg-imap-channel-01.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 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 2 characters in excess of 72. ** 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 75: '...t this extension MUST include a CHANNE...' RFC 2119 keyword, line 88: '...owever every URI MUST contain at least...' RFC 2119 keyword, line 96: '...te the list in order and SHOULD return...' RFC 2119 keyword, line 138: '... The server MUST NOT issue an unta...' 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 (November 2001) is 7491 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? 'KEYWORD' on line 178 looks like a reference -- Missing reference section? 'IMAP4rev1' on line 175 looks like a reference -- Missing reference section? 'ABNF' on line 172 looks like a reference -- Missing reference section? 'URI' on line 181 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 6 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-01.txt ACI Worldwide 5 B. Leiba 6 IBM Research 7 November 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 docu- 23 ments at any time. It is inappropriate to use Internet Drafts as 24 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. Dis- 35 cussion and suggestions for improvement are requested. Distribu- 36 tion of this draft is unlimited. 38 0. Administrivia 40 Lines prefixed with ">>>" are meta-comments and will not appear in the 41 final document. 43 Discussion concerning this draft should be directed to the 44 mailing list. (To subscribe: echo subscribe | 45 mail ietf-imap-voice-request@imc.org) 47 1. Abstract 49 IMAP4 is being used to serve rich media content in environments 50 that extend beyond traditional text-based e-mail. One example is a 51 cellular telephone that can retrieve and send MIME-encoded audio 52 data through IMAP4. While this type of content can be exchanged 53 natively using IMAP4, some applications will work better if the 54 message content can be manipulated using schemes external to the 55 IMAP4 connection. In our cellular telephone example, it might be 56 preferable for the telephone client to retrieve the audio data 57 using RTSP. This specifications defines a mechanism for an IMAP4 58 client to request message content from a server through an external 59 scheme. 61 2. Conventions Used in this Document 63 The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" 64 in this document are to be interpreted as described in [KEYWORD]. 66 In examples, "C:" and "S:" preface lines sent by the client and the 67 server respectively. 69 3. Protocol Framework 71 This memo defines the following extensions to [IMAP4rev1]. 73 3.1. CAPABILITY Identification 75 IMAP4 servers that support this extension MUST include a CHANNEL 76 capability response in the response list to the CAPABILITY command. 77 This entry indicates the server supports the extension, and lists 78 the schemes available to the CHANNEL command. The capability 79 response consists of the string "CHANNEL=" followed by a 80 comma-seperated list of schemes supported by the CHANNEL extension. 82 3.2. CHANNEL Command 84 The CHANNEL command requests that message data be retrieved through 85 an external scheme. Clients may issue a partially-qualified URI, in 86 which case the server will determine the final connection 87 end-point. What constitutes a partially-qualified URI is implemen- 88 tation defined, however every URI MUST contain at least a scheme. 90 The syntax of the CHANNEL command is: 92 tag CHANNEL uri-list channel-set 94 uri-list is a list of URIs specifying how the client is willing to 95 retrieve the message data. If uri-list contains more than one ele- 96 ment the server must enumerate the list in order and SHOULD return 97 the message data via the first URI it is capable of using. 99 >>> the intent is that the client can indicate a list of 100 >>> services in descending order of usefulness/quality. 101 >>> Also, there is no guarantee that a server can express a 102 >>> particular body section through all of its advertised 103 >>> schemes, thus the list provides fallback for the server 104 >>> as well as the client. 106 channel-set is a list of message body sections to be retrieved 107 through the specified URI. 109 >>> example syntax: 110 >>> 0 CHANNEL (rtsp imap) (1 2)(3 1)(3 9.1) 111 >>> asks for section 2 of message 1 and sections 1 and 9.1 112 >>> of message 3. The preferred method is RTSP, however if 113 >>> RTSP isn't available/usable, try IMAP. In either case, 114 >>> the server will fill in the connection end-point 115 >>> information. You cannot ask for .HEADERS or .MIME data 116 >>> with CHANNEL. 118 3.3. CHANNEL Response 120 The CHANNEL response returns connection status and location infor- 121 mation to the client. One untagged response is returned for each 122 body section requested. 124 >>> example response to above command: 125 >>> 126 >>> S: * 1 CHANNEL 2 rtsp://frobozz.example.com/144124 127 >>> S: * 3 CHANNEL 1 128 >>> imap://user@example.com:/inbox;uidvalidity=2/;uid=33 129 >>> S: * 3 CHANNEL 9.1 NIL 130 >>> S: 0 OK done 131 >>> 132 >>> The NIL response to the section 9.1 request indicates 133 >>> that the part could not be retrieved via either of the 134 >>> requested schemes. This could be caused by the inability 135 >>> to convert or represent the content through the schemes, 136 >>> or because some resource was unavailable. 138 The server MUST NOT issue an untagged CHANNEL response containing a 139 URL until such time as that URL is valid and avaliable for the 140 client to dereference. The lifetime of the URL is implementation 141 defined. 143 4. Formal Protocol Syntax 145 The following syntax specification uses the augmented Backus-Naur 146 Form (ABNF) notation as defined in [ABNF], and incorporates by ref- 147 erence the Core Rules from that document. This syntax extends the 148 grammar specified in [IMAP4rev1]. 150 The following tokens are incorporated from [URI]: scheme, URI-ref- 151 erence. 153 capability =/ "CHANNEL=" scheme *["," scheme] 155 channel = "CHANNEL" SP uri-list SP channel-set 157 channel-data = "CHANNEL" nz-number (URI-reference / nil) 159 channel-set = 1*( "(" nz-number SP section-part ")" ) 160 command-select =/ channel 162 response-data = "*" SP (resp-cond-state / resp-cond-bye / 163 mailbox-data / message-data / 164 capability-data / channel-data) CRLF 165 ; adds to IMAP4rev1 166 ; 168 uri-list = "(" URI-reference *[SP URI-reference] ")" 170 5. References 172 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifi- 173 cations: ABNF." RFC2234, November 1997 175 [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Ver- 176 sion 4rev1," Work in Progress 178 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels," BCP 9, RFC2119, March 1997 181 [URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): 182 Generic Syntax," RFC2396, August 1998 184 6. Security Considerations 186 7. Authors' Addresses 188 Lyndon Nerenberg Steve Hole 189 ACI Worldwide ACI Worldwide 190 Suite 900 Suite 900 191 10117 - Jasper Avenue 10117 - Jasper Avenue 192 Edmonton, Alberta Edmonton, Alberta 193 Canada T5J 1W8 Canada T5J 1W8 195 197 Barry Leiba 198 IBM T.J. Watson Research Center 199 30 Saw Mill River Road 200 Hawthorne, NY 10532 201 203 Phone: +1 914 784 7941