[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5064

Network Working Group                                          M. Duerst
Internet-Draft                                       W3C/Keio University
Expires: April 25, 2005                                 October 25, 2004



                  The Archived-At Message Header Field
                      draft-duerst-archived-at-02


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 April 25, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


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 April 25, 2005                 [Page 1]

Internet-Draft    The Archived-At Message Header Field      October 2004



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.   Security Considerations  . . . . . . . . . . . . . . . . . . . 5
   7.   IANA considerations  . . . . . . . . . . . . . . . . . . . . . 6
   8.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
   9.   Normative References . . . . . . . . . . . . . . . . . . . . . 6
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
        Intellectual Property and Copyright Statements . . . . . . . . 8







































Duerst                   Expires April 25, 2005                 [Page 2]

Internet-Draft    The Archived-At Message Header Field      October 2004



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.  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.


2.  Syntax Definition


   The name of the header field is 'Archived-At'.  The content of the
   header field mostly consist of an URI [RFCXXXX] 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 [RFCXXXX].


   More formally, the header field is defined as follows in ABNF
   according to [RFC2234]:


      archived-at = "Archived-At:" '<' URI '>' CRLF ; URI not empty


   where URI is defined in [RFCXXXX] and CRLF is defined in [RFC2234].


   For backward-compatibility, the following MAY also be parsed (but
   MUST not be generated):


      obs-archived-at = "X-Archived-At:" 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].






Duerst                   Expires April 25, 2005                 [Page 3]

Internet-Draft    The Archived-At Message Header Field      October 2004



3.  Multiple Archived-At Header Fields


   If a message is archived at several independent locations, several
   header fields MUST be used.  Multiple Archived-At header fields with
   the same URI SHOULD be avoided.  An Archived-At header field MUST
   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 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 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
   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 the message id "0I5U00G08DFGCR@mailsj-v1.corp.adobe.com",




Duerst                   Expires April 25, 2005                 [Page 4]

Internet-Draft    The Archived-At Message Header Field      October 2004



   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.


6.  Security Considerations


   There are many potential security issues when activating and
   dereferencing an URI.  For more details, please see [RFCXXXX].  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.





























Duerst                   Expires April 25, 2005                 [Page 5]

Internet-Draft    The Archived-At Message Header Field      October 2004



7.  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:
         provisional
         (Note to RFC Editor: Replace this with "standard")


      Author/Change controller:
         Martin Duerst, duerst@w3.org, W3C/Keio University
         (Note to RFC Editor: Replace this with "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


8.  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
   proposal.


9  Normative References


   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.


   [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




Duerst                   Expires April 25, 2005                 [Page 6]

Internet-Draft    The Archived-At Message Header Field      October 2004



              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.


   [RFCXXXX]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax",
              draft-fielding-uri-rfc2396bis-07.txt (work in progress),
              April 2004.



Author's Address


   Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
                 possible, for example as "D&#252;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 April 25, 2005                 [Page 7]

Internet-Draft    The Archived-At Message Header Field      October 2004



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 (2004).  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 April 25, 2005                 [Page 8]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/