[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-welzl-expires-00
Hi,
Thanks a whole lot for your feedback, and the time you put
into it! We'll incorporate this into the next update, which we
wanted to start working on soon anyway.
Cheers,
Michael
----- Original Message -----
From: "Alfred HÎnes" <ah@xxxxxxxxx>
To: <michael.welzl@xxxxxxxxxx>; <thomas.nolf@xxxxxxxxxxxxxxxxxx>;
<jpalme@xxxxxxxxx>
Cc: <ietf-822@xxxxxxx>
Sent: Sunday, November 23, 2008 9:04 PM
Subject: draft-welzl-expires-00
> 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@xxxxxxxxx |
> +------------------------+--------------------------------------------+
>