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

[Alexey Melnikov <[e-mail]>]

Sorry for delay. I forgot about Last Call, my fault.

Keith Moore wrote:

> I apologize for an off-topic posting.
> Please send replies to [e-mail], not to the drums or ietf-smtp lists.
>
> On May 18, a Last Call was issued on for document draft-gellens-pop3ext-05.txt ,
> for Proposed Standard status.  Nobody has commented on the document.  I am
> reluctant to recommend that IESG approve this document without more evidence
> of support.
>
> So I'm asking for more review...
>
> Should the document be adopted as is?  Does it need more wordsmithing?

May be only only few comments/questions...

Section 6.3

    Discussion:
        [skipped].
       The SASL capability indicates that the AUTH command is available and
        that it supports an optional base64 encoded second argument for
        an initial client response as described in the SASL
        specification.

Why outline the existence of the second base64-encoded parameters?
Are you trying to correct AUTH RFC?


Section 6.4

    Standard commands affected:
        USER APOP AUTH

    Discussion:
        The LOGIN-DELAY capability includes an integer
        argument which indicates the number of seconds after an "+OK"
        response to a PASS, APOP, or AUTH command before another
        authentication will be accepted.  Clients which permit the user

May be I have paranoia, but PASS command is affected by LOGIN-DELAY also.


Section 8.1

    LOGIN-DELAY
        This occurs on an -ERR response to an AUTH, USER, PASS or APOP
        command and indicates that the user has logged in recently and
        will not be allowed to login again until the login delay period
        has expired.

I don't like servers that says "-ERR user not known" to USER command.
I think that LOGIN-DELAY response to USER command may server as a hint for attack on
server.
I propose to forbid server answer "-ERR [LOGIN-DELAY n]" to the USER command.

Last question : why authors decided to change syntax for IMPLEMENTATION from
IMPLEMENTATION "Shlemazle Plotz v302"
to
IMPLEMENTATION Shlemazle-Plotz-v302

> Are all of these capabilities needed?

Yes, because client should know about their existence to operate correctly with
different servers and to provide with service.

> Are all of the capabilities defined with sufficient precision?

I think that descriptions are precise enough.

> Should the document be standards track or should it be Informational or
> Experimental?

I would like to see it on Standard track, to insure interoperability (as other list
members wrote).

> Should the extension mechanism be separated from (and perhaps a different
> status from) the extensions themselves?

I agree with Chris Newman. So nothing else I can add.


Chris Newman wrote:

> > Are all of these capabilities needed?
>
> All of the capabilities (with the exception of IMPLEMENTATION) reflect
> functional variations in deployed POP servers which would function more
> smoothly if the client knew about them.  So I'd say yes.

I agree. About IMPLEMENTATION : to be frank IMPLEMENTATION servers for
logging/debugging purposes only. I don't see other use. IMPLEMENTATION requires 1
line of code to implement, so I think we don't need to discuss it.


Best 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
------------------------------------------

P.S. I've implemented in my server TOP, USER, PIPELINING, EXPIRE, UIDL and
IMPLEMENTATION.
And I have plans to implement SASL (CRAM-MD5) and LOGIN-DELAY as well.

Has anybody client that support current draft? (Or I have to write it myself :-))