idnits 2.17.1 draft-ietf-lemonade-imap-channel-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 351. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 367), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (July 18, 2004) is 7221 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) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Lemonade Working Group L. Nerenberg 2 Internet-Draft Orthanc Systems 3 Expires: January 16, 2005 S. Hole 4 ACI Worldwide 5 B. Leiba 6 IBM T.J. Watson Research Center 7 July 18, 2004 9 IMAP4 Channel Transport Mechanism 10 draft-ietf-lemonade-imap-channel-02 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 16, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 42 Table of Contents 44 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 45 2. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 3 46 2.1 CAPABILITY Identification . . . . . . . . . . . . . . . . 3 47 2.2 CHANNEL Command . . . . . . . . . . . . . . . . . . . . . 3 48 2.3 UID CHANNEL Command . . . . . . . . . . . . . . . . . . . 4 49 2.4 CHANNEL Response . . . . . . . . . . . . . . . . . . . . . 4 50 2.5 CHANNELSCHEMES Command . . . . . . . . . . . . . . . . . . 4 51 2.6 CHANNELSCHEMES Response . . . . . . . . . . . . . . . . . 5 52 3. Command Sequencing . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Formal Protocol Syntax . . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 55 6. Normative References . . . . . . . . . . . . . . . . . . . . . 6 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 57 A. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 58 B. Administrivia . . . . . . . . . . . . . . . . . . . . . . . . 7 59 C. Document Revision History . . . . . . . . . . . . . . . . . . 8 60 C.1 Changes in draft -02 . . . . . . . . . . . . . . . . . . . 8 61 D. Outstanding Issues . . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . . . 9 64 1. Conventions Used in this Document 66 The key words "MUST," "MUST NOT," "SHOULD," "SHOULD NOT," and "MAY" 67 in this document are to be interpreted as described in [KEYWORD]. 69 In examples, "C:" and "S:" preface lines sent by the client and the 70 server respectively. 72 2. Protocol Framework 74 This memo defines the following extensions to [IMAP4]. 76 2.1 CAPABILITY Identification 78 IMAP4 servers that support this extension MUST advertise the 79 "CHANNEL" capability. 81 2.2 CHANNEL Command 83 The CHANNEL command requests that message data be retrieved through 84 an external scheme. Clients may issue a request specifying a 85 partially-qualified URI, in which case the server will determine the 86 final connection end\-point. What constitutes a partially-qualified 87 URI is implementation defined. 89 The syntax of the CHANNEL command is: 91 tag CHANNEL channel-uri-list channel-set 93 is a list of URIs and schemes specifying how the 94 client desires to retrieve the message data. If 95 contains more than one element the server SHOULD return the message 96 data using the first element in the list it is capable of using. 98 is a list of message-number/body-section pairs 99 describing the content to be retrieved. The message number specifies 100 the sequence number of the message to act on. 102 The CHANNEL command is only valid in the selected state. 104 Example: 106 C: 0 CHANNEL (rtsp ftp://marvin@example.net/incoming/) 107 (1 2)(3 1)(3 9.1) 109 asks for section 2 of message 1 and sections 1 and 9.1 of message 3. 110 The preferred retrieval scheme is RTSP. If RTSP isn't available the 111 IMAP server should attempt to transfer the requested data to the FTP 112 server at example.com. 114 In either case the server will fill in the connection end-point 115 information. 117 2.3 UID CHANNEL Command 119 The UID CHANNEL command is identical to the CHANNEL command with the 120 exception that the message numbers in the sequence sets refer to 121 unique identifiers instead of message sequence numbers. 123 2.4 CHANNEL Response 125 An untagged CHANNEL response is returned for each message-number/ 126 body-section pair specified by the corresponding CHANNEL command: 128 * message-number CHANNEL section-spec URI 130 The ordering of these responses is arbitrary. The message number and 131 in the response mirror those in the corresponding 132 request, therefore responses to UID CHANNEL commands report the 133 message UID rather than the message sequence number. 135 The server MUST NOT issue an untagged CHANNEL response containing a 136 URI until such time as that URI is avaliable for the client to 137 dereference. The lifetime of the URI is implementation defined. 139 For example, the responses to the example command in the previous 140 section might look like: 142 S: * 1 CHANNEL 2 rtsp://frobozz.example.com/144124 143 S: * 3 CHANNEL 1 144 ftp://marvin@example.com/incoming/abzzqfw11423 145 S: * 3 CHANNEL 9.1 NIL 146 S: 0 OK done 148 The NIL response to the section 9.1 request indicates that the part 149 could not be retrieved via any of the requested schemes. For 150 example, this could be caused by the inability to convert or 151 represent the content via the requested schemes, or because a 152 resource was unavailable. 154 2.5 CHANNELSCHEMES Command 156 The CHANNELSCHEMES command queries the server for the list of schemes 157 it supports. 159 The syntax of the CHANNELSCHEMES command is: 161 tag CHANNELSCHEMES 163 2.6 CHANNELSCHEMES Response 165 A tagged CHANNELSCHEMES response is returned in response to a 166 CHANNELSCHEMES command. 168 The syntax of the CHANNELSCHEMES response is: 170 tag CHANNELSCHEMES channelschemes-data 172 3. Command Sequencing 174 There is no way to distinguish between a response to a CHANNEL 175 command and a UID CHANNEL command, therefore clients MUST NOT issue a 176 UID CHANNEL command while a CHANNEL command is in progress. 177 Conversely, clients MUST NOT issue a CHANNEL command while a UID 178 CHANNEL command is in progress. These restrictions are in addition 179 to the normal sequencing rules that apply to UID-style commands. 181 Servers MUST NOT send an EXPUNGE response while responding to a 182 CHANNEL command, however a server MAY send an EXPUNGE response during 183 a UID CHANNEL command. 185 4. Formal Protocol Syntax 187 The following syntax specification uses the augmented Backus-Naur 188 Form (ABNF) notation as defined in [ABNF], and incorporates by 189 reference the Core Rules from that document. This syntax extends the 190 grammar specified in [IMAP4]. 192 The following tokens are incorporated from [URI]: absoluteURI, 193 scheme. 195 channel = "CHANNEL" SP channel-uri-list 196 SP channel-set 198 channelschemes = "CHANNELSCHEMES" 200 channelschemes-data = astring / "(" astring 1*(SP astring) ")" 201 ; encodes a 203 channel-data = nz-number SP "CHANNEL" SP section-spec SP 204 astring 205 ; encodes an 207 channel-set = 1*("(" nz-number SP section-spec ")") 208 ; refers to the message sequence 209 ; number or unique identifier. 211 channel-uri-list = "(" channel-uri 212 *(SP channel-uri) ")" 214 channel-uri = astring 215 ; / 216 ; represented as an IMAP 218 command-auth =/ channelschemes 220 command-select =/ channel 222 response-data = "*" SP (resp-cond-state / resp-cond-bye / 223 mailbox-data / message-data / 224 capability-data / channel-data) CRLF 225 ; adds to 227 uid =/ channel 229 5. Security Considerations 231 It is assumed that the IMAP server and its cooperating client share 232 an authorization (and authentication) namespace. 234 6 Normative References 236 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 237 Specifications: ABNF", RFC 2234, November 1997. 239 [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 240 4rev1", RFC 3501, March 2003. 242 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 243 Requirement Levels", BCP 14, RFC 2119, March 1997. 245 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 246 Resource Identifiers (URI): Generic Syntax", RFC 2396, 247 August 1998. 249 Authors' Addresses 251 Lyndon Nerenberg 252 Orthanc Systems 253 304 - 1755 Robson Street 254 Vancouver, BC V6G 3B7 255 CA 257 EMail: lyndon+rfc-imap-channel@orthanc.ca 259 Steve Hole 260 ACI Worldwide 261 Suite 1807 262 10088 - 102 Avenue 263 Edmonton, Alberta T5J 2Z1 264 CA 266 Phone: +1 780 424 4922 267 Fax: +1 780 424 4925 268 EMail: steve.hole@messagingdirect.com 270 Barry Leiba 271 IBM T.J. Watson Research Center 272 30 Saw Mill River Road 273 Hawthorne, NY 10532 274 US 276 Phone: +1 914 784 7941 277 EMail: leiba@watson.ibm.com 279 Appendix A. IANA Considerations 281 IANA is requested to update the IMAP capabilities registry to add the 282 CHANNEL capability defined by this memo. 284 Appendix B. Administrivia 286 [This appendix will not appear in the final document.] 287 Discussion concerning this draft should be directed to the 288 mailing list. 290 Appendix C. Document Revision History 292 [This appendix will not appear in the final document.] 294 Appendix C.1 Changes in draft -02 296 1. Revert text to that from draft-nerenberg-imap-channel-01, which 297 again forms the baseline document for the specification. The 298 usage and implementation guide will be split out into another 299 memo seperate from the specification itself. 301 2. Revert to the simple string "channel" for the capability. The 302 old scheme (channel=foo,bar) required parsable capabilities. A 303 new command (CHANNELSCHEMES) is proposed for discovering the 304 supported scheme list. 306 3. The grammar has been cleaned up and synced with RFC3501. 308 4. References to schemes in the protocol no longer include the 309 trailing ":" in the scheme name (e.g. we now use "ftp" rather 310 than "ftp:"). The grammar is now unambiguous with reference to 311 the use of and (a scheme name cannot 312 contain a ":", and an requires one). Both types 313 are now encoded as . 315 5. Document reformatted to meet the latest RFC Editor's 316 requirements. 318 6. Added a CHANNELSCHEMES command, used to discover the schemes 319 supported by the server. 321 Appendix D. Outstanding Issues 323 [This appendix will not appear in the final document.] 325 1. The Security Considerations section needs to be expanded. 327 2. Examples need a seperate section. 329 Intellectual Property Statement 331 The IETF takes no position regarding the validity or scope of any 332 Intellectual Property Rights or other rights that might be claimed to 333 pertain to the implementation or use of the technology described in 334 this document or the extent to which any license under such rights 335 might or might not be available; nor does it represent that it has 336 made any independent effort to identify any such rights. Information 337 on the procedures with respect to rights in RFC documents can be 338 found in BCP 78 and BCP 79. 340 Copies of IPR disclosures made to the IETF Secretariat and any 341 assurances of licenses to be made available, or the result of an 342 attempt made to obtain a general license or permission for the use of 343 such proprietary rights by implementers or users of this 344 specification can be obtained from the IETF on-line IPR repository at 345 http://www.ietf.org/ipr. 347 The IETF invites any interested party to bring to its attention any 348 copyrights, patents or patent applications, or other proprietary 349 rights that may cover technology that may be required to implement 350 this standard. Please address the information to the IETF at 351 ietf-ipr@ietf.org. 353 Disclaimer of Validity 355 This document and the information contained herein are provided on an 356 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 357 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 358 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 359 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 360 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 361 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 363 Copyright Statement 365 Copyright (C) The Internet Society (2004). This document is subject 366 to the rights, licenses and restrictions contained in BCP 78, and 367 except as set forth therein, the authors retain all their rights. 369 Acknowledgment 371 Funding for the RFC Editor function is currently provided by the 372 Internet Society.