draft-melnikov-imap-content-location-00.txt M. Crispin Expires: December 2002 University of Washington S. Hole A. Melnikov ACI WorldWide/MessagingDirect June 2002 An extension to IMAP BODYSTRUCTURE for returning Content-Location information draft-melnikov-imap-content-location-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society 2002. All Rights Reserved. 0.1. Open issues Other open issues are enclosed in << and >> in the relevant places of this document. 0.2. Change History Table of Contents <<To be completed later>> 1. Abstract The [IMAP4] BODYSTRUCTURE FETCH data item allows a client to learn about the MIME structure of a message without the need to download the entire message. This document extends the syntax of the [IMAP4] BODYSTRUCTURE FETCH response data item to include information from the Content-Location header field described in [MHTML]. This extension helps MHTML-aware IMAP clients to save both the number of round trips and the amount of information sent across the network. Fallback strategies are also discussed when an IMAP server doesn't support this extension. 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. In examples, lines beginning with "S:" are sent by the IMAP server, and lines beginning with "C:" are sent by the client. Line breaks may appear in example commands solely for editorial clarity; when present in the actual message they are represented by "<CRLF>". Space character may be represented in examples as "<SPACE>". The formal syntax is defined using ABNF [ABNF]. 3. IMAP Protocol Changes This document adds an additional element to the BODYSTRUCTURE FETCH response described in 7.4.2 of [IMAP4]. The extension data of a multipart body part is extended to add a new element "body location" after the "body language": body location A string giving the content location URI as specified in the Content-Location MIME header field [MHTML]. The extension data of a non-multipart body part is extended to add a new element "body location" after the "body language": body location A string giving the content location URI as specified in Content-Location MIME header field [MHTML]. Example: S: * 1 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii") <SPACE>NIL NIL "7BIT" 323 14 NIL NIL NIL NIL)("TEXT" "HTML"<SPACE> ("CHARSET" "iso-8859-1") NIL NIL "QUOTED-PRINTABLE" 50578<SPACE> 1111 NIL NIL NIL "http://home.netscape.com/")<SPACE> "MIXED" ("BOUNDARY" "------------8FC7BFAA529B4689FD642892")<SPACE> NIL NIL NIL)) If the server doesn't return Content-Location information in a BODYSTRUCTURE FETCH response, the client should issue one or more FETCHes that contain "BODY.PEEK[HEADER.FIELDS (Content-Location)]" for the root part, "BODY.PEEK[<section#>.HEADER.FIELDS (Content-Location)]" for a MESSAGE/RFC822 part and "BODY.PEEK[<section#>.MIME]" for all other parts. Of course, "BODY.PEEK[<nnn>HEADER]" (or HEADER.FIELDS that includes Content-Location) can be use instead of "BODY.PEEK[<nnn>HEADER.FIELDS (Content-Location)]" if it is desired to get other header fields. Example: C: A141 FETCH 1:* BODYSTRUCTURE S: * 1 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii") <SPACE>NIL NIL "7BIT" 323 14 NIL NIL NIL)("TEXT" "HTML"<SPACE> ("CHARSET" "iso-8859-1") NIL NIL "QUOTED-PRINTABLE" 50578<SPACE> 1111 NIL NIL NIL) "MIXED"<SPACE> ("BOUNDARY" "------------8FC7BFAA529B4689FD642892")<SPACE> NIL NIL)) ... S: A141 OK done! ;;; The server did not return a Content-Location in the BODYSTRUCTURE, so we ;;; must fetch it manually from the header field: C: A142 FETCH 1 (BODY.PEEK[HEADER.FIELDS (Content-Location)]<SPACE> BODY.PEEK[1.MIME] BODY.PEEK[2.MIME]) S: * 1 FETCH (BODY[HEADER.FIELDS (Content-Location)] {2}<CRLF><CRLF> <SPACE>BODY[1.MIME] {79}<CRLF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit<CRLF> <SPACE>BODY[2.MIME] {182}<CRLF> Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Base: "http://home.netscape.com/" Content-Location: "http://home.netscape.com/"<CRLF><CRLF>) S: A142 OK done! A client must be able to deal with empty responses from "BODY[HEADER.FIELDS (Content-Location)]" and treat them as missing Content-Location header fields. 4. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined by [IMAP4]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] body-fld-loc = nstring ; NIL if Content-Location header is not present, ; has a syntax of URI otherwise 5. Security Considerations This document doesn't raise any new security concernes not already discussed in [IMAP4] and [MHTML]. 6. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, November 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", update to RFC 2060 in progress, University of Washington. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [MHTML] Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm University/KTH, Microsoft Corporation, Lotus Development Corporation, March 1999. 7. Acknowledgments <<to be completed when appropriate>> 8. Author's Addresses Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527 Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU Steve Hole ACI WorldWide/MessagingDirect #900, 10117 Jasper Avenue, Edmonton, Alberta, T5J 1W8, CANADA EMail: Steve.Hole@messagingdirect.com Alexey Melnikov ACI WorldWide/MessagingDirect 22 The Quadrant, Richmond, Surrey TW9 1BP, United Kingdom EMail: Alexey.Melnikov@messagingdirect.com 9. Full Copyright Statement Copyright (C) The Internet Society 2002. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.