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

Frank Ellermann wrote:
> Russ Allbery wrote:
> 
>> usepro doesn't define header fields.  Header fields are
>> defined in usefor.  From draft-ietf-usefor-usefor-11.txt:
> 
> ACK.  Keith kind of insisted that there must be some issue
> with news in the proposal for mail, and I double-checked
> that this isn't the case.

IMV, the only difference is that news processing does not have to 
concern itself with USER options.

    For news, Expires has been processed as a removal concept.
    i.e, the news article is no longer available and/or truncated.

Keith desires user permission.  Difficult to apply in news groups.
IMV, this is thee key philosophical issue here.   All I am saying is:

   Expiration already exist outside any externally declared
   expiration related flag. For news Expires helps the process.
   But User permission is not required for news or email
   storage purging.  There are default settings already in place.

So if this EXPIRES is introduced as a standard, how does it change the 
existing default expiration practice?

What I find difficult to swallow is the attempt to make this a backend 
transparent concept - for offline MUA only.   I don't think that is 
realistic.


> [...min default max detail...]
>> thus leaving the question to site configuration.
> 
> Thanks for info.  That should be okay even for Hector's 
> groupware scenario.  Unless Keith finds something in his
> X.400 documentation invalidating his proposed semantics.

X.400 operations also had data retention policies that were NO user based.

I recall, back in the early 80s when I first got my feet wet with 
designing the early offline mail systems, the engineers and corporate 
lawyers meetings discussing the details over captured email with these 
new "offline mail systems" which we called "Emailator" on what was 
then the employees new terminals - Personal Computers.

Then again I worked under a top security clearance area, so there were 
natural security concerns regarding:

   - Requiring tempest computers (to guard against Russians
     parked outside in vans sniffing the electronic download
     or display signals),

   - Automatic Expirations of captured email, no user option,

   - Making sure PC's had storage destruction/scrabbling
     software was installed.

When I left to concentrate on my successful moonlight shareware 
product - Silver Xpress, the 3rd offline mail system of its kind, 
after TAPCIS and QMAIL Deluxe - the 1st for Fidonet,  there was never 
a time where there wasn't some form of automatic purging for the mail 
hosting system.  SX worked on 22 different online hosting systems. All 
of them had automatic purging.  Regardless of the network, the 
software, the system, it was always there.  So I find it somewhat 
shocking that there is attempt to stop this practice or labeling it as 
some obscene bastard operation.  Very odd.

The only way I see you can do this is to give it some obscure header 
field name that 100% relates to user rendering.

But calling it "Expires?"  Sorry, don't be surprise if someone uses 
this outside the proposal intent to keep backends or operators from 
using it.  Its too juicy.  Nothing like it exist (in email) to get rid 
of mail with zero false positive. The sender says "On this date, this 
message is no longer useful, valid, its useless",  rest assured it 
will be taken literally and they are not going to wait for a user to 
get rid of it, especially when their 3rd party offline user is not 
prepare to support it.  Centralize systems will be the key beneficiary,

-- 
HLS