[Top] [All Lists]

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

2008-07-30 00:38:00

Bill McQuillan wrote:

On Tue, 2008-07-29, Russ Allbery wrote:

Bill McQuillan <McQuilWP(_at_)pobox(_dot_)com> writes:

In netnews the tradition is that the originator of a message "owns" it.
Thus the author is empowered to cancel a message that he or she has
posted and to suggest the lifetime of that message by using the
"Expires:" field.

I don't believe this is a correct characterization of how netnews works or
how the netnews protocol documents present control over message stores.
It is quite well-established in the Usenet world that the operator of a
news server has complete control over that message store, including
keeping messages for an arbitrary length of time, ignoring Expires,
rejecting all cancel messages, and so forth.  The original poster has no
control over the message within the protocol once it has left their
posting client; they can only provide advisory information and requests.

Actually, as I understand it an operator only has control of his own local
store (and any downstream stores which soley depend on his feed.) The
message I was refering to is a higher level entity that may be cached in
many thousand stores that no one operator has control over.

Obviously, there are overrides possible in the real world, but the one
person that usenet seems to treat as legitimate in sending a cancel message
is the author. I do not claim that this is an integral part of the
architecture, but it seems to me that it is a generally accepted feature of
usenet but not of email.

yes, and I agree that it makes a difference. if a usenet message sender wants to delete a message that he has sent after a particular date, he can always issue a cancel for that message on that date. from that perspective, giving the usenet sender the ability to request deletion via Expires doesn't create a new capability - it just provides a more efficient/precise way to do what could have already been done via a cancel message.


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