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

Keith,

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.

-- 
HLS



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).
>
> Keith
>
>