Subject: Re: draft-welzl-expires-00
From: "Michael Welzl" <[email-masked]>
To: Alfred HÎnes <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Sun, 23 Nov 2008 21:27:52 +0100
List-Id: <ietf-822.imc.org>

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

From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
Subject: draft-welzl-expires-00
To: [email-masked], [email-masked], [email-masked]
Date: Sun, 23 Nov 2008 21:04:25 +0100 (MEZ)
Cc: [email-masked]
Sender: [email-masked]

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-masked]                     |
+------------------------+--------------------------------------------+