Re: [Off Topic] Need review for POP3 extension mechanism

Randall Gellens wrote:

> At 2:58 PM -0700 7/23/98, Alexey Melnikov wrote:
>
> >Imagine, for example, that server calculates the minimal EXPIRE value for all
> >users and returns it in the unauthenticated state. Let user A have
> >EXPIRE value
> >equal to 0 and user B has EXPIRE >0 (5 for example). Described server
> >will return
> >EXPIRE 0 in unauthenticated state, but it will not be the truth for user B.
> >I think that something like EXPIRE USER will help to solve such problem.
>
> If user B's client does not do another CAPA after authenticating, it
> might issue a warning if user B has LMOS set, something like "Warning:
> your mail server might delete messages immediately".
>
> I don't like the idea of CAPA returning EXPIRE USER, because that
> forces the client to reissue CAPA after authenticating.  I could see
> perhaps adding USER as an extra token after the value parameter (EXPIRE
> 5 USER) to indicate that the value might be inaccurate.   But remember
> we're talking POP, not IMAP, here.  We want to keep things simple.  How
> many servers are going to be operating in a mode such that there is a
> number-of-days-per-user expiration policy, which for some users is 0
> (immediate deletion) and for others is something else?  Is it worth
> cluttering the protocol to be able to do something slightly better in
> those few cases?

I don't want to make things more complex, I just want to make them good from the
beginning (i.e. not to redesign them later). Personally I am happy with EXPIRE 0,
EXPIRE 1 (everything non zero), EXPIRE NEVER, EXPIRE USER.

Extra token is a good way to go.

> There are widely-deployed servers today which delete messages after a
> DELE has been received for them, even if the client does not send QUIT
> before the connection closes, even though this is a clear violation of
> POP3.
>
> Since there are always edge cases, maybe we should cut EXPIRE from the
> draft, which means we live with the status quo, at least until a
> replacement draft advances.  I tend to think that would be worse,
> because we simply aren't going to be able to solve 100% of the
> expiration cases without complexity that doesn't belong in POP.  But if
> the consensus is that that's better, I'll do it.

I agree with Mike : EXPIRE should stay. However I don't mind to place it in a
separate document.


One more comment : I think it is good idea to add more text about how EXPIRE value
is calculated (What Chris wrote before), because it is not obvious for readers,
that didn't take a look at the previous versions of POP3ext draft.

Regards,
Alexey Melnikov
------------------------------------------
SMTP/POP3/IMAP4/ACAP servers creation team
"ACAP Explorer" client
Imap Development Kit (my own product)

Epsylon Technologies, Russia
 http://www.demo.ru
------------------------------------------