[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                                  Aoyama Gakuin University
Expires: September 7, 2006                                 March 6, 2006


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

Status of this Memo

    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 becomes
    aware will be disclosed, in accordance with Section 6 of BCP 79.

    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 September 7, 2006.

Copyright Notice

    Copyright (C) The Internet Society (2006).

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 September 7, 2006               [Page 1]

Internet-Draft    The Archived-At Message Header Field        March 2006


Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.  Header Field Definition  . . . . . . . . . . . . . . . . . . .  3
      2.1.  Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  3
      2.2.  Multiple Archived-At Header Fields . . . . . . . . . . . .  4
      2.3.  Interaction with Message Fragmentation and Reassembly  . .  4
      2.4.  Syntax Extension for Internationalized Message Headers . .  4
      2.5.  The X-Archived-At Header Field . . . . . . . . . . . . . .  5
    3.  Implementation and Usage Considerations  . . . . . . . . . . .  5
      3.1.  Formats of Archived Message  . . . . . . . . . . . . . . .  5
      3.2.  Implementation Considerations  . . . . . . . . . . . . . .  5
      3.3.  Usage Considerations . . . . . . . . . . . . . . . . . . .  6
    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
      5.1.  Registration of the Archive-At Header Field  . . . . . . .  8
      5.2.  Registration of the X-Archived-At Header Field . . . . . .  8
    6.  Change Log . . . . . . . . . . . . . . . . . . . . . . . . . .  9
      6.1.  Changes from -04.txt to -05.txt  . . . . . . . . . . . . .  9
      6.2.  Changes from -03.txt to -04.txt  . . . . . . . . . . . . .  9
      6.3.  Changes from -02.txt to -03.txt  . . . . . . . . . . . . .  9
    7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
      8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
    Intellectual Property and Copyright Statements . . . . . . . . . . 13
























Duerst                  Expires September 7, 2006               [Page 2]

Internet-Draft    The Archived-At Message Header Field        March 2006


1.  Introduction

    [RFC2369] defines a number of header fields that can be added to
    Internet messages such as those sent by email distribution lists or
    in netnews [RFC1036].  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 3.3.  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.  Header Field Definition

2.1.  Syntax

    For the Archived-At header field, the field name is 'Archived-At'.
    The field body consist of an URI [STD66] enclosed in angle brackets
    ('<', '>').  The URI MAY contain folding white space FWS, [RFC2822]),
    which is ignored.  MTAs MUST NOT insert whitespace within the angle
    brackets, but client applications SHOULD ignore any whitespace, which
    might have been inserted by poorly behaved MTAs.  The URI points to
    an archived version of the message.  See Section 3.1 for some more
    details.

    This header field is subject to the encoding and character
    restrictions for mail headers as described in [RFC2822].

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

       archived-at = "Archived-At:" [FWS] "<" URI ">" CRLF

    where URI is defined in [STD66] and CRLF and FWS are defined in
    [RFC2822].






Duerst                  Expires September 7, 2006               [Page 3]

Internet-Draft    The Archived-At Message Header Field        March 2006


    Please note that the above ABNF does not take into account FWS within
    URI; an ABNF that does take FWS into account, but does not describe
    the URI syntax restrictions, is provided here:
       archived-at-alt = "Archived-At:" [FWS] '<' unstructured '>' CRLF

    This syntax is kept simple in that only one URI per header field is
    allowed.  In this point, the syntax is different from [RFC2369].
    Also, comments are not allowed.

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

2.3.  Interaction with Message Fragmentation and Reassembly

    [RFC2046] allows for the fragmentation and reassembly of messages.
    Archived-At header fields are to be treated in the same way as
    Comment header fields, i.e. copied to the first fragment message
    header on fragmentation and back from there to the header of the
    reassembled message.

    This treatement has been choosen for compatibility with existing
    infrastructure.  It means that Archived-At header fields in the first
    fragment message MAY refer to an archived version of the whole,
    unfragmented, message.  To avoid confusion, Archived-At headers
    SHOULD NOT be added to fragment messages.

2.4.  Syntax Extension for Internationalized Message Headers

    There are some efforts to allow non-ASCII text directly in message
    header field bodies.  In such contexts, the URI non-terminal in the
    syntax defined in Section 2.1 is to be replaced by IRI as defined in
    [RFC3987].  For conversion between URIs and IRIs, the procedures
    defined in [RFC3987] are to be applied.




Duerst                  Expires September 7, 2006               [Page 4]

Internet-Draft    The Archived-At Message Header Field        March 2006


2.5.  The X-Archived-At Header Field

    For backwards compatibility, this document also describes the
    X-Archived-At header field, a precursor of the Archived-At header
    field.  The X-Archived-At header field MAY also be parsed, but SHOULD
    not be generated.

    The following is the syntax of the X-Archived-At header field, in
    ABNF according to (which also defines SP) [RFC4234]:

       obs-archived-at = "X-Archived-At:"  SP URI CRLF ; URI not empty

    The X-Archived-At header field does not allow white space inside the
    URI.


3.  Implementation and Usage Considerations

3.1.  Formats of Archived Message

    There is no restriction on the format used to serve the archived
    message from the URIs in '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.

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



Duerst                  Expires September 7, 2006               [Page 5]

Internet-Draft    The Archived-At Message Header Field        March 2006


    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.

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

    You may want to refer to messages in a non-message context, such as
    on a Web page or in an instant message.  In such a case, you can
    extract the URI from the Archived-At header field, avoiding the
    search for the correct message in the archive.

    You may want to refer to other messages in a message context.
    Refering to a single message is often done by replying to that
    message.  However, when referring to more than one message, providing
    pointers to archived messages is a widespread practice.  The
    Archived-At header field makes it easier to provide these pointers.

    You may want to find messages related to a message at hand.  You may
    not have received the related messages, and therefore need to use an
    archive.  You may also prefer finding related messages in the archive
    rather than in your MUA, because messages in archives may be linked
    in ways not provided by your MUA.  The Archived-At header field
    provides a link to the starting point in the archive from which 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
    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



Duerst                  Expires September 7, 2006               [Page 6]

Internet-Draft    The Archived-At Message Header Field        March 2006


    software if such use is found helpful.


4.  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 is harmless when received
    directly, but that produces problems when accessed via the URI.  One
    reason for this may be the format used in the archive, where some
    content was not adequately escaped.

    The Archived-At header field points to some archived form of the
    message itself.  This in turn may contain the Archived-At field.
    This creates a potential for a denial-of-service attack on the server
    pointed to by the URI in the Archived-At header field.  The
    conditions are that the archived form of the message is downloaded
    automatically, and that 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.  Second, appropriate
    measures for loop detection should be used.


5.  IANA Considerations






















Duerst                  Expires September 7, 2006               [Page 7]

Internet-Draft    The Archived-At Message Header Field        March 2006


5.1.  Registration of the Archive-At Header Field

    IANA is herewith requested to register the Archived-At header field
    in the Message Header Fields Registry ([RFC3864]) 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-05.txt
          (Note to RFC Editor: Replace this with
           RFC YYYY (RFC number of this specification))

       Related information:
          none

5.2.  Registration of the X-Archived-At Header Field

    IANA is herewith requested to register the Archived-At header field
    in the Message Header Fields Registry ([RFC3864]) as follows:

       Header field name:
          X-Archived-At

       Applicable protocol:
          mail (RFC 2822), optionally also netnews (RFC 1036)

       Status:
          deprecated

       Author/Change controller:
          IETF

       Specification document(s):
          Internet-Draft draft-duerst-archived-at-05.txt
          (Note to RFC Editor: Replace this with
           RFC YYYY (RFC number of this specification))

       Related information:



Duerst                  Expires September 7, 2006               [Page 8]

Internet-Draft    The Archived-At Message Header Field        March 2006


          none


6.  Change Log

    Note to RFC Editor: Please remove this whole section before
    publication.

6.1.  Changes from -04.txt to -05.txt

       Small wording adjustments for readability.

       Separated normative and informative references, added reference to
       RFC1036.

       Moved X-Archived-At header into separate section and added
       registration template.

       Clarified syntax: allowed FWS, provided alternate syntax in an
       attempt to describe different syntactic layers, changed single
       quotes to double quotes for literals.

       Added section about message fragmentation.

       Reorganized document to reduce number of top-level sections.

       Added section about IRIs.

       Removed reference to 'safe' URI characters (no longer a term used
       in URI spec).

       Removed "URI not empty" comment in ABNF: URI according to STD66
       has to contain a scheme part anyway because it is absolute.

6.2.  Changes from -03.txt to -04.txt

       Updated from RFC 2234 to RFC 4234.

       Updated author's address/affiliation.

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





Duerst                  Expires September 7, 2006               [Page 9]

Internet-Draft    The Archived-At Message Header Field        March 2006


       Added reference to RFC 2119 (keywords)

       Changed "MUST" to "SHOULD" for existence of message


7.  Acknowledgements

    The members of the W3C system team, in particular Gerald Oskoboiny,
    Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, 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 Frank Ellermann, Arnt
    Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith
    Moore, has led to further improvements of the proposal.


8.  References

8.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

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

    [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
               Identifiers (IRIs)", RFC 3987, January 2005.

    [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", RFC 4234, October 2005.

    [STD66]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66,
               RFC 3986, January 2005.

8.2.  Informative References

    [RFC1036]  Horton, M. and R. Adams, "Standard for Interchange of
               USENET Messages", December 1987.

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



Duerst                  Expires September 7, 2006              [Page 10]

Internet-Draft    The Archived-At Message Header Field        March 2006


               November 1996.

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














































Duerst                  Expires September 7, 2006              [Page 11]

Internet-Draft    The Archived-At Message Header Field        March 2006


Author's Address

    Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever
                  possible, for example as "D&#252;rst" in XML and HTML.)
    Aoyama Gakuin University
    5-10-1 Fuchinobe
    Sagamihara, Kanagawa  229-8558
    Japan

    Phone: +81 42 759 6329
    Fax:   +81 42 759 6495
    Email: mailto:duerst@it.aoyama.ac.jp
    URI:   http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/






































Duerst                  Expires September 7, 2006              [Page 12]

Internet-Draft    The Archived-At Message Header Field        March 2006


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 (2006).  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 September 7, 2006              [Page 13]


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