ietf-822
[Top] [All Lists]

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

2008-07-28 22:09:25

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

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