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

On Sun, 12 Jul 1998, Jacob Palme wrote:
> I suggest that at the end of the description of each
> capability is added a new subheader "Specified in". For
> those capabilities which have been described in other IETF
> standards, this subheader should give an explicit reference
> to this standard. For thos capabilities, which have not
> been described in other IETF standards, this subheader
> could contain the phrase "This standard".

That's a reasonable suggestion.  If Randy does "a revision reflecting
comments received during last call", then this would be useful.

> Chapter 4, second paragraph, I suggest add information of
> whether CRLF is included in these 255 octets or not.

Good point.

> The way I understand the specification, two new
> interactions between clients and server are needed, started
> with the CAPA command, one before authorization and one
> afterwards. Interactions usually incur delays. Is this
> really necessary? One might compare with the EHLO command
> in SMTP, which does not incur any additional interactions,
> since it replaces the HELO interaction.

A reasonable issue.  But realize there is no equivalent to HELO in POP3.
The only other place to put the capability list would be in the greeting
line which is already overloaded with the APOP challenge.  On the other
hand, without the CAPA command, one would have to do an extra round-trip
to probe for each capability one wanted to use.  If we add TLS to POP3,
that would be up to two round-trips before login and four afterwards. 
Knocking that down to one before and one afterwards is an improvement, and
with piplining, the round-trip after login can be eliminated -- with the
result of this being no more expensive than ESMTP EHLO.

I think you've just made a good argument for why this should be
standardized :-)

> USER capability: "although they may not be available to all
> users": I suggest this is specified more clearly. To which
> users are they available and not available? My guess, from
> reading the text, is that users are split into three
> categories:
> 
> (a) Users who may issue USER and PASS
> 
> (c) Users who may not use this POP server at all
> 
> The above is only my guess, the standard should specify
> what it means!

It's an issue of security policy.  A site may determine that some subset
of users aren't allowed to use clear text passwords and have to use APOP
or AUTH instead.  I don't think the current wording is particularly
troublesome, there are several reasonable interopretations none of which
result in an interoperability problem.

> (b) Users who may not issue USER and PASS, but which can
> use some kind of mechanism for general retrieval of public
> messages

FYI, POP3 has no such mechanism and probably never will given that's an
IMAP feature.

> EXPIRE capability: Days after what? Days after the arrival
> of the message into the POP mailbox? Days after last user
> connection to the POP server?

Since it says "indicates the minimum server retention period, in days, for
messages on the server", that would mean EXPIRE is: min(days after
arrival, days after retrieval) which the example describes in some detail.

There was a lot of discussion behind EXPIRE, and trying to express server
policy with more precision simply results in too much complexity.  EXPIRE
has just enough information for a client to know what it has to do (0 =
disallow "leave mail on server", NEVER = "leave mail on server" is fine,
something else = consult user about leave mail on server).

> Chapter 7: "Clients MUST NOT require the precense of any
> extension for basic functionality". I do not like this at
> all. Certainly, it should be permitted for a company to
> supply its users with clients which will refuse to work
> without requiring authorization! Such clients would
> increase security against certain kinds of attacks, and it
> is unreasonable that such clients are forbidden.

Good point.  POP3 is a strange beast since there is no
mandatory-to-implement authentication mechanism (which makes clear text
mandatory to implement implicitly), thus one has to require an
authentication command to function since anonymous POP3 is worthless.  I
propose:

  Clients MUST NOT require the presence of any extension or optional
  feature for basic functionality, with the exception of the
  authentication commands (APOP, AUTH and USER/PASS).

> Chapter 9: "IANA considerations". Any specification of new
> IANA registries must contain more information, such as the
> procedure for IANA to employ in accepting new items into
> the registry. See "draft-iesg-iana-considerations-04.txt".

It already identifies the procedure as "IESG approval" for POP3
capabilities and "Specification Required" for response codes.  What more
is necessary?  We certainly can't make a normative reference to an
Internet draft.

		- Chris