< draft-duerst-archived-at-08.txt   draft-duerst-archived-at-09.txt >
Network Working Group M. Duerst Network Working Group M. Duerst
Internet-Draft Aoyama Gakuin University Internet-Draft Aoyama Gakuin University
Intended status: Standards Track August 20, 2007 Intended status: Standards Track August 21, 2007
Expires: February 21, 2008 Expires: February 22, 2008
The Archived-At Message Header Field The Archived-At Message Header Field
draft-duerst-archived-at-08 draft-duerst-archived-at-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 21, 2008. This Internet-Draft will expire on February 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This memo defines a new email header field, Archived-At:, to provide This memo defines a new email header field, Archived-At:, to provide
a direct link to the archived form of an individual email message. a direct link to the archived form of an individual email message.
skipping to change at page 2, line 23 skipping to change at page 2, line 23
2.5. The X-Archived-At Header Field . . . . . . . . . . . . . . 5 2.5. The X-Archived-At Header Field . . . . . . . . . . . . . . 5
3. Implementation and Usage Considerations . . . . . . . . . . . 5 3. Implementation and Usage Considerations . . . . . . . . . . . 5
3.1. Formats of Archived Message . . . . . . . . . . . . . . . 5 3.1. Formats of Archived Message . . . . . . . . . . . . . . . 5
3.2. Implementation Considerations . . . . . . . . . . . . . . 5 3.2. Implementation Considerations . . . . . . . . . . . . . . 5
3.3. Usage Considerations . . . . . . . . . . . . . . . . . . . 6 3.3. Usage Considerations . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5.1. Registration of the Archive-At Header Field . . . . . . . 8 5.1. Registration of the Archive-At Header Field . . . . . . . 8
5.2. Registration of the X-Archived-At Header Field . . . . . . 8 5.2. Registration of the X-Archived-At Header Field . . . . . . 8
6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Changes from -07.txt to -08.txt . . . . . . . . . . . . . 9 6.1. Changes from -08.txt to -09.txt . . . . . . . . . . . . . 9
6.2. Changes from -06.txt to -07.txt . . . . . . . . . . . . . 10 6.2. Changes from -07.txt to -08.txt . . . . . . . . . . . . . 9
6.3. Changes from -05.txt to -06.txt . . . . . . . . . . . . . 10 6.3. Changes from -06.txt to -07.txt . . . . . . . . . . . . . 10
6.4. Changes from -04.txt to -05.txt . . . . . . . . . . . . . 10 6.4. Changes from -05.txt to -06.txt . . . . . . . . . . . . . 10
6.5. Changes from -03.txt to -04.txt . . . . . . . . . . . . . 11 6.5. Changes from -04.txt to -05.txt . . . . . . . . . . . . . 10
6.6. Changes from -02.txt to -03.txt . . . . . . . . . . . . . 11 6.6. Changes from -03.txt to -04.txt . . . . . . . . . . . . . 11
6.7. Changes from -02.txt to -03.txt . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
1. Introduction 1. Introduction
[RFC2369] defines a number of header fields that can be added to [RFC2369] defines a number of header fields that can be added to
skipping to change at page 5, line 46 skipping to change at page 5, line 46
information. information.
3.2. Implementation Considerations 3.2. Implementation Considerations
Mailing list expanders and email archives are often separate pieces Mailing list expanders and email archives are often separate pieces
of software. It may therefore be difficult to create an of software. It may therefore be difficult to create an
'Archived-At' header field in the mailing list expander software. 'Archived-At' header field in the mailing list expander software.
One way to address this difficulty is to have the mailing list One way to address this difficulty is to have the mailing list
expander software generate an unambiguous URI, e.g. an URI based on 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 the message identifier of the incoming email, and to set up the
system so that it redirects requests for such URIs to the actual archiving system so that it redirects requests for such URIs to the
messages. actual messages. If the email does not contain a message identifier,
a unique identifier can be generated.
Such a system has been implemented and is in productive use at W3C. Such a system has been implemented and is in productive use at W3C.
As an example, the URI As an example, the URI
"http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com", "http://www.w3.org/mid/0I5U00G08DFGCR@mailsj-v1.corp.adobe.com",
containing the significant part of the message id containing the significant part of the message identifier
"<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI "<0I5U00G08DFGCR@mailsj-v1.corp.adobe.com>", is redirected to the URI
of this message in the W3C mailing-list archive at of this message in the W3C mailing-list archive at
http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html. http://lists.w3.org/Archives/Public/uri/2004Oct/0017.html.
Source code for this implementation is available at Source code for this implementation is available at
http://dev.w3.org/cvsweb/search/, in particular http://dev.w3.org/cvsweb/search/, in particular
http://dev.w3.org/cvsweb/search/cgi/mid.pl and http://dev.w3.org/cvsweb/search/cgi/mid.pl and
http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. These locations may http://dev.w3.org/cvsweb/search/bin/msgid-db.pl. These locations may
be subject to change. be subject to change.
When using the message id to create an address for the archived mail, When using the message identifier to create an address for the
care has to be taken to escape characters in the message id that are archived mail, care has to be taken to escape characters in the
not allowed in the URI, or to remove them, as done above for the "<" message identifier that are not allowed in the URI, or to remove
and ">" delimiters. them, as done above for the "<" and ">" delimiters.
Implementations such as that described above can introduce a security Implementations such as that described above can introduce a security
issue. Somebody might deliberately reuse a message id to break the issue. Somebody might deliberately reuse a message identifier to
link to a message. This can be addressed by checking incoming break the link to a message. This can be addressed by checking
message ids against those of the messages already in the archive and incoming message identifiers against those of the messages already in
discarding incoming duplicates, by checking the content of incomming the archive and discarding incoming duplicates, by checking the
duplicates and discarding them if they are significantly different content of incoming duplicates and discarding them if they are
from the first message, by offering multiple choices in the response significantly different from the first message, by offering multiple
to the URI, or by using some authentication mechanism on incomming choices in the response to the URI, or by using some authentication
messages. mechanism on incoming messages.
3.3. Usage Considerations 3.3. Usage Considerations
It may at first seem strange to have a pointer to an archived form of 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 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 has the message, why would one need a pointer to it? It turns out
that such pointers can be extremely useful. This section describes that such pointers can be extremely useful. This section describes
some of the scenarios for their use. some of the scenarios for their use.
A user may want to refer to messages in a non-message context, such A user may want to refer to messages in a non-message context, such
skipping to change at page 7, line 45 skipping to change at page 7, line 47
pointed to by the URI in the Archived-At header field. The pointed to by the URI in the Archived-At header field. The
conditions are that the archived form of the message is downloaded conditions are that the archived form of the message is downloaded
automatically, and that further URIs in that message are followed and automatically, and that further URIs in that message are followed and
downloaded recursively without checking for already downloaded downloaded recursively without checking for already downloaded
resources. However, this kind of scenario can easily be avoided by resources. However, this kind of scenario can easily be avoided by
implementations. First, the URI in the Archived-At header field implementations. First, the URI in the Archived-At header field
should not be dereferenced automatically. Second, appropriate should not be dereferenced automatically. Second, appropriate
measures for loop detection should be used. measures for loop detection should be used.
In Section 3.2, an attack is described that may break an URI to a In Section 3.2, an attack is described that may break an URI to a
message by introducing a new message with the same message id. message by introducing a new message with the same message
Possible countermeasures are also discussed. identifier. Possible countermeasures are also discussed.
5. IANA Considerations 5. IANA Considerations
5.1. Registration of the Archive-At Header Field 5.1. Registration of the Archive-At Header Field
IANA is herewith requested to register the Archived-At header field IANA is herewith requested to register the Archived-At header field
in the Message Header Fields Registry ([RFC3864]) as follows: in the Message Header Fields Registry ([RFC3864]) as follows:
Header field name: Header field name:
Archived-At Archived-At
skipping to change at page 9, line 33 skipping to change at page 9, line 33
RFC YYYY (RFC number of this specification)) RFC YYYY (RFC number of this specification))
Related information: Related information:
none none
6. Change Log 6. Change Log
Note to RFC Editor: Please remove this whole section before Note to RFC Editor: Please remove this whole section before
publication. publication.
6.1. Changes from -07.txt to -08.txt 6.1. Changes from -08.txt to -09.txt
Fixed some typos.
Changed from "message id" to more correct "message identifier".
Added a sentence to cover the case of messages without message
identifiers.
6.2. Changes from -07.txt to -08.txt
Replaced 'you' by 'a user' in usage considerations section. Replaced 'you' by 'a user' in usage considerations section.
Added a note to say that URIs may not be permanent for pointers to Added a note to say that URIs may not be permanent for pointers to
example implementation in "Implementation Considerations" section. example implementation in "Implementation Considerations" section.
Improved advice on countermeasures for the security issue in Improved advice on countermeasures for the security issue in
Section 3.2. Section 3.2.
Removed a superfluous sentence. Removed a superfluous sentence.
Added some discussion of countermeasures to the first security Added some discussion of countermeasures to the first security
issue in the security section (first paragraph). issue in the security section (first paragraph).
Updated acknoledgments. Updated acknoledgments.
6.2. Changes from -06.txt to -07.txt 6.3. Changes from -06.txt to -07.txt
Changed ABNF to introduce the folded-URI rule. Changed ABNF to introduce the folded-URI rule.
Added text about a security issue to , and mentioned it in the Added text about a security issue to , and mentioned it in the
security section. (Section 3.2) security section. (Section 3.2)
Updated reference to netnews format. Updated reference to netnews format.
Some wording improvements. Some wording improvements.
6.3. Changes from -05.txt to -06.txt 6.4. Changes from -05.txt to -06.txt
Removed 'also optionally' for netnews. Removed 'also optionally' for netnews.
Improved explanation in section about IRIs. Improved explanation in section about IRIs.
Some wording improvements. Some wording improvements.
6.4. Changes from -04.txt to -05.txt 6.5. Changes from -04.txt to -05.txt
Small wording adjustments for readability. Small wording adjustments for readability.
Separated normative and informative references, added reference to Separated normative and informative references, added reference to
RFC1036. RFC1036.
Moved X-Archived-At header into separate section and added Moved X-Archived-At header into separate section and added
registration template. registration template.
Clarified syntax: allowed FWS, provided alternate syntax in an Clarified syntax: allowed FWS, provided alternate syntax in an
skipping to change at page 11, line 5 skipping to change at page 11, line 8
Reorganized document to reduce number of top-level sections. Reorganized document to reduce number of top-level sections.
Added section about IRIs. Added section about IRIs.
Removed reference to 'safe' URI characters (no longer a term used Removed reference to 'safe' URI characters (no longer a term used
in URI spec). in URI spec).
Removed "URI not empty" comment in ABNF: URI according to STD66 Removed "URI not empty" comment in ABNF: URI according to STD66
has to contain a scheme part anyway because it is absolute. has to contain a scheme part anyway because it is absolute.
6.5. Changes from -03.txt to -04.txt 6.6. Changes from -03.txt to -04.txt
Updated from RFC 2234 to RFC 4234. Updated from RFC 2234 to RFC 4234.
Updated author's address/affiliation. Updated author's address/affiliation.
6.6. Changes from -02.txt to -03.txt 6.7. Changes from -02.txt to -03.txt
Fixed syntax to allow spaces after colon. Fixed syntax to allow spaces after colon.
Avoided misunderstanding with message ids ('<' and '>' are part of Avoided misunderstanding with message ids ('<' and '>' are part of
the message id) the message id)
Added reference to RFC 2119 (keywords) Added reference to RFC 2119 (keywords)
Changed "MUST" to "SHOULD" for existence of message Changed "MUST" to "SHOULD" for existence of message
7. Acknowledgments 7. Acknowledgments
The members of the W3C system team, in particular Gerald Oskoboiny, The members of the W3C system team, in particular Gerald Oskoboiny,
Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, created the Olivier Thereaux, Jose Kahan, and Eric Prud'hommeaux, created the
mid-based email archive lookup system and the experimental form of mid-based email archive lookup system and the experimental form of
the Archived-At header. Pete Resnik provided the motivation for the Archived-At header. Pete Resnik provided the motivation for
writing up this memo. Discussion on the ietf-822@imc.org mailing writing up this memo. Discussion on the ietf-822@imc.org mailing
list, in particular contributions by Frank Ellermann, Arnt list, in particular contributions by Frank Ellermann, Arnt
Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith Gulbrandsen, Graham Klyne, Bruce Lilly, Charles Lindsey, and Keith
Moore, has led to further improvements of the proposal. Chris Moore, has led to further improvements of the proposal. Chris
Newman, Chris Lonvick, Stephane Borzmeyer, and Vijay K. Gurbani Newman, Chris Lonvick, Stephane Borzmeyer, Vijay K. Gurbani, and S.
provided additional valuable comments. Moonesamy provided additional valuable comments.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001. April 2001.
 End of changes. 17 change blocks. 
36 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/