[Top] [All Lists]

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

2008-07-24 09:56:49


I was referring to widely practiced Standard Email Compliance Policies that include archiving, expiration, mining, etc following and/or meeting required data retention regulations outside the considerations of user rights.

Nothing insane, irresponsible or illegal about them. While you may not feel is our job to bless the practice, I'm sure others will take all these related issues into account. You made it quite clear your view point; backends MUST not deal with this header and if they do only with user permission. Well, the devil is in the details; e.g., if user permission is provided (assuming it is even offered at all), it can not defeat what may be already in place. It can only serve to accelerate the expired classification. Not extend it - unless of course an implementation wishes to consider that logic.


Keith Moore wrote:

Hector Santos wrote:

As you know Ned, expiration that is out of the control of the MUA (user) is already in practice.

That's irrelevant for a discussion of a standard. There are lots of things that are "already in practice" that are irresponsible or completely insane.

Our job is NOT to bless those practices, it is to define practices that are sane.

We can't stop people from implementing things that are irresponsible or insane. But there are things that we can do. We can make it clear that such behavior is a violation of the standard. And in some cases we can design protocols in such a way that such violations are observable, so that the responsible parties can be held accountable by whatever means is available (legal or economic or social).


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