Network Working Group M. Duerst Internet-Draft W3C/Keio University Expires: August 22, 2005 February 21, 2005 The Archived-At Message Header Field draft-duerst-archived-at-03 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on August 22, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. Duerst Expires August 22, 2005 [Page 1] Internet-Draft The Archived-At Message Header Field February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Syntax Definition . . . . . . . . . . . . . . . . . . . . . . 3 3. Multiple Archived-At Header Fields . . . . . . . . . . . . . . 4 4. Formats of Archived Message . . . . . . . . . . . . . . . . . 4 5. Implementation Considerations . . . . . . . . . . . . . . . . 4 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Changes from -02.txt to -03.txt . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . 9 Duerst Expires August 22, 2005 [Page 2] Internet-Draft The Archived-At Message Header Field February 2005 1. Introduction [RFC2369] defines a number of header fields that can be added to email messages sent by email distribution lists. One of them is the 'List-Archive' header field that describes how to access archives for the list. This allows to access the archives as a whole, but not the individual message. There is often a need or desire to refer to the archived form of a single message. For more detailled usage scenarios, please see Section 6. This memo defines a new header, 'Archived-At', to refer to a single message at an archived location. This can help to find a message to a mailing list in the archive of that mailing list much more quickly and directly. It can also be used independently of mailing lists, for example in connection with legal requirements to archive certain messages. In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. Syntax Definition The name of the header field is 'Archived-At'. The content of the header field mostly consist of an URI [STD66] enclosed in angle brackets ('<', '>'), with internal whitespace being ignored. MTAs MUST NOT insert whitespace within the angle brackets, but client applications should treat any whitespace, which might have been inserted by poorly behaved MTAs, as characters to ignore. The URI points to an archived version of the message. See Section 4 for some more details. This header field is subject to the encoding and character restrictions for mail headers as described in [RFC2822]. Additionally, the URI content is further restricted to the set of URI safe characters [STD66]. More formally, the header field is defined as follows in ABNF according to [RFC2234]: archived-at = "Archived-At:" *WSP '<' URI '>' CRLF ; URI not empty where URI is defined in [STD66] and CRLF and WSP are defined in [RFC2234]. For backward-compatibility, the following MAY also be parsed (but MUST not be generated): Duerst Expires August 22, 2005 [Page 3] Internet-Draft The Archived-At Message Header Field February 2005 obs-archived-at = "X-Archived-At:" *WSP URI CRLF ; URI not empty This syntax is kept simple in that only one URI per header field is allowed. In this point, the syntax is different from [RFC2369]. 3. Multiple Archived-At Header Fields Each Archived-At header field only contains a single URI. If it is desired to list multiple URIs where an archived copy of the message can be found, a separate Archived-At field is required for each URI. Multiple Archived-At header fields with the same URI SHOULD be avoided. An Archived-At header field SHOULD only be created if the message is actually being made available at the URI given in the header field. If a message is forwarded from a list to a sublist, and both lists support adding the Archived-At header field, then the sublist SHOULD add a new Archived-At header field without removing the already existing one(s), unless the header field is exactly the same as an already existing one, in which case the new header field SHOULD NOT be added. 4. Formats of Archived Message There is no restriction on the format used to serve the archived message from the URI in the 'Archived-At' header field. It is expected that in many cases, the archived message will be served as (X)HTML, as plain text, or in their original form as message/rfc822 [RFC2046]. Some forms of URIs may imply the format in which the archived message is served, although this should not be relied upon. If the protocol used to retrieve the message allows for content negotiation, then it is also possible to serve the archived message in several different formats. As an example, a HTTP URI in an 'Archived-At' header may allow to serve the archived message both as text/html for human consumption in a browser and as message/rfc822 for use by a mail user agent without loss of information. 5. Implementation Considerations This section shortly discusses some implementation and usage considerations. Mailing list expanders and email archives are often separate pieces of software. It may therefore be difficult to create an 'Archived-At' header field in the mailing list expander software. One way to address this difficulty is to have the mailing list expander software generate an unambiguous URI, e.g. an URI based on the message id of the incoming email, and to set up the archiving Duerst Expires August 22, 2005 [Page 4] Internet-Draft The Archived-At Message Header Field February 2005 system so that it redirects requests for such URIs to the actual messages. Such a system has been implemented and is in productive use at W3C. As an example, the URI "http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com", containing significant part of the message id "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI of this message in the W3C mailing-list archive at http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html. Source code for this implementation is available at http://dev.w3.org/cvsweb/search/, in particular http://dev.w3.org/cvsweb/search/cgi/mid.pl and http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. When using the message id to create an address for the archived mail, care has to be taken to escape characters in the message id that are not allowed in the URI, or to remove them, as done above for the "<" and ">" delimiters. 6. Usage Considerations It may at first seem strange to have a pointer to an archived form of a message in a header field of that same message. After all, if one has the message, why would one need a pointer to it? It turns out that such pointers can be extremely useful. This section describes some of the scenarios for their use. One may want to refer to messages in a non-message context, such as on a Web page or in an instant messaging context. In such a case, being able to take the URI out of the Archived-At header avoids having to search the correct message in the archive. One may want to refer to other messages in a message context. While refering to a single message is often done by replying to that message, when referring to more than one message, providing a pointer to these messages is a widespread practice. The Archived-At header makes it easier to provide these pointers. One may want to find related messages, for which one may need to go to the archive if one has not received potentially related messages. Also, it may often be easier to find related messages in an archive than in an email client. The Archived-At header makes it easier to find the starting point in the archive to find related messages. Please note that in the above usage scenarios, it is mostly the human reader, rather than the email client software, that makes use of the Duerst Expires August 22, 2005 [Page 5] Internet-Draft The Archived-At Message Header Field February 2005 URI in the Archived-At header. However, this does not rule out the use of the URI in the Archived-At header by the email client or other software if such use is found helpful. 7. Security Considerations There are many potential security issues when activating and dereferencing an URI. For more details, please see [STD66]. In the context of this proposal, the following are particularly relevant: An intruder may get access to the message transmission and be able to insert an URI pointing to some malicious content. Also, somebody may be able to construct a message that when received directly is harmless, but that when accessed via the URI produces some problems because in the format used in the archive, some content has not been adequately escaped. Because the Archived-At header field points to some archived form of the message itself, which in turn may contain the Archived-At field, there is a potential for a denial-of-service attack on the server pointed to by the URI in the Archived-At header field if the archived form of the message is downloaded automatically, and further URIs in that message are followed and downloaded recursively without checking for already downloaded resources. However, this kind of scenario can easily be avoided by implementations. First, the URI in the Archived-At header field should not be dereferenced automatically, and second, appropriate measures for loop detection should be used. Duerst Expires August 22, 2005 [Page 6] Internet-Draft The Archived-At Message Header Field February 2005 8. IANA considerations IANA is herewith requested to register the Archived-At header field in the Message Header Fields Registry as follows: Header field name: Archived-At Applicable protocol: mail (RFC 2822), optionally also netnews (RFC 1036) Status: standard Author/Change controller: IETF Specification document(s): Internet-Draft draft-duerst-archived-at-02.txt (Note to RFC Editor: Replace this with RFC YYYY (RFC number of this spec)) Related information: none 9. Change Log 9.1 Changes from -02.txt to -03.txt Fixed syntax to allow spaces after colon. Avoided misunderstanding with message ids ('<' and '>' are part of the message id) Added reference to RFC 2119 (keywords) Changed "MUST" to "SHOULD" for existence of message 10. Acknowledgements The members of the W3C system team, in particular Gerald Oskoboiny, Olivier Thereaux, and Jose Kahan, created the mid-based email archive lookup system and the experimental form of the Archived-At header. Pete Resnik provided the motivation for writing up this memo. Discussion on the ietf-822@imc.org mailing list, in particular contributions by Arnt Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Moore, has led to further improvements of the Duerst Expires August 22, 2005 [Page 7] Internet-Draft The Archived-At Message Header Field February 2005 proposal. 11 Normative References [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2369] Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3864] Klyne, G., Nottingham, M. and J. Mogul, "Registration Procedures for Message Header Fields", RFC 3864, BCP 90, September 2004. [STD66] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Author's Address Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) World Wide Web Consortium/Keio University 5322 Endo Fujisawa, Kanagawa 252-8520 Japan Phone: +81 466 49 1170 Fax: +81 466 49 1171 EMail: mailto:duerst@w3.org URI: http://www.w3.org/People/D%C3%BCrst/ Duerst Expires August 22, 2005 [Page 8] Internet-Draft The Archived-At Message Header Field February 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Duerst Expires August 22, 2005 [Page 9]