idnits 2.17.1 draft-melnikov-imap-content-location-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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 244 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 are 34 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([IMAP4], [MHTML]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 7986 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 draft-melnikov-imap-content-location-00.txt M. Crispin 2 Expires: December 2002 University of Washington 3 S. Hole 4 A. Melnikov 5 ACI WorldWide/MessagingDirect 6 June 2002 8 An extension to IMAP BODYSTRUCTURE for returning 9 Content-Location information 10 draft-melnikov-imap-content-location-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are 16 working documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 27 Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society 2002. All Rights Reserved. 34 0.1. Open issues 36 Other open issues are enclosed in << and >> in the relevant places 37 of this document. 39 0.2. Change History 41 Table of Contents 43 <> 45 1. Abstract 47 The [IMAP4] BODYSTRUCTURE FETCH data item allows a client to learn about 48 the MIME structure of a message without the need to download the entire 49 message. 51 This document extends the syntax of the [IMAP4] BODYSTRUCTURE FETCH 52 response data item to include information from the Content-Location 53 header field described in [MHTML]. This extension helps MHTML-aware 54 IMAP clients to save both the number of round trips and the amount of 55 information sent across the network. 57 Fallback strategies are also discussed when an IMAP server doesn't 58 support this extension. 60 2. Conventions Used in This Document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 66 In examples, lines beginning with "S:" are sent by the IMAP server, and 67 lines beginning with "C:" are sent by the client. Line breaks may appear 68 in example commands solely for editorial clarity; when present in 69 the actual message they are represented by "". Space character 70 may be represented in examples as "". 72 The formal syntax is defined using ABNF [ABNF]. 74 3. IMAP Protocol Changes 76 This document adds an additional element to the BODYSTRUCTURE FETCH response 77 described in 7.4.2 of [IMAP4]. 79 The extension data of a multipart body part is extended to add 80 a new element "body location" after the "body language": 82 body location 83 A string giving the content location URI as specified in the 84 Content-Location MIME header field [MHTML]. 86 The extension data of a non-multipart body part is extended to add 87 a new element "body location" after the "body language": 89 body location 90 A string giving the content location URI as specified in 91 Content-Location MIME header field [MHTML]. 93 Example: S: * 1 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii") 94 NIL NIL "7BIT" 323 14 NIL NIL NIL NIL)("TEXT" "HTML" 95 ("CHARSET" "iso-8859-1") NIL NIL "QUOTED-PRINTABLE" 50578 96 1111 NIL NIL NIL "http://home.netscape.com/") 97 "MIXED" ("BOUNDARY" "------------8FC7BFAA529B4689FD642892") 98 NIL NIL NIL)) 100 If the server doesn't return Content-Location information in a 101 BODYSTRUCTURE FETCH response, the client should issue one or more FETCHes that 102 contain "BODY.PEEK[HEADER.FIELDS (Content-Location)]" for the root part, 103 "BODY.PEEK[.HEADER.FIELDS (Content-Location)]" for a MESSAGE/RFC822 104 part and "BODY.PEEK[.MIME]" for all other parts. Of course, 105 "BODY.PEEK[HEADER]" (or HEADER.FIELDS that includes Content-Location) 106 can be use instead of "BODY.PEEK[HEADER.FIELDS (Content-Location)]" 107 if it is desired to get other header fields. 109 Example: C: A141 FETCH 1:* BODYSTRUCTURE 110 S: * 1 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii") 111 NIL NIL "7BIT" 323 14 NIL NIL NIL)("TEXT" "HTML" 112 ("CHARSET" "iso-8859-1") NIL NIL "QUOTED-PRINTABLE" 50578 113 1111 NIL NIL NIL) "MIXED" 114 ("BOUNDARY" "------------8FC7BFAA529B4689FD642892") 115 NIL NIL)) 116 ... 117 S: A141 OK done! 118 ;;; The server did not return a Content-Location in the BODYSTRUCTURE, so we 119 ;;; must fetch it manually from the header field: 120 C: A142 FETCH 1 (BODY.PEEK[HEADER.FIELDS (Content-Location)] 121 BODY.PEEK[1.MIME] BODY.PEEK[2.MIME]) 122 S: * 1 FETCH (BODY[HEADER.FIELDS (Content-Location)] {2} 123 BODY[1.MIME] {79} 124 Content-Type: text/plain; charset=us-ascii 125 Content-Transfer-Encoding: 7bit 126 BODY[2.MIME] {182} 127 Content-Type: text/html; charset=iso-8859-1 128 Content-Transfer-Encoding: quoted-printable 129 Content-Base: "http://home.netscape.com/" 130 Content-Location: "http://home.netscape.com/") 131 S: A142 OK done! 133 A client must be able to deal with empty responses from 134 "BODY[HEADER.FIELDS (Content-Location)]" and treat them as missing 135 Content-Location header fields. 137 4. Formal Syntax 139 The following syntax specification uses the Augmented Backus-Naur 140 Form (ABNF) notation as specified in [ABNF]. 142 Non-terminals referenced but not defined below are as defined by 143 [IMAP4]. 145 Except as noted otherwise, all alphabetic characters are case- 146 insensitive. The use of upper or lower case characters to define token 147 strings is for editorial clarity only. Implementations MUST accept 148 these strings in a case-insensitive fashion. 150 body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang 151 [SP body-fld-loc *(SP body-extension)]]] 152 ; MUST NOT be returned on non-extensible 153 ; "BODY" fetch 155 body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang 156 [SP body-fld-loc *(SP body-extension)]]] 158 body-fld-loc = nstring 159 ; NIL if Content-Location header is not present, 160 ; has a syntax of URI otherwise 162 5. Security Considerations 164 This document doesn't raise any new security concernes not already 165 discussed in [IMAP4] and [MHTML]. 167 6. References 169 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 170 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 171 November 1997. 173 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 174 4rev1", update to RFC 2060 in progress, University of Washington. 176 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 177 Requirement Levels", RFC 2119, Harvard University, March 1997. 179 [MHTML] Palme, J., Hopmann, A., Shelness, N., 180 "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", 181 RFC 2557, Stockholm University/KTH, Microsoft Corporation, 182 Lotus Development Corporation, March 1999. 184 7. Acknowledgments 186 <> 188 8. Author's Addresses 190 Mark R. Crispin 191 Networks and Distributed Computing 192 University of Washington 193 4545 15th Avenue NE 194 Seattle, WA 98105-4527 196 Phone: (206) 543-5762 198 EMail: MRC@CAC.Washington.EDU 200 Steve Hole 202 ACI WorldWide/MessagingDirect 203 #900, 10117 Jasper Avenue, 204 Edmonton, Alberta, T5J 1W8, CANADA 206 EMail: Steve.Hole@messagingdirect.com 208 Alexey Melnikov 210 ACI WorldWide/MessagingDirect 211 22 The Quadrant, Richmond, Surrey 212 TW9 1BP, United Kingdom 214 EMail: Alexey.Melnikov@messagingdirect.com 216 9. Full Copyright Statement 218 Copyright (C) The Internet Society 2002. All Rights Reserved. 220 This document and translations of it may be copied and furnished to 221 others, and derivative works that comment on or otherwise explain it 222 or assist in its implementation may be prepared, copied, published 223 and distributed, in whole or in part, without restriction of any 224 kind, provided that the above copyright notice and this paragraph 225 are included on all such copies and derivative works. However, this 226 document itself may not be modified in any way, such as by removing 227 the copyright notice or references to the Internet Society or other 228 Internet organizations, except as needed for the purpose of 229 developing Internet standards in which case the procedures for 230 copyrights defined in the Internet Standards process must be 231 followed, or as required to translate it into languages other than 232 English. 234 The limited permissions granted above are perpetual and will not be 235 revoked by the Internet Society or its successors or assigns. 237 This document and the information contained herein is provided on an 238 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 239 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 240 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 241 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 242 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.