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