Pete Resnick wrote:
Don't use the wrong header name just because someone else used it ages
ago for something slightly different and then deprecated it and you
want to un-deprecate it. Use the right header name, or don't use
anything.
I'm sorry, but I'm not at all convinced by this. To repeat Frank, the
"Expires:" header field *in use today* in news is defined as follows:
The Expires header field specifies a date and time when the poster
deems the article to be no longer relevant and could usefully be
removed ("expired").
That's almost precisely what we've been talking about: A field to
indicate the date after which the *sender* thinks you could delete this
message. Do you have to delete it? No. Can you color it polka-dotted? Of
course. But the sender is indicating that, for all he cares, you can
delete it after this date.
Major differences between private email vs public conference or public
group based systems.
The key difference Pete, is that in News we have a 1 to ALL mail mail
conferencing system. There is no 1 to 1 private end-user relationship,
sender/user contract concerns with news groups. There is no "You." It
is govern as a whole by the system operator, the group conference or
newsgroup manager, if any.
Expires makes sense for News here because we don't have these user
concerns. It was less complicated than for a private 1 to 1 system
where there is a "You." For news, expires is parenthetically defined
as Remove. However the user can't remove group mail. Only the system
or moderator can. He generally can not delete/expire another sender's
or author's posting into a newsgroup. The user can, and only if
allowed, remove (CANCEL) his own posting.
IMTO, introducing a standard "Expires" header is most definitely going
to be considered for its worth and consequences. I can easily see how
it may be implemented by backends and mail distribution software.
Easily. And that may include having a default user permission option
that the user has to turn off - not turn on first.
IMTO, my main point is I don't think you can ignore how a new standard
header called "expires" relates to all kinds of existing practices,
especially on servers.
> Is there a potential that some bastard e-mail server will take
> this to mean that it should delete the message behind your
> back without your permission?
Bastard?
It already happens in wide practice. I am surprise to see this is a
shocking and considered a bastard?
RFC 1939 specifically says there no violation regarding these
policies. Nothing "bastard" about this common practice.
* Enforce a site policy regarding mail retention on the server.
Sites are free to establish local policy regarding the storage and
retention of messages on the server, both read and unread. For
example, a site might delete unread messages from the server after
60 days and delete read messages after 7 days. Such message
deletions are outside the scope of the POP3 protocol and are not
considered a protocol violation.
RFC 2449 (CAPA) specifically briefly touches on the concepts of data
retention and automatic deletion policies. Nothing bastard about this.
Discussion:
While POP3 allows clients to leave messages on the server, RFC
1939 [POP3] warns about the problems that may arise from this,
and allows servers to delete messages based on site policy.
The EXPIRE capability avoids the problems mentioned in RFC 1939,
by allowing the server to inform the client as to the policy in
effect. The argument to the EXPIRE capability indicates the
minimum server retention period, in days, for messages on the
server.
EXPIRE 0 indicates the client is not permitted to leave mail on
the server; when the session enters the UPDATE state the server
MAY assume an implicit DELE for each message which was downloaded
with RETR.
<note>
For our system, we make Server Retention a OPERATOR option per USER.
</note>
EXPIRE NEVER asserts that the server does not delete messages.
The concept of a "retention period" is intentionally vague.
Servers may start counting days to expiration when a message is
added to a maildrop, when a client becomes aware of the existence
of a message through the LIST or UIDL commands, when a message
has been acted upon in some way (for example, TOP or RETR), or at
some other event. The EXPIRE capability cannot provide a precise
indication as to exactly when any specific message will expire.
The capability is intended to make it easier for clients to
behave in ways which conform to site policy and user wishes. For
example, a client might display a warning for attempts to
configure a "leave mail on server" period which is greater than
or equal to some percentage of the value announced by the server.
<note>
I wish Offline MUA followed this recommendation.
</note>
If a site uses any automatic deletion policy, it SHOULD use the
EXPIRE capability to announce this.
<note>
Notice this is a SHOULD. Servers are not required to
make automatic deletion policies a user permission based idea.
Online system are better server because they have control over the
presentation of new options as they come. Offline 3rd party based MUA
isers suffer in this area.
</note>
The EXPIRE capability, with a parameter other than 0 or NEVER, is
intended to let the client know that the server does permit mail
to be left on the server, and to present a value which is the
smallest which might be in force.
Sites which permit users to retain messages indefinitely SHOULD
announce this with the EXPIRE NEVER response.
If the expiration policy differs per user (that is, the EXPIRE
argument might change after authentication), the server MUST
announce in AUTHENTICATION state the smallest value which could
be set for any user. This might be the smallest value currently
in use for any user (so only one value per server), or even the
smallest value which the server permits to be set for any user.
The server SHOULD append the token "USER" to the EXPIRE parameter
in AUTHENTICATION state, to inform the client that a more
accurate value is available after authentication. The server
SHOULD announce the more accurate value in TRANSACTION state.
(The "USER" token allows the client to decide if a second CAPA
command is needed or not.)
A site may have a message expiration policy which treats messages
differently depending on which user actions have been performed,
or based on other factors. For example, a site might delete
unseen messages after 60 days, and completely- or partially-seen
messages after 15 days.
The announced EXPIRE value is the smallest retention period which
is or might be used by any category or condition of the current
site policy, for any user (in AUTHENTICATION state) or the
specific user (in TRANSACTION state). That is, EXPIRE informs
the client of the minimum number of days messages may remain on
the server under any circumstances.
Examples:
EXPIRE 5 USER
EXPIRE 30
EXPIRE NEVER
EXPIRE 0
The first example indicates the server might delete messages
after five days, but the period differs per user, and so a more
accurate value can be obtained by issuing a second CAPA command
in TRANSACTION state. The second example indicates the server
could delete messages after 30 days. In the third example, the
server announces it does not delete messages. The fourth example
specifies that the site does not permit messages to be left on
the server.
IMO, if we can't make this new proposal of a Sender define "expires"
header consistent with already existing standard practices, then IMO,
it should be call something else.
--
HLS