doc: Add RFC documents

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]
+