Re: draft-rose-pop3-again-02.txt

[John Gardiner Myers <[e-mail]>]

Mark Crispin <[e-mail]> writes:
> Just for my edification, why doesn't POP3 have an equivalent to the IMAP4
> CAPABILITY command, and why doesn't POP3 have more command completion codes
> than just +OK and -ERR?

Nobody has brought these up as issues, at least this time around.

> Did we really decide that there should be ``one or more whitespace
> characters'' delimiting keywords and arguments? 

This wording was in draft-rose-pop3-again-01.txt, which I used as a
base.  I don't believe this issue was brought up before on the list,
except perhaps in the context of the PASS command.  The issue of the
format of *responses* was discussed and clarified there.

While I personally would prefer the command/argument delimiter be a
single space, I don't think it's worth arguing about.

> Does any client use more than
> one whitespace character?  Does any client use TAB?  [Page 3]

Unknown to me.

> Is -ERR really a ``success indicator''?  [Page 3]

Yes, as Marshall notes.

> ``Hence a multi-line response is terminated with the five octets''... seems to
> be restating the obvious and is confusing in the context of the previous
> sentence.  [Page 3]

Would it be better to transpose this and the previous sentence?

> Why isn't a server permitted to give
>         -ERR I can't talk with you now
> as a greeting?  (Equivalent to IMAP4 BYE as a greeting) [Page 4]

As Marshall indicates, a server can indicate "I can't talk with you
now" by refusing connections.  However, an initial "-ERR" greeting
would be useful for allowing a server to indicate that it will
permanently refuse to talk with the client.

Is this a feature worth adding?  We're trying to set a high level of
requirements for new features.

> AUTHORIZATION state information should mention APOP, and perhaps also AUTH.
> Note that the current spec says ``must now issue the USER command'' -- this
> should be modified given other means of authentication.  [Page 4]

Do you have suggested wording?

It is most certainly not appropriate to mention AUTH.

> It's a nasty implementation burden to make the server permit a new USER
> command if the lock can't be obtained.  If clients don't implement it, it
> should be nuked.  [Page 4]

Could you give details as to the burden?  I think in your case, the
server doesn't have to give up root until after it knows it has the
lock.

I suspect a server can choose to just close the TCP connection after a
failed PASS command, though there isn't any explicit wording to this
effect.

> ``This line is called a "drop listing" for that''  For that what?  [Page 7]

Appended "maildrop."

> ``The first octets present must indicate the number of messages''  I had to
> read this a few times before I figured out what this meant, especially in
> light of the following sentence.  I suggest a rewrite.  [Page 7]

In order to simplify parsing, all POP3 servers required to use a
certain format for drop listings.  The positive response consists of
"+OK" followed by a single space, the number of messages in the
maildrop, a single space, and the size of the maildrop in octets.
This memo makes no requirement on what follows the maildrop size.
Minimal implementations should just end that line of the response with
a CRLF pair.  More advanced implementations may include other
information.

> ``This line is called a "scan listing" for that message.'' is stated twice.
> [Page 8]

It is stated one time for the case where LIST has an argument and once
for the case where LIST is used without an argument.

> Same ``The first octets'' problem as on page 7.  [Page 8, Page 13]

fixed

> Page 17 is awfully mealy-mouthed about the message size.  Is it a reliable
> indicator of the RFC822 message size in Internet text format, or isn't it?

I read section 10 as clearly stating message sizes are for the
Internet text form.  It then goes on to give implementation advice as
to how a server may properly caclculate these sizes.  The
implementation advice is appropriately mealy-mouthed, since servers
can legitimately perform any necessary calculations at other times or
using other methods.

-- 
_.John G. Myers		Internet: [e-mail]
			LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up