Re: EXPIRE

At 12:46 PM -0700 7/23/98, Lyndon Nerenberg wrote:

>> I'm not sure the added complexity would buy us anything useful.  The
>> EXPIRE setting can only be a rough guide to the user, never accurate
>> (without some complex per-message expiration warning mechanism).  Even
>> if the server presents the currently accurate value for a specific
>> user, that value could change, the user doesn't know how long the
>> message has already been on the server, and some servers could change
>> the expiration period after the user has seen the message.
>
>And for those exact reasons I oppose including EXPIRE. At best the
>information
>it provides is of marginal utility, and in practice, any incorrect/invalid
>data returned by EXPIRE will most likely result in lost mail. The only way I
>will support EXPIRE is if the protocol spec *requires* the server to enforce
>the value it advertised to a client (i.e. if on day n you say EXPIRE 30, and
>on day n+1 you say EXPIRE 2, any operations I performed on day n must
>continue
>to work within the constraints of the EXPIRE 30 information you gave me). If
>you cannot guarantee the semantics of operations based on EXPIRE data it
>doesn't belong in the protocol.

EXPIRE doesn't cause lost mail.

Currently, POP servers are operated in one of three modes: users are
permitted to leave mail on the server indefinitely (perhaps subject to
maildrop size limits); users are not permitted to leave mail on the
server at all; or users are permitted to leave mail on the server for
some period of time, either from arrival on the server or first notice
to the client, and perhaps subject to earlier or later deletion based
on user action (TOP, RETR).

Currently, there is no standardized, interoperable way to inform users
of the server's operating mode.

With the EXPIRE capability, the server can inform the client as to
which of the three modes is in force, and additionally offer some
guidance regarding the time period for the third mode.  This guidance
should not be used for anything more specific than warnings for setting
client LMOS days.

I think this is a big improvement over the current situation.  It
causes no harm, and it improves things.

Earlier versions of the draft had more three different EXPIRE
capabilities, based on message status.  There was consensus that this
was too complex, that something simpler was needed.

Please keep in mind that this is POP, not IMAP.  This is primarily a
download-and-delete-from-server model.  Leaving mail on the server is
generally used to allow mail to be downloaded to multiple clients.  POP
is not intended to be a generalized mail retention and access protocol.
If a user leaves mail on the server and deletes it from a client,
expecting to be able to download it again later, then mail might be
lost.  This is a misuse of POP.  The EXPIRE capability does not make
this any more likely.

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
--Chair, Californians for higher taxes, worse government, poorer schools,
  unsafe water, and more crime.--
-------------- Randomly-selected tag: ---------------
Things get worse under pressure.