Re: [ietf-822] Expires header field

[Dave Crocker <[e-mail]>]

On 11/8/2022 2:36 AM, Murray S. Kucherawy wrote:
> Before I send it to an extended Last Call, I wanted to prompt here for 
> any feedback, support, etc.  Please have at it.


Review of: draft-billon-expires-06
Reviewed by:  D. Crocker <[e-mail]>
Date: 2 Dec 2022

All comments are inline.


> Abstract
>
>     This document allows broader use of the Expires message header field
>     for mail messages.  Message creators can then indicate when a message
>     sent becomes valueless and can safely be deleted, while recipients
>     would use the information to delete or ignore these valueless
>     messages.

The draft does not indicate in what way this specification is an update 
or enhancement to the previous version.

I suspect the change has more to do with use than semantics, and it is 
explicitly no change in syntax.

Consequently, it is probably less confusing to just limit the history 
references to the history section.

So for the Abstract, perhaps instead:

The Expires message header field indicates when a message becomes 
valueless and can be deleted safely.  Recipients have the option to use 
this information, as guidance for further message disposition.



> 1.  Introduction
>
>     The date and time of expiration can be used by the mailbox provider
>     or the MUA to indicate to the user that certain messages could be
which provider?  which MUA?  And what is the basis for having an 
originating system (mailbox provider) decide when a message expires?

I suspect what is meant is:

The data and time of expiration can be added by an author, to indicate 
when a message is considered no longer useful.


>     deleted, in an attempt to unclutter the user's mailbox and spare
>     storage resources.
indicating loss of utility is arguably a more significant attribute than 
saving storage space.



> 2.  Header Field example
>
>     The header field definition and syntax remain the same as in
>     [RFC4021], the time at which a message loses its validity.

>     expires = "Expires" ":" date-time
The above ABNF is not merely an example.  It is a normative 
specification of the syntax.

It should be called out as such, rather than buried in an 'example' section.



>     Example:
>
>     Expires: Wed, 1 Dec 2021 17:22:57 +0000
>
>     Message creators MUST NOT include more than one Expires header field
>     in the message they send.
>
>     If there is more than one Expires header field then message readers
>     SHOULD act as if no Expires header field is present.
If the issue is strong enough for the MUST NOT, why is violation worthy 
only of a SHOULD?


> 3.  Security considerations
>
>     Dates in this header field can be set a long way in the past or in
>     the future, including outside the range of internal time
>     representations in some programming environments - all software which
>     processes the Expires header field MUST be made safe against this
>     possibility.
>
> 4.  Advice to Message Creators
Does this include anyone other than authors?


>     Message creators add the header field along with a relevant date and
>     time when they know that the content of the message has no value
>     after a given point of time.  This could apply to commercial
>     newsletters, that include time-limited offers, event announcements,
>     social notifications, or Time-limited access codes.
This is not 'advice'.   It is really an expansion of reasons it might be 
used.

This would go nicely in the Introduction, where the only utility that is 
described is freeing storage.



> 5.  Advice to Message Readers (Mailbox providers, Webmails and MUAs)
"webmails"?  Those are just a type of MUA.

Mailbox providers aren't really message readers, are they?



>     The expiration of a message's validity would logically lead to the
Expiration ends intended utility, not 'validity'.

And note the 'intended'.



>     Presence of the Expires header field MUST NOT be interpreted as a
>     sign that a message is legitimate.
A normative statement like this is not 'advice'.  It should go up in a 
section providing normative specification.



> 6.  Past History of the Expires: header field
Past History -> History



d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
mast:@[e-mail]