idnits 2.17.00 (12 Aug 2021) /tmp/idnits63873/draft-segmuller-imap-structure-00.txt: 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: ---------------------------------------------------------------------------- ** 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 6 longer pages, the longest (page 2) being 59 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 abstract seems to contain references ([IMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 91: '... returned MUST NOT change for any par...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 207 has weird spacing: '...at this exten...' -- 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 (April 2001) is 7705 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) -- Missing reference section? 'IMAP' on line 285 looks like a reference -- Missing reference section? 'MIME' on line 298 looks like a reference -- Missing reference section? 'VPIM' on line 74 looks like a reference -- Missing reference section? 'KEYWORDS' on line 289 looks like a reference -- Missing reference section? 'RFC822' on line 295 looks like a reference -- Missing reference section? 'ABNF' on line 292 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Segmuller 3 Internet Draft IBM T.J. Watson Research Center 4 Document: draft-segmuller-imap-structure-00.txt April 2001 5 Expires: October 2001 7 IMAP Extension: Structure 9 Status of this Document 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 The protocol discussed in this document is experimental and subject 29 to change. Persons planning on either implementing or using this 30 protocol are STRONGLY URGED to get in touch with the author before 31 embarking on such a project. 33 Discussion and suggestions for improvement are requested, and should 34 be sent to ietf-imapext@imc.org. This document will expire before 31 35 October 2001. Distribution of this memo is unlimited. 37 Abstract 39 This document describes the STRUCTURE extension to the [IMAP] 40 protocol. This extension allows the querying of the message 41 structure information in a self describing way. 43 1 Introduction 45 This document describes a new static message data item which returns 46 all the content fields of all the parts in a message. 48 Clients that implement this extension need only issue one command to 49 obtain all the content-* fields (defined in [MIME]) of all part. 51 Without this extension, this is not possible if there is a required 52 content-* field which is not in the BODYSTRUCTURE command. A client 53 must wait for the fetch BODYSTRUCTURE to return, and then issue fetch 54 "BODY[n.MIME]" for each part that it requires this additional 55 information for. 57 We can add these fields to the BODYSTRUCTURE response, but then the 58 problem will hit us again in the future. 60 If there are two extensions that add fields to the BODYSTRUCTURE 61 response at the same time, then these extensions need to be aware of 62 each other when being defined, otherwise we will have two conflicting 63 extensions. 65 Draft Note: 67 This problem recently surfaced in the "Voice Profile for Internet 68 Mail" IETF working group [VPIM]. One part of the discussion 69 centered on where to put the critical content notation such that an 70 IMAP client can get the information without an extra round trip. 71 This caused them to look at where the critical content can be 72 squeezed into instead of what is right for MIME. 74 [VPIM]; Discussions on "Voice Profile for Internet Mail" IETF 75 working group; Charter: 76 "http://www.ietf.org/html.charters/vpim-charter.html"; Archive: 77 "http://www.neystadt.org/vpim/"; March 2001 79 2 Conventions used in this document 81 Conventions for notations are as in [IMAP], including the use of 82 [KEYWORDS]. 84 The capability string associated with the extension defined in this 85 document is "STRUCTURE". 87 3 FETCH STRUCTURE Command 89 The STRUCTURE message data item is added to the fetch command. This 90 static data item returns the structure of the message. The data 91 returned MUST NOT change for any particular message. 93 For each part in the message, the "content-" fields are returned. 94 The FIELDS and FIELDS.NOT part specifiers, which are followed by a 95 list of field-name (as defined in [RFC822]) names, may be used to 96 restrict which fields are returned. The content-type and 97 content-disposition fields are always returned. The FIELDS part 98 specifier return the specified fields, in addition to the 99 content-type and content-disposition fields. The FIELDS.NOT part 100 specifier returns only the "content-" fields which are not listed, 101 but always returns the content-type and content-disposition. 103 4 FETCH STRUCTURE Response 105 The STRUCTURE message data item returns information about all the 106 parts in a message. For every part in the message, the content-type 107 (with parameters), the content-disposition (with parameters), and all 108 the "content-" fields are returned. The content-* fields that are 109 returned are determined by the FIELDS and FIELDS.NOT specifier of the 110 FETCH STRUCTURE command. The content-type and content-disposition 111 are always returned. 113 Following the content-* fields, some additional information, which is 114 dependent on the type of part, is returned. 116 For "text/*" parts, the number of octets and the number of lines in 117 the body of the part is returned. 119 For "multipart/*" parts, the STRUCTURE of each nested part is 120 returned. 122 For "message/rfc822" parts, the ENVELOPE and STRUCTURE of the nested 123 message is returned. 125 For all other parts, the number of octets in the body of the part is 126 returned. 128 5 Formal Syntax 130 This syntax updates the formal syntax in [IMAP]. 132 The following syntax specification uses the Augmented Backus-Naur 133 Form (ABNF) notation as specified in [ABNF]. 135 fetch-att =/ "STRUCTURE" [ "[" "FIELDS" [ ".NOT" ] SP header-list 136 "]" ] 138 msg-att-static =/ "STRUCTURE" SP structure 140 structure = "(" media-content-type 141 SP body-fld-param 142 SP body-fld-dsp 143 SP structure-content-fields 144 SP structure-body 145 ")" 147 media-content-type = media-type SP media-subtype 149 media-type = string 150 structure-content-fields = "(" structure-field 151 *(SP structure-field) 152 ")" / nil 153 ; all content-* fields in the 154 ; part header 155 ; except content-type and 156 ; content-disposition 158 structure-field = structure-header SP structure-value 160 structure-header = string 162 structure-value = string 164 structure-body = structure-body-basic / structure-body-text 165 / structure-body-msg / structure-body-mpart 167 structure-body-basic = body-fld-octets 168 ; content-type of anything except 169 ; "text/*", "multipart/*", 170 "message/rfc822" 172 structure-body-text = body-fld-octets SPACE body-fld-lines 173 ; content-type of "text/*" 175 structure-body-msg = body-fld-octets SP body-fld-lines 176 SP envelope SP structure 177 ; content-type of "message/rfc822" 179 structure-body-mpart = structure *( SP structure ) 180 ; content-type of "multipart/*" 182 Draft Note: 184 The following are copied from [IMAP], they are not being defined in 185 this document. 187 body-fld-dsp = "(" string SP body-fld-param ")" / nil 189 body-fld-lines = number 191 body-fld-octets = number 193 body-fld-param = "(" string SP string *(SP string SP string) 194 ")" / nil 196 envelope = "(" env-date SP env-subject 197 SP env-from SP env-sender SP env-reply-to 198 SP env-to SP env-cc SP env-bcc 199 SP env-in-reply-to SP env-message-id ")" 201 media-subtype = string 203 6 Security Considerations 205 Security considerations are discussed in [IMAP]. 207 It is belived that this extension doesn't introduce any additional 208 security concerns. 210 7 Example 212 For the message: 214 to: foo@bar.com.invalid 215 from: bar@foo.com.invalid 216 subject: re: foo bar baz 217 content-type: multipart/mixed; boundary="A" 219 --A 220 content-type: text/html; charset="iso-8859-1" 221 content-transfer-encoding: quoted-printable 223 hello 225 --A 226 content-type: image/gif; name="xyz.gif" 227 content-transfer-encoding: base64 228 content-disposition: attachment; filename="xyz.gif" 230 .... 232 --A 233 content-type: message/rfc822 235 from: foo@bar.com.invalid 236 to: bar@foo.com.invalid 237 subject: foo bar baz 238 content-type: text/plain 240 hello 242 --A-- 244 The command: 246 xx FETCH 1 (STRUCTURE) 248 Would return: 250 * 1 FETCH (STRUCTURE 251 ("multipart" "mixed" ("boundary" "A") nil nil 252 ("text" "html" ("charset" "iso-8859-1") nil 253 ("content-transfer-encoding" "quoted-printable") 254 7 1 ) 255 ("image" "gif" ("name" "xyz.gif") 256 ("attachment" ("filename" "xyz.gif")) 257 ("content-transfer-encoding" "quoted-printable") 258 200 ) 259 ("message" "rfc822" nil nil nil 260 200 7 261 262 ("text" "html" ("charset" "iso-8859-1") nil 263 nil 7 1 ) 264 ) 265 ) 266 ) 268 In the above example, the one long line has been folded, and extra 269 spaces have been inserted at the beginning of each line for formating 270 purposes only. In the actual response, there is only one space 271 between tokens, and no embeded new line characters. 273 8 Author's Address 275 Wolfgang Segmuller 276 IBM T.J. Watson Research Center 277 30 Saw Mill River Rd 278 Hawthorne, NY 10532 280 Phone: 1-914-784-7408 281 Email: whs@watson.ibm.com 283 Appendix A. References 285 [IMAP]; Crispin, M.; "Internet Message Access Protocol - Version 286 4rev1"; Internet Draft draft-crispin-imapv-14.txt (updates RFC 2060); 287 University of Washington; January 2001 289 [KEYWORDS]; Bradner, S.; "Key words for use in RFCs to Indicate 290 Requirement Levels"; RFC 2119; Harvard University; March 1997 292 [ABNF]; Crocker, D.; "Augmented BNF for Syntax Specifications: ABNF"; 293 RFC 2234; Internet Mail Consortium; November, 1997. 295 [RFC822]; Crocker, D.; "Standard for the Format of ARPA Internet Text 296 Messages"; STD 11; RFC 822; University of Delaware; August 1982 298 [MIME]; Freed, N. and Borenstein, N.; "Multipurpose Internet Mail 299 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 300 2045; Innosoft and First Virtual; November 1996. 302 Appendix B. Full Copyright Statement 304 Copyright (C) The Internet Society 2001. All Rights Reserved. 306 This document and translations of it may be copied and furnished to 307 others, and derivative works that comment on or otherwise explain it 308 or assist in its implementation may be prepared, copied, published 309 and distributed, in whole or in part, without restriction of any 310 kind, provided that the above copyright notice and this paragraph are 311 included on all such copies and derivative works. However, this 312 document itself may not be modified in any way, such as by removing 313 the copyright notice or references to the Internet Society or other 314 Internet organizations, except as needed for the purpose of 315 developing Internet standards in which case the procedures for 316 copyrights defined in the Internet Standards process must be 317 followed, or as required to translate it into languages other than 318 English. 320 The limited permissions granted above are perpetual and will not be 321 revoked by the Internet Society or its successors or assigns. 323 This document and the information contained herein is provided on an 324 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 325 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 326 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 327 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 328 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.