idnits 2.17.1 draft-cridland-urlfetch-binary-03.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 413. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 419. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 4, 2008) is 5675 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 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) == Outdated reference: A later version (-13) exists of draft-ietf-lemonade-streaming-06 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft Isode Limited 4 Intended status: Standards Track September 4, 2008 5 Expires: March 8, 2009 7 Extended URLFETCH for binary and converted parts 8 draft-cridland-urlfetch-binary-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 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 This Internet-Draft will expire on March 8, 2009. 35 Abstract 37 The URLFETCH command defined as part of URLAUTH provides a mechanism 38 for third-parties to gain access to data held within messages in a 39 user's private store, however, this data is sent verbatim, which is 40 not suitable for a number of applications. This memo specifies a 41 method for obtaining data in forms suitable for non-mail 42 applications. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Conventions used in this document . . . . . . . . . . . . . . 3 48 3. Extended URLFETCH . . . . . . . . . . . . . . . . . . . . . . 3 49 3.1. Command Parameters . . . . . . . . . . . . . . . . . . . . 3 50 3.2. Response Metadata . . . . . . . . . . . . . . . . . . . . 4 51 4. Example Exchanges . . . . . . . . . . . . . . . . . . . . . . 5 52 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 53 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 54 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 56 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 58 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 Intellectual Property and Copyright Statements . . . . . . . . . . 10 62 1. Introduction 64 Although [URLAUTH] provides a URLFETCH command which can be used to 65 dereference a URL and return the body part data, it does so by 66 returning the encoded form, without sufficient metadata to decode. 67 This is suitable for use in mail applications such as [BURL], where 68 the encoded form is suitable, but not where access to the actual 69 content is required, such as [STREAMING]. 71 This memo specifies a mechanism which returns additional metadata 72 about the part, such as its [MEDIATYPE] type, as well as removing any 73 content transfer encoding used on the body part. 75 2. Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [KEYWORDS]. 81 Protocol examples are line-wrapped for clarity. Protocol strings are 82 prefixed with C: and S: for client and server respectively, and 83 elided data is represented by [...]. Implementors should note these 84 notations are for editorial clarity only. 86 3. Extended URLFETCH 88 This extension is available in any IMAP server implementation which 89 includes URLAUTH=BINARY within its capability string. 91 Such servers accept additional, per-URL, parameters to the URLFETCH 92 command, and will provide, upon request, specific data for each URL 93 dereferenced. 95 3.1. Command Parameters 97 The URLFETCH command is extended by the provision of optional 98 parameters. The extended URLFETCH command is distinct by enclosing 99 each URL and associated parameters in a parenthesized list. The 100 absence of any parameters, or if the URL is sent unenclosed, causes 101 the command to behave precisely as specified in [URLAUTH]. 103 Similarly, if the URL is invalid, the command will behave precisely 104 as specified in [URLAUTH], and return a simple NIL. 106 Available parameters are: 108 BODYPARTSTRUCTURE 109 Provide a BODYPARTSTRUCTURE. 111 BODYPARTSTRUCTURE is defined in [CONVERT], and provides metadata 112 useful for processing applications, such as the type of the data. 114 BINARY 115 Provide the data without any Content-Transfer-Encoding. 117 In particular, this means that the data MAY contain NUL octets, 118 and not be formed from textual lines. Data containing NUL octets 119 MUST be transferred using the literal8 syntax defined in [BINARY]. 121 BODY 122 Provide the data as-is. 124 This will provide the same data as the unextended [URLAUTH] as a 125 metadata item. 127 Metadata items MUST NOT appear more than once per URL requested, and 128 clients MUST NOT request both BINARY and BODY. 130 3.2. Response Metadata 132 In order to carry any requested metadata and provide additional 133 information to the consumer, the URLFETCH response is similarly 134 extended. 136 Following the URL itself, servers will include a series of 137 parenthesized metadata elements. Defined metadata elements are as 138 follows: 139 BODYPARTSTRUCTURE 140 The BODYPARTSTRUCTURE provides information about the data 141 contained in the response, as it has been returned. It will 142 reflect any conversions or decoding that have taken place. In 143 particular, this will show an identity encoding if BINARY is also 144 requested. 146 BINARY 147 The BINARY item provides the content, without any content transfer 148 encoding applied. If this is not possible (for example, the 149 content transfer encoding is unknown to the server), then this MAY 150 contain NIL. Servers MUST understand all identity content 151 transfer encodings defined in [MIME], as well as the 152 transformation encodings "Base64" [BASE64] and "Quoted-Printable" 153 [MIME]. 155 BODY 156 The BODY item provides the content as found in the message, with 157 any content transfer encoding still applied. Requesting only the 158 BODY will provide equivalent functionality to the unextended 159 [URLAUTH], however using the extended syntax described herein. 161 Note that unlike [CONVERT], BODYPARTSTRUCTURE is not appended with 162 the part specifier, as this is implicit in the URL. 164 4. Example Exchanges 166 A client requests the data with no content transfer encoding. 168 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 169 section=1.2;urlauth=anonymous:internal: 170 91354a473744909de610943775f92038" BINARY) 171 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 172 section=1.2;urlauth=anonymous:internal: 173 91354a473744909de610943775f92038" (BINARY {28} 174 S: Si vis pacem, para bellum. 175 S: 176 S: ) 177 S: A001 OK URLFETCH completed 179 Note that the data here does not contain a NUL octet, therefore a 180 literal - not literal8 - syntax has been used. 182 A client again requests data with no content transfer encoding, but 183 this time requests the body structure. 185 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 186 section=1.3;urlauth=anonymous:internal: 187 ae354a473744909de610943775f92038" BINARY BODYPARTSTRUCTURE) 188 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 189 section=1.3;urlauth=anonymous:internal: 190 ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE 191 ("IMAGE" "PNG" () NIL NIL "BINARY" 123)) (BINARY ~{123} 192 S: [123 octets of data, some of which is NUL]) 193 S: A001 OK URLFETCH completed 194 A client requests only the body structure. 196 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 197 section=1.3;urlauth=anonymous:internal: 198 ae354a473744909de610943775f92038" BODYPARTSTRUCTURE) 199 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 200 section=1.3;urlauth=anonymous:internal: 201 ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE 202 ("IMAGE" "PNG" () NIL NIL "BASE64" 164)) 203 S: A001 OK URLFETCH completed 205 A client requests the body structure, and the original content. 207 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 208 section=1.3;urlauth=anonymous:internal: 209 ae354a473744909de610943775f92038" BODYPARTSTRUCTURE BODY) 210 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 211 section=1.3;urlauth=anonymous:internal: 212 ae354a473744909de610943775f92038" (BODYPARTSTRUCTURE 213 ("IMAGE" "PNG" () NIL NIL "BASE64" 164)) (BODY {164} 214 S: [164 octets of base64 encoded data]) 215 S: A001 OK URLFETCH completed 217 Some parts cannot be decoded, so the server will provide the 218 BODYPARTSTRUCTURE of the part as-is, and NIL for the binary content: 220 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 221 section=1.4;urlauth=anonymous:internal: 222 87ecbd02095b815e699503fc20d869c8" BODYPARTSTRUCTURE BINARY) 223 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 224 section=1.4;urlauth=anonymous:internal: 225 87ecbd02095b815e699503fc20d869c8" (BODYPARTSTRUCTURE 226 ("IMAGE" "PNG" () NIL NIL "X-BLURDYBLOOP" 123)) 227 (BINARY NIL) 228 S: A001 OK URLFETCH completed 230 If a part simply doesn't exist, however, or the URI is invalid for 231 some other reason, then NIL is returned instead of metadata: 233 C: A001 URLFETCH ("imap://joe@example.com/INBOX/;uid=20/; 234 section=200;urlauth=anonymous:internal: 235 88066d37e2e5410e1a6486350a8836ee" BODYPARTSTRUCTURE BODY) 236 S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/; 237 section=200;urlauth=anonymous:internal: 238 88066d37e2e5410e1a6486350a8836ee" NIL 239 S: A001 OK URLFETCH completed 241 5. Formal Syntax 243 This formal syntax uses ABNF as specified in [ABNF], and includes 244 productions defined in [URLAUTH], [BINARY] and [IMAP]. 246 capability =/ "URLAUTH=BINARY" 248 ; Command parameters; see Section 3.1 250 urlfetch = "URLFETCH" 1*(SP url-fetch-arg) 252 url-fetch-arg = url-fetch-simple / url-fetch-ext 254 url-fetch-simple = url-full 255 ; Unextended URLFETCH. 257 url-fetch-ext = "(" url-full *(SP url-fetch-param) ")" 258 ; If no url-fetch-param present, as unextended. 260 url-fetch-param = "BODY" / "BINARY" / "BODYPARTSTRUCTURE" / atom 262 ; Response; see Section 3.2 264 urlfetch-data = "*" SP "URLFETCH" 265 1*(SP (urldata-simple / urldata-ext / 266 urldata-error)) 268 urldata-error = SP url-full SP nil 270 urldata-simple = SP url-full SP nstring 271 ; If client issues url-fetch-simple, server MUST respond with 272 ; urldata-simple. 274 urldata-ext = SP url-full url-metadata 276 url-metadata = 1*(SP "(" url-metadata-el ")") 278 url-metadata-el = url-meta-bodystruct / url-meta-body / 279 url-meta-binary 281 url-bodystruct = "BODYPARTSTRUCTURE" SP body 283 url-binary = "BINARY" SP ( nstring / literal8 ) 284 ; If content contains a NUL octet, literal8 MUST be used. 285 ; Otherwise, content SHOULD use nstring. 286 ; On decoding error NIL should be used. 288 url-body = "BODY" SP nstring 290 6. IANA Considerations 292 IMAP4 capabilities are registered by publishing a standards track or 293 IESG approved experimental RFC. The registry is currently located 294 at: 296 http://www.iana.org/assignments/imap4-capabilities 298 This document defines the URLFETCH=BINARY IMAP capability. IANA is 299 requested to add it to the registry accordingly. 301 7. Security Considerations 303 Implementors are directed to the security considerations within 304 [IMAP], [URLAUTH], and [BINARY]. 306 The ability of the holder of a URL to be able to fetch metadata about 307 the content pointed to by the URL as well as the content itself 308 allows a potential attacker to discover more about the content than 309 was previously possible, including its original filename, and user- 310 supplied description. 312 The additional value of this information to an attacker in marginal, 313 and applies only to those URLs for which the attacker does not have 314 direct access, such as those produced by [URLAUTH]. Implementors are 315 therefore directed to the security considerations present in 316 [URLAUTH]. 318 8. Acknowledgements 320 Comments were received on the idea, and/or this draft, from Neil 321 Cook, Philip Guenther, Alexey Melnikov, Ken Murchison and others. 322 Whether in agreement or dissent, the comments have refined and 323 otherwise influenced the document. 325 9. References 327 9.1. Normative References 329 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 330 Specifications: ABNF", STD 68, RFC 5234, January 2008. 332 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 333 Encodings", RFC 4648, October 2006. 335 [BINARY] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 336 April 2003. 338 [CONVERT] Melnikov, A. and P. Coates, "Internet Message Access 339 Protocol - CONVERT Extension", RFC 5259, July 2008. 341 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 342 4rev1", RFC 3501, March 2003. 344 [KEYWORDS] 345 Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, March 1997. 348 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 349 Extensions (MIME) Part One: Format of Internet Message 350 Bodies", RFC 2045, November 1996. 352 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - 353 URLAUTH Extension", RFC 4467, May 2006. 355 9.2. Informative References 357 [BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, 358 May 2006. 360 [MEDIATYPE] 361 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 362 Extensions (MIME) Part Two: Media Types", RFC 2046, 363 November 1996. 365 [STREAMING] 366 Cook, N., "Streaming Internet Messaging Attachments", 367 draft-ietf-lemonade-streaming-06 (work in progress), 368 June 2008. 370 Author's Address 372 Dave Cridland 373 Isode Limited 374 5 Castle Business Village 375 36, Station Road 376 Hampton, Middlesex TW12 2BX 377 GB 379 Email: dave.cridland@isode.com 381 Full Copyright Statement 383 Copyright (C) The IETF Trust (2008). 385 This document is subject to the rights, licenses and restrictions 386 contained in BCP 78, and except as set forth therein, the authors 387 retain all their rights. 389 This document and the information contained herein are provided on an 390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 397 Intellectual Property 399 The IETF takes no position regarding the validity or scope of any 400 Intellectual Property Rights or other rights that might be claimed to 401 pertain to the implementation or use of the technology described in 402 this document or the extent to which any license under such rights 403 might or might not be available; nor does it represent that it has 404 made any independent effort to identify any such rights. Information 405 on the procedures with respect to rights in RFC documents can be 406 found in BCP 78 and BCP 79. 408 Copies of IPR disclosures made to the IETF Secretariat and any 409 assurances of licenses to be made available, or the result of an 410 attempt made to obtain a general license or permission for the use of 411 such proprietary rights by implementers or users of this 412 specification can be obtained from the IETF on-line IPR repository at 413 http://www.ietf.org/ipr. 415 The IETF invites any interested party to bring to its attention any 416 copyrights, patents or patent applications, or other proprietary 417 rights that may cover technology that may be required to implement 418 this standard. Please address the information to the IETF at 419 ietf-ipr@ietf.org.