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

[Mark Crispin <[e-mail]>]

On Tue, 21 Jun 1994 18:22:51 -0700, Marshall Rose wrote:
> In general, it would be helpful for you to review the draft with respect
> to a minimalist philosophy.  The goals are: simplicity and minimal
> footprint on the server.  Presumably other protocols will be less
> simple and have larger footprints.

These goals needs to be stated explicitly in the document.

The IETF needs to be consistant; if POP3 claims exemption from what were
stated as requirements elsewhere (over the objection of that protocol's
author) by means of being a ``minimalist'' protocol then it should state that
this is its position.

> > Is -ERR really a ``success indicator''?  [Page 3]
> Yes, a success indicator tells you whether you were successful or not.

I prefer the less ambiguous ``status indicator'' or ``indicator of success''.

> > 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]
> Because it is simpler for the server to not accept new connections.

Actually, in an inetd-based implementation on UNIX, it is not.  A POP3 server
is not the TCP/IP listener.  The POP3 code has no decision-making ability over
what inetd accepts or refuses.  If, after being started, the POP3 server
decides that it refuses to deal with this connection, its choice is pretty
much limited to closing the connection silently unless a -ERR is permitted.

> > 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?
> Minimal server footprint.

This doesn't answer the question.  I still have no idea what the text actually
means.

If it must be accurate, it should say so.  If it's only an estimate, it should
say so.  All accurate figures qualify as valid estimates, but not all valid
estimates qualify as accurate.

The document could be smaller if it says one or the other forthrightly without
all this other meaningless crud.

On Wed, 22 Jun 1994 11:21:54 -0400 (EDT), John Gardiner Myers wrote:
> 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.

POP3 is chock-full of optional commands and facilities.  A server has no way
of knowing what is supported unless it tries one of the optional commands and
sees what happens.  This was pronounced an unacceptable state of affairs in
the IMAP working group, and a CAPABILITY command was put into the protocol
over my vehement objections.

> > Did we really decide that there should be ``one or more whitespace
> > characters'' delimiting keywords and arguments?
>
> While I personally would prefer the command/argument delimiter be a
> single space, I don't think it's worth arguing about.

The problem is that my server only uses a single space.  I haven't heard of
any interoperability problems, but I'm going to have to add code to fix this.

So much for minimal server footprint!

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

We should find out, and if not, I propose a reduction in the protocol
consistant with its minimalist goals stated by Marshall.

> > ``Hence a multi-line response is terminated with the five octets''...
> Would it be better to transpose this and the previous sentence?

Perhaps.

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

Yes.  It would also make the protocol smaller if +OK and -ERR are allowed in
all cases.  It may be silly to respond to NOOP with -ERR, but stating that you
can't (as the current document does) makes the protocol larger.

> > ``must now issue the USER command''
> Do you have suggested wording?

``must authenticate.''  Then, document USER/PASS as one means of
authentication, and that other means may be added in the future.

Otherwise, it requires the use of USER for all authentication mechanisms.

> > It's a nasty implementation burden to make the server permit a new USER
> > command if the lock can't be obtained.
> 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.

Not true.  My server has given up root long before any sort of locking on the
mailbox takes place.

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

A clarification or tightening of the requirement is needed.  Basically, you
should not consider the user logged in unless you can ``lock'' the mailbox in
the POP3 sense.  Agreed?

What is more likely is that I won't implement the lock in the POP3 sense at
all; I will just simulate its behavior.  This then leads to the question of
what the appropriate simulated behavior would be:
 Case 1: Can get read/write.  Must make sure that messages in the middle of
	the mailbox don't disappear.  Make sure that messages don't appear at
	the end of the mailbox (new mail)?  Already handled.
 Case 2: Can get read but not write.  Not sure what to do.
 Case 3: Can get no access at all.  Not sure what to do.
Case 1 is probably the common case, with case 2 an infrequent second, and case
3 for completeness (it won't happen in my implementation; I don't know about
anyone else's).

Is it better to close the TCP connection in case 2/3 happen, or should I say
zero messages, or ???

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

Looks good.  Are there any ``more advanced implementations'' which include
such other information, or should that provision be flushed?

> > ``This line is called a "scan listing" for that message.'' is stated
> > twice.
> 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.

It needs to be collapsed, since it reads as a typo.

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

The implementation advice is fine.  I still don't know if this is exact or
not; the advice implies that an estimate is alright.  I request a decision,
one way or the other.

If it doesn't have to be exact, I could simplify my server to eliminate part
of the size calculation.