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" <[email protected]>
To: <[email protected]>; <[email protected]>;
<[email protected]>
Cc: <[email protected]>
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:  [email protected]                     |
> +------------------------+--------------------------------------------+
>