Internet-Draft M. Welzl
Intended status: Proposed Standard University of Innsbruck
Expires: January 31, 2009 T. Nolf
University of Innsbruck
J. Palme
Stockholm University / KTH
July 30, 2008
The Expires Header in E-mail
draft-welzl-expires-00.txt
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 January 31, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This memo introduces a new email header called Expires. Using this
header, the sender of an email can state that (s)he believes this
message will be irrelevant after the indicated date/time. The
receiving MUA can then automatically detect that a message has
expired and facilitate handling of such emails for the user.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [i].
The word "client" may in this text designate functionality, which
some implementations actually implement wholly or partly in a server.
For example, in the case of IMAP and NNTP, it is very common to
Welzl, Nolf, Palme Expires - January 2008 [Page 1]
The Expires Header in E-mail July 2008
implement functionality, which logically may be regarded as belonging
to a client, in the server.
The acronym "MUA" is short for "mail user agent", the software that
allows a user to access and manage email.
Table of Contents
1. Introduction...................................................2
2. Syntax.........................................................2
3. Semantics......................................................2
4. Relation to X.400 gateways and Netnews.........................3
Security Considerations...........................................3
References........................................................3
Acknowledgments...................................................4
Author's Addresses................................................4
1. Introduction
This memo introduces a new header field called "Expires" for Internet
email [1] headers, which will enhance the email service. The
intention is to let a sender of an email state a date/time until
which a message will be relevant. Using this header field, the
receiving MUA can then automatically detect that a message has
expired and facilitate handling of such emails for the user.
2. Syntax
This section specifies the syntax of the new field using the ABNF
rules from [2]. The syntax elements are defined in [1].
Expires-field = "Expires:" CFWS date-time [CFWS] CRLF
3. Semantics
The Expires header indicates a date-time at which this message
expires. The exact meaning of "expires" is:
"The sender believes this message will be irrelevant after the
indicated date/time."
This header is intended for use between senders and recipients and
their agents, rather than by message transport. It is suggested that
the default behavior of an MUA with respect to the expires header
field should be to display such a message in a distinguished way. For
Welzl, Nolf, Palme Expires - January 2008 [Page 2]
The Expires Header in E-mail July 2008
example, the message could be displayed with gray text rather than
black, or in a different font than normal, or (in summaries) with an
image of an hourglass with the sand at the bottom.
It is also suggested that MUAs allow setting of an expiration date as
an option when composing messages.
The Expires header is strictly advisory in nature: MUAs, Message
Stores, and MTAs, MUST NOT delete a message on the basis of an
Expired header field unless given explicit instructions to do so by
the recipient. Mail Filters MUST NOT consider an expired header field
as criteria to be considered for deleting the message unless given
explicit instructions to do so by the recipient.
4. Relation to X.400 gateways and Netnews
A similar header to Expires is also defined in recommendations for
gatewaying [3] between X.400 [4] and Internet mail as a renamed
version of what was previously called "Expiry-Date". However, those
recommendations are only valid for gateways. By defining the field
here, it is made available for general Internet email usage. It is
additionally defined in a similar way in netnews [5].
Note that the definition given in this document imposes a stricter
requirement on the field to be advisory than the other definitions:
in [3], the meaning of Expiry is specified as the "time at which a
message loses its validity", and [5] states that the Expires header
field "specifies a date and time when the poster deems the article to
be no longer relevant and could usefully be removed". Such automatic
removal without explicit instructions from the recipient is strictly
forbidden for general Internet mail.
Security Considerations
One intention of "Expires" is to help recipients avoid seeing
messages with information which is not any longer valid. There
may of course be cases where a user might want to see an expired
message (e.g. a user might sometimes want to be informed of a
meeting, even after the time of the meeting). This is the reason for
the requirement that MUAs MUST NOT delete messages on the basis of
the Expires-field unless given explicit instructions to do so by the
recipient.
Welzl, Nolf, Palme Expires - January 2008 [Page 3]
The Expires Header in E-mail July 2008
References
[1] Resnick, P. (Editor), "Internet Message Format", Internet-draft
draft-resnick-2822upd-06 (work in progress), February 2008.
EDITORIAL NOTE: TO BE REPLACED WITH RFC 2822 IN CASE OF
PUBLICATION BEFORE THIS I-D IS PUBLISHED.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
[3] Kille, S. and Overell, P.(Editors), "MIXER (Mime Internet X.400
Enhanced Relay): Mapping between X.400 and RFC 822/MIME",
RFC 2156, January 1998.
[4] ISO/ITU: "Message Handling Systems, Part 7: Interpersonal
Messaging System, ISO international standard 10021-7, ITU
recommendation X.420.
[5] Murchison, K. (Editor), Lindsey, C., Kohn, D., "Netnews Article
Format", Internet-draft draft-ietf-usefor-usefor-12 (work in
progress), January 2007.
EDITORIAL NOTE: TO BE REPLACED WITH RFC 1036 IN CASE OF
PUBLICATION BEFORE THIS I-D IS PUBLISHED.
Acknowledgments
The authors would like to thank the many people who provided their
help during fruitful discussions in the IETF-822 mailing list of the
internet mail consortium. This includes Frank Ellermann, Ned Freed,
Arnt Gulbrandsen, Charles Lindsey, Jeff Macdonald, Keith Moore and
Hector Santos. Specifically, Keith Moore provided text for the
semantic definition of Expiry.
Welzl, Nolf, Palme Expires - January 2008 [Page 4]
The Expires Header in E-mail July 2008
Author's Addresses
Michael Welzl
University of Innsbruck
Technikerstr. 21 A
A-6020 Innsbruck
Austria
Phone: +43 (512) 507-6110
Email: michael.welzl@uibk.ac.at
Thomas Nolf
University of Innsbruck
Technikerstr. 21 A
A-6020 Innsbruck
Austria
Email: thomas.nolf@student.uibk.ac.at
Jacob Palme
Stockholm University / KTH
Skeppargatan 73
S-115 30 Stockholm
Sweden
Email: jpalme@dsv.su.se
Welzl, Nolf, Palme Expires - January 2008 [Page 5]
The Expires Header in E-mail July 2008
Full Copyright Statement
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Welzl, Nolf, Palme Expires - January 2008 [Page 6]