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