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

On Wed, 08 Jul 1998 21:30:01 -0400 Keith Moore <[email protected]> wrote:

> Does it need more wordsmithing?

The wording seems fine to me.   Certainly good enough to implement against. 

> Are all of these capabilities needed?

I think that you will find individuals that support all of the capabilities 
listed.    I personally believe that most of them are useful, and many of
them are indepensable.

> Are all of the capabilities defined with sufficient precision?

Yes.   There are some conflicts though I think.   See below on the discussion 
of the SASL support.
 
> Should the document be standards track or should it be Informational or 
> Experimental?

The document should definitely be standards track.   Certain "optional" 
features like UIDL and TOP are unwieldly at best to implement without a
capability probe.   Perhaps it is because we were an IMAP4 mailer first 
(and therefore use to CAPABILITY), I *really* found I missed it in POP3.

> Should the extension mechanism be separated from (and perhaps a different 
> status from) the extensions themselves?

I don't know.   If it wasn't late in the process, I would say that the 
capabilities that reflect policy behaviour should be outside; leaving only 
those capabilities that reflect optional standard behaviour ie. UIDL, TOP
etc.

I also wasn't sure about the AUTH capability support.    It is a wonderful 
idea -- one that I am certainly used to in IMAP, ACAP, and SMTP AUTH.   The
only thing is that John's update to the POP3 AUTH extension defines a probe
function (AUTH with no arguments) for listing available server mechanisms.   
Perhaps there has been discussion on removing the probe (going back to the
RFC1734 behaviour) in favour of the capability response.   As it is, there
are two ways to get the same information.   I'm not sure if this is a problem
or not.    I'm not sure which to implement in my client.

> If the document is approved for Proposed, should all of the proposed extensions 
> be included?  Or should some of the extensions be moved to a separate 
> Informational or Experimental?   Which ones?

Unless they are private extensions, they should not be informational.   It 
does not make sense to me that you would even do an informational document
for an extension that you expect to get interoperability between multiple 
implementors on.   It would be wise to set the policy right up front that 
extensions go on the standards track, at least as experimental.   They can
always be punted later if nobody finds them interesting enough to implement 
and deploy.

Cheers.
---  
Steve Hole                           
The Esys Corporation
Mailto:[email protected]  
Phone:403-424-4922