idnits 2.17.00 (12 Aug 2021) /tmp/idnits44407/draft-nerenberg-imap-channel-02.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-14) 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 6 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (June 2002) is 7273 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) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'IMAP4rev1' ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 3 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-02.txt ACI Worldwide 5 B. Leiba 6 IBM Research 7 June 2002 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 Discussion concerning this draft should be directed to the 41 mailing list. (To subscribe: echo subscribe | 42 mail ietf-imap-voice-request@imc.org) 44 Changes in -02: 46 Changed to use instead of . This allows retrieval of headers and MIME structure. 49 returns a , not (to match 50 syntax). 52 Add missing SP tokens to grammar. 54 Grammar fix to allow foo: as a valid URI in a request. 56 Add UID CHANNEL. 58 Clarify response when client issues a command with an unsupported 59 scheme. 61 Add section on command sequencing. 63 Note arbitrary ordering of untagged responses. 65 Replace URI-reference with absoluteURI. The IMAP server can't main- 66 tain the state required to deal with relative URIs. This also 67 solves an ambiguity between parsing "NIL" as or as a relative 68 URI. 70 Outstanding Issues 72 Responses encode the URL as an . Does the syntax of 73 conflict with the base IMAP grammar? There are enough 74 punctuation characters available in a URL to put a protocol parser 75 into an intractable state. Someone (besides the draft authors) 76 needs to verify there are no conflicts between and 77 the rest of IMAP. 79 Security considerations needs to be written. 81 1. Abstract 83 IMAP4 is being used to serve rich media content in environments 84 that extend beyond traditional text-based e-mail. One example is a 85 cellular telephone that can retrieve and send MIME-encoded audio 86 data through IMAP4. While this type of content can be exchanged 87 natively using IMAP4, some applications will work better if the 88 message content can be manipulated using schemes external to the 89 IMAP4 connection. In our cellular telephone example, it might be 90 preferable for the telephone client to retrieve the audio data 91 using RTSP. This specifications defines a mechanism for an IMAP4 92 client to request message content from a server through an external 93 scheme. 95 2. Conventions Used in this Document 97 The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" 98 in this document are to be interpreted as described in [KEYWORD]. 100 In examples, "C:" and "S:" preface lines sent by the client and the 101 server respectively. 103 The examples in this document do NOT form part of the specifica- 104 tion. Where conflicts exist between the text and the formal gram- 105 mar, the grammar is authoritative. 107 3. Protocol Framework 109 This memo defines the following extensions to [IMAP4rev1]. 111 3.1. CAPABILITY Identification 113 IMAP4 servers that support this extension MUST include a CHANNEL 114 capability response in the response list to the CAPABILITY command. 115 This entry indicates the server supports the extension, and lists 116 the schemes available to the CHANNEL command. The capability 117 response consists of the string "CHANNEL=" followed by a list of 118 schemes supported by the CHANNEL extension. 120 Example: 122 * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5 CHANNEL=imap,ftp 124 3.2. CHANNEL Command 126 The CHANNEL command requests that message data be retrieved through 127 an external scheme. Clients may issue a partially-qualified URI, in 128 which case the server will determine the final connection 129 end-point. What constitutes a partially-qualified URI is implemen- 130 tation defined. 132 The syntax of the CHANNEL command is: 134 tag CHANNEL channel-uri-list channel-set 136 is a list of URIs or schemes specifying how the 137 client is willing to retrieve the message data. If contains more than one element the server must enu- 139 merate the list in order and SHOULD return the message data via the 140 first item in the list it is capable of using. 142 is a list of message-number/body-section pairs 143 describing the content to be retrieved. The message number speci- 144 fies the sequence number of the message to act on, or in the case 145 of a UID CHANNEL command, the UID of the message. 147 Example: 149 C: 0 CHANNEL (rtsp: imap:) (1 2)(3 1)(3 9.1) 151 asks for section 2 of message 1 and sections 1 and 9.1 of mes- 152 sage 3. The preferred retrieval scheme is RTSP. If RTSP isn't 153 available the IMAP scheme should be attempted. In either case 154 the server will fill in the connection end-point information. 156 3.3. CHANNEL Response 158 An untagged CHANNEL response is returned for each message-num- 159 ber/body-section pair specified by the corresponding CHANNEL 160 command: 162 * message-number CHANNEL section-spec URI 164 The ordering of these responses is arbitrary. The message number 165 and in the response mirror those in the correspond- 166 ing request, therefore responses to UID CHANNEL commands report the 167 message UID rather than the message sequence number. 169 Example: 171 The responses to the example command in the previous section 172 might look like: 174 S: * 1 CHANNEL 2 rtsp://frobozz.example.com/144124 175 S: * 3 CHANNEL 1 176 imap://user@example.com:/inbox;uidvalidity=2/;uid=33 177 S: * 3 CHANNEL 9.1 NIL 178 S: 0 OK done 180 The NIL response to the section 9.1 request indicates that the 181 part could not be retrieved via either of the requested 182 schemes. This could be caused by the inability to convert or 183 represent the content via the requested schemes, or because a 184 resource was unavailable. 186 The server MUST NOT issue an untagged CHANNEL response containing a 187 URL until such time as that URL is avaliable for the client to 188 dereference. The lifetime of the URL is implementation defined. 190 If any one of the schemes in the does not match 191 one of the schemes listed in the server channel capability list the 192 server: 1) MUST NOT execute any part of the command, 2) MUST NOT 193 return any untagged responses to the command, and 3) MUST issue 194 only a tagged BAD completion response. 196 3.4. Command Sequencing 198 Since there is no way to distinguish between responses to CHANNEL 199 and UID CHANNEL, clients MUST NOT issue a UID CHANNEL command while 200 a CHANNEL command is in progress. Conversely, clients MUST NOT 201 issue a CHANNEL command while a UID CHANNEL command is in progress. 202 These restrictions are in addition to the normal sequencing rules 203 that apply to UID-style commands. 205 4. Formal Protocol Syntax 207 The following syntax specification uses the augmented Backus-Naur 208 Form (ABNF) notation as defined in [ABNF], and incorporates by ref- 209 erence the Core Rules from that document. This syntax extends the 210 grammar specified in [IMAP4rev1]. 212 The following tokens are incorporated from [URI]: absoluteURI, 213 scheme. 215 capability =/ "CHANNEL=" scheme *("," scheme) 217 channel = ["UID" SP] "CHANNEL" SP channel-uri-list 218 SP channel-set 220 channel-data = "CHANNEL" SP section-spec SP 221 (absoluteURI / nil) 223 channel-set = 1*("(" nz-number SP section-spec ")") 225 channel-uri-list = "(" channel-uri-reference 226 1*(SP channel-uri-reference) ")" 228 channel-uri-reference = absoluteURI / scheme ":" 230 command-select =/ channel 232 response-data = "*" SP (resp-cond-state / resp-cond-bye / 233 mailbox-data / message-data / 234 capability-data / channel-data) CRLF 235 ; adds to 237 5. References 239 [ABNF] Crocker, D., P. Overell, "Augmented BNF for Syntax Specifi- 240 cations: ABNF." RFC2234, November 1997 242 [IMAP4rev1] Crispin, M., "Internet Message Access Protocol - Ver- 243 sion 4rev1," Work in Progress 245 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels," BCP 9, RFC2119, March 1997 248 [URI] Berners-Lee, T., et al, "Uniform Resource Identifiers (URI): 249 Generic Syntax," RFC2396, August 1998 251 6. Security Considerations 253 >>> TBD <<< 255 7. Authors' Addresses 257 Lyndon Nerenberg Steve Hole 258 ACI Worldwide ACI Worldwide 259 Suite 900 Suite 900 260 10117 - Jasper Avenue 10117 - Jasper Avenue 261 Edmonton, Alberta Edmonton, Alberta 262 Canada T5J 1W8 Canada T5J 1W8 264 265 Phone: +1 780 424 4922 Phone: +1 780 424 4922 267 Barry Leiba 268 IBM T.J. Watson Research Center 269 30 Saw Mill River Road 270 Hawthorne, NY 10532 271 272 Phone: +1 914 784 7941