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

*** within

>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 did not mean to open a rat's nest here.  I thought the idea of EXPIRE
USER off the top my head and I was sitting on the fence as to whether I
should even mention it...  The comments about over engineering things and
adding complexity are always valid concerns, and I am happy with EXPIRE the
way it is.  The area, that I thought that could be improved was adding
clarification text so that everyone knew EXACTLY how it would work.  I think
it needs to be made really clear how it works with per user settings, and
that the client needs to reissue CAPA after authentication.   With the text
Randy will be adding, I am happy with the draft.

Alexey also brings up a good point on EXPIRE 0.  Clarification text and the
example Alexy brings up below should also be added to the spec.

As to Chris's comments, I agree that we don't want re-open and redesign the
whole spec.  I apologize for the late comments, and really all I was looking
for was looking for was more clarification text so that it was crystal clear
exactly how everything worked.  I did not mean to start re-engineering
thigns.  With clarifications added, I am happy with the doc, and think it is
ready for it to go to proposed standard.  It is something we are interested
in implementing.

>>
>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,
*** I think EXPIRE should stay.  The doc just needed to be more explicit
explaining how it worked.