[Top] [All Lists]

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

2008-07-25 19:17:24

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

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.


<Prev in Thread] Current Thread [Next in Thread>