Hello,
after studying the Internet-Draft authored by you,
draft-welzl-expires-00,
I'd like to submit a few comments, addressing the issues I found
in that memo.
To give more context, sometimes I quote larger blocks of text
literally and show the replacement proposed using the shorthand
notation:
<original draft text>
---
<modified text>
I use change bars ('|' in column 1) and up/down pointing marker
lines ('^^^'/'vvv') to emphasize the location of textual issues
and/or proposed corrections. Modified text has been re-adjusted
to match RFC formatting rules, where appropriate.
(1) General: Relation to RFC 4021, IANA Considerations.
The draft lacks an IANA Considerations section.
It should aim at updating the entry for "Expires" in the
Header Field registry established by RFC 4021.
Further, since the draft text -- in particular in Sect. 3 & 4 --
contains a revision of Section 2.1.50 of RFC 4021, it should say
so explicitely.
The significant challenge is that an MUA never can be sure whether
a particular message carrying the Expires header field has travered
an X.400 gateway or not.
To my knowledge, at least one widespread commercial messaging
product behaves internally similar to X.400 (but is not X.400),
and routinely adds a couple of RFC 2156 header fields to outgoing
messages sent to the Internet, e.g., Importance, Priority,
Sensitivity, Autosubmitted, and Autoforwarded, which all are
tagged as "not for general use" in RFC 4021.
If this draft wants to make sense, IMHO it really should formally
update RFC 4021; it makes no sense to have two different semantics
attached to the same header field, dependent on the (mostly
unknown) originator of that field.
Necessary changes:
- Front matter:
Updates: 4021
- Abstract:
<< see text proposal in (2b) below >>
- Introduction:
... << to be worked out, similar as in (2b) below >>
...
This document updates Section 2.1.50 of RFC 4021.
- Section 3: ... << to be worked out >>
- Section 4: ... << to be worked out >>
(2) General: inconsistent use of established IETF terminology
Unfortunately, the draft partially messes up the precise use of
terminology firmly established in the IETF with colloquial abuse
of language. Following the line of RFC 2822/5322, the draft
should consistently be precise in distinguishing between an email
(message or MIME part) "header" and a "header field" therein.
To this end, I suggest the following changes:
(2a) document title:
The Expires Header in E-mail
---
The Expires Header Field in Email
(See the RFC Editor 'terms-online' vocabulary for the spelling
of "email" without an embedded hyphen.)
(2b) Abstract
[ Also incorporating changes for (1) above: ]
| 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.
---
| This memo generalizes the use and changes the semantics of the email
| header field called Expires. Using this header field, the sender of
| an email can now 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.
(2c) Section 3, 1st paragraph
v
| The Expires header indicates a date-time at which this message
expires. The exact meaning of "expires" is:
--- vvvvvvv
| The Expires header field indicates a date-time at which this message
expires. The exact meaning of "expires" is:
(2d) Section 3, 3rd paragraph
v
| This header is intended for use between senders and recipients and
their agents, rather than by message transport. [...]
--- vvvvvvvvvv
| This header field is intended for use between senders and recipients
and their agents, rather than by message transport. [...]
(2e) Section 3, 5th (= last) paragraph
v
| The Expires header is strictly advisory in nature: [...]
--- vvvvvvv
| The Expires header field is strictly advisory in nature: [...]
(2f) Section 4, 1st paragraph
In this case, I additionally suggest to simplify the text a bit:
vvvvvvvvvvvv
| 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".
--- vvvvvvv
| A similar header field 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".
(3) References -- outdated ref.
Ref. [1] in the meantime has been published as RFC 5322
(October 2008).
Best regards,
Alfred Hönes.
--
+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
|
+------------------------+--------------------------------------------+