Re: Intent to revive "expires" header from draft-ietf-mailext-new-fields-15

Bill McQuillan wrote:
> 
> The reason I proposed this was I am worried that it will be TOO easy for J.
> Random Sender to determine how my message store will be managed. IMHO the
> word "expires" carries so varied a meaning that I will have to struggle to
> make any reasonable use of it.
> 
> What I am willing to grant J. R. Sender is the ability to declare one (or
> more?) "status change" date-time(s) from *his* point of view. I'm hesitant
> to use the word "expires" for that status change, both because of the
> disconnect between the sender's opinion and the recipient's as well as the
> danger of server or client developers implementing what they believe is its
> "meaning".

At this point I agree that if we wish to keep this totally backend 
transparent (which is not possible for Online MUAs), but strictly for 
store and forward offline based mail readers, then it ought to use a 
different header terminology.

Using "Expires:" has too much potential to become central with mail 
operations.  Consider DKIM with its expiration tags.   The same issues 
will apply.  How does a system single source the design?   Most will 
prefer to consolidate the logic.

Remember, this this era, it is nature of operators and vendors will 
always look for a "better feature" to offer their customers, an 
automatic way of doing things.   If this is made a standard, rest 
assured it will be used on the backend one way or another.  It is too 
enticing for an era where we don't have too many sound "indicators" to 
make automated decisions. This one is a prime candidate to be one. 
Consider if there is abuse by spammers in an vain attempt to keep mail 
"active" as long as possible on MUA work spaces, some one is sure to 
add backend logic to zoom in how Expires tags.

If we wish to minimize backend handling, then it probably will help by 
giving it a header field name whose connotation implies "FOR END USER 
DISPLAY RENDERING" only. "Color-me-Gray-Date:" comes to mind :-)

But then again, for the online system, it still means the backend has 
to be aware of it too.

-- 
HLS