summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5064.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5064.txt')
-rw-r--r--doc/rfc/rfc5064.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc5064.txt b/doc/rfc/rfc5064.txt
new file mode 100644
index 0000000..0921e9e
--- /dev/null
+++ b/doc/rfc/rfc5064.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group M. Duerst
+Request for Comments: 5064 Aoyama Gakuin University
+Category: Standards Track December 2007
+
+
+ The Archived-At Message Header Field
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+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.
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Header Field Definition .........................................2
+ 2.1. Syntax .....................................................2
+ 2.2. Multiple Archived-At Header Fields .........................3
+ 2.3. Interaction with Message Fragmentation and Reassembly ......3
+ 2.4. Syntax Extension for Internationalized Message Headers .....3
+ 2.5. The X-Archived-At Header Field .............................4
+ 3. Implementation and Usage Considerations .........................4
+ 3.1. Formats of Archived Message ................................4
+ 3.2. Implementation Considerations ..............................4
+ 3.3. Usage Considerations .......................................5
+ 4. Security Considerations .........................................6
+ 5. IANA Considerations .............................................7
+ 5.1. Registration of the Archive-At Header Field ................7
+ 5.2. Registration of the X-Archived-At Header Field .............7
+ 6. Acknowledgments .................................................8
+ 7. References ......................................................8
+ 7.1. Normative References .......................................8
+ 7.2. Informative References .....................................8
+
+
+
+
+
+
+
+
+
+
+Duerst Standards Track [Page 1]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+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
+ access to the archives as a whole, but not an individual message.
+
+ There is often a need or desire to refer to the archived form of a
+ single message. For more detailed 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 provides quick
+ access to the location of a mailing list message in the list archive.
+ 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 a URI [STD66] enclosed in angle brackets
+ ('<', '>'). The URI MAY contain folding whitespace (FWS, [RFC2822]),
+ which is ignored. Mail Transfer Agents (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 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 Augmented
+ BNF (ABNF) according to [RFC4234]:
+
+ archived-at = "Archived-At:" [FWS] "<" folded-URI ">" CRLF
+ folded-URI = <URI, but free insertion of FWS permitted>
+
+ where URI is defined in [STD66], and CRLF and FWS are defined in
+ [RFC2822].
+
+ To convert a folded-URI to a URI, first apply standard [RFC2822]
+ unfolding rules (replacing FWS with a single SP), and then delete any
+ remaining un-encoded SP characters.
+
+
+
+Duerst Standards Track [Page 2]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+ This syntax is kept simple in that only one URI per header field is
+ allowed. In this respect, 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 per URI is required.
+ 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
+ Comments 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 treatment has been chosen 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 an
+ Internationalized Resource Identifier (IRI) as defined in [RFC3987].
+ The specifics of the actual octet encoding of the IRI will follow the
+ rules for general direct encoding of non-ASCII text. For conversion
+ between IRIs and URIs, the procedures defined in [RFC3987] are to be
+ applied.
+
+
+
+
+
+
+Duerst Standards Track [Page 3]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+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 [RFC4234] (which also defines SP):
+
+ obs-archived-at = "X-Archived-At:" SP URI CRLF
+
+ The X-Archived-At header field does not allow whitespace inside 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 URI in an 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 its 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, an HTTP URI in an
+ Archived-At header may make it possible 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 (MUA) without loss of
+ information.
+
+3.2. 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., a URI based on
+ the message identifier of the incoming email, and to set up the
+ archiving system so that it redirects requests for such URIs to the
+ actual messages. If the email does not contain a message identifier,
+ a unique identifier can be generated.
+
+
+
+
+
+
+Duerst Standards Track [Page 4]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+ 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 significant part of the message identifier
+ "<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. These locations may
+ be subject to change.
+
+ When using the message identifier to create an address for the
+ archived mail, care has to be taken to escape characters in the
+ message identifier that are not allowed in the URI, or to remove
+ them, as done above for the "<" and ">" delimiters.
+
+ Implementations such as that described above can introduce a security
+ issue. Somebody might deliberately reuse a message identifier to
+ break the link to a message. This can be addressed by checking
+ incoming message identifiers against those of the messages already in
+ the archive and discarding incoming duplicates, by checking the
+ content of incoming duplicates and discarding them if they are
+ significantly different from the first message, by offering multiple
+ choices in the response to the URI, or by using some authentication
+ mechanism on incoming messages.
+
+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.
+
+ A user may want to refer to messages in a non-message context, such
+ as on a Web page, in an instant message, or in a phone conversation.
+ In such a case, the user can extract the URI from the Archived-At
+ header field, avoiding the search for the correct message in the
+ archive.
+
+ A user may want to refer to other messages in a message context.
+ Referring 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.
+
+
+
+Duerst Standards Track [Page 5]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+ A user may want to find messages related to a message at hand. The
+ user may not have received the related messages, and therefore needs
+ to use an archive. The user may also prefer finding related messages
+ in the archive rather than in her MUA, because messages in archives
+ may be linked in ways not provided by the 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
+ software if such use is found helpful.
+
+4. Security Considerations
+
+ There are many potential security issues when activating and
+ dereferencing a URI. For more details, including some
+ countermeasures, 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 a URI
+ pointing to some malicious content. This can be addressed by using a
+ secured way of message transmission. 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. This can be addressed by using adequate
+ escaping.
+
+ 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.
+
+ In Section 3.2, an attack is described that may break a URI to a
+ message by introducing a new message with the same message
+ identifier. Possible countermeasures are also discussed.
+
+
+
+
+
+
+
+Duerst Standards Track [Page 6]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+5. IANA Considerations
+
+5.1. Registration of the Archive-At Header Field
+
+ IANA has registered the Archived-At header field in the Message
+ Header Fields Registry ([RFC3864]) as follows:
+
+ Header field name:
+ Archived-At
+
+ Applicable protocol:
+ mail (RFC 2822) and netnews (RFC 1036)
+
+ Status:
+ standard
+
+ Author/Change controller:
+ IETF
+
+ Specification document(s):
+ RFC 5064
+
+ Related information:
+ none
+
+5.2. Registration of the X-Archived-At Header Field
+
+ This section is non-normative (specifically, an implementation that
+ ignores this section remains compliant with this specification).
+
+ IANA has registered the X-Archived-At header field in the Message
+ Header Fields Registry ([RFC3864]) as follows:
+
+ Header field name:
+ X-Archived-At
+
+ Applicable protocol:
+ mail (RFC 2822) and netnews (RFC 1036)
+
+ Status:
+ deprecated
+
+ Author/Change controller:
+ IETF
+
+ Specification document(s):
+ RFC 5064
+
+
+
+
+Duerst Standards Track [Page 7]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+ Related information:
+ none
+
+6. Acknowledgments
+
+ 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 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, led to
+ further improvements of the proposal. Chris Newman, Chris Lonvick,
+ Stephane Borzmeyer, Vijay K. Gurbani, and S. Moonesamy provided
+ additional valuable comments.
+
+7. References
+
+7.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., Ed., "Internet Message Format", RFC 2822,
+ April 2001.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ September 2004.
+
+ [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
+ Identifiers (IRIs)", RFC 3987, January 2005.
+
+ [RFC4234] Crocker, D., Ed., 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.
+
+7.2. Informative References
+
+ [RFC1036] Horton, M. and R. Adams, "Standard for interchange of
+ USENET messages", RFC 1036, December 1987.
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ November 1996.
+
+
+
+Duerst Standards Track [Page 8]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+ [RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
+ for Core Mail List Commands and their Transport through
+ Message Header Fields", RFC 2369, July 1998.
+
+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: duerst@it.aoyama.ac.jp
+ URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Duerst Standards Track [Page 9]
+
+RFC 5064 The Archived-At Message Header Field December 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2007).
+
+ 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.
+
+ 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, THE IETF TRUST 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.
+
+Intellectual Property
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Duerst Standards Track [Page 10]
+