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

As one of the co-authors, I'll take a crack at your questions.

On Wed, 8 Jul 1998, Keith Moore wrote:
> Should the document be adopted as is?  Does it need more wordsmithing?

I have already implemented to the current spec (including all the
capabilities listed).  The only wordsmithing issue that might be a concern
is how strongly the "lots of POP extensions are undesirable" wording
should be.  It's pretty strong now in that it gives cause to reject any
extension which overlaps SMTP or IMAP functionality.  I'd consider it a
friendly amendment to make that language even stronger (although I don't
know about my co-authors).

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

> Are all of the capabilities defined with sufficient precision?

I think so.  But a proposed standard doesn't have to be perfect.

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

I think there are three extensions which together demand the capability
command for POP3.  The SASL AUTH command (RFC 1734), the STARTTLS
extension (draft-newman-tls-imappop-04.txt), and the LANG command (which
hasn't been written yet).  I expect these to be popular down the road, and
the last thing I'd want is for POP clients to have to probe for each of
these individually.  Further, since I want draft-newman-tls-imappop-04.txt
on the standards track, I'll simply rip the POP STARTTLS extension out of
that spec if the POP extensions draft doesn't go standards track.  Then
the industry will use the "pops" port for POP+TLS. 

The IMAP WG determined that probing for commands just wasn't a good plan
after months of debate.  So we should either forbid the addition of any
extensions to POP3 (including those necessary for internationalization
and TLS support), or we bite the bullet and put this on the standards
track.

> In the absence of more community input, my recommendation would be to direct
> the authors to remove all of the capabilities from this document, except those 
> which are already defined in standards-track documents.  Additional capabilities 
> could be defined in a separate experimental or informational RFC.

Ok, here's what we have:

TOP    -- RFC 1939, section 7
USER   -- RFC 1939, section 7
UIDL   -- RFC 1939, section 7
SASL   -- RFC 1734
EXPIRE -- RFC 1939, section 8 second bullet item.  In fact just announcing
this standards-track server behavior potentially resolves the problem
described in paragraph containing "may be confusing to the user
community." 

The "LOGIN-DELAY" option is based on a feature deployed in several servers
including Innosoft's and CMU Cyrus pop3d which only allows people to login
with a certain frequency to improve server scaling and reduce load.
Unfortunately, this creates a user confusion scenario when setting the
"mail check interval" since the POP client can only discover the interval
by annoying trial & error.  Without such a feature, some users will check
mail every 5 seconds or worse.  Imagine trying to scale a POP server with
that setting on all the clients.

The "PIPELINING" option is identical to the one in ESMTP, for similar
reasons.  I think this is a no-brainer.

I could care less about the "IMPLEMENTATION" capability.

The only other issue is the response codes which I believe are justified
both because of their successful addition to IMAP2, and because clients
are currently doing strcmp()s on the returned error strings which is
neither internationalizable nor interoperable.

		- Chris