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

At 03.30 +0200 98-07-09, Keith Moore wrote:
> 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.

I have read the document and have some comments. I am not a
POP expert and have no personal experience of implementing
POP.

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

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

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.

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

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

(c) Users who may not use this POP server at all

The above is only my guess, the standard should specify
what it means!

PIPELINING capability: Keith has indicated that maybe the
new capabilities should not be described here but in a
separate document. I have no general comment on this, but I
think the PIPELINING capability is important, and do not
want any delay in making it into a standard.

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?


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.

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

I am not a member of the [email protected], so please
copy any replies to this message, which I should see,
either to me personally or to the [email protected]
mailing list. (It is reasonable that discussion in the
final stage of IESG approval of a new standard is
widened to a more general ist, like the mailext list.
Since the mailext IETF wg stopped operation, discussion
in that list will not cause problem to ongoing standards
work in the same list.)

------------------------------------------------------------------------
Jacob Palme <[email protected]> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/~jpalme
Temporary summer phone No. +46-8-664 77 48 not +46-8-16 16 67