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

On Fri, 10 Jul 1998, Steve Hole wrote:
> 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.

There was a long discussion on this issue a few months ago which I believe
came to the rough concensus that most would prefer a slow migration to the
capability list, so that clients only have to do one kind of feature
probe.

The current draft of the POP3 STARTTLS support requires that CAPA be
implemented.  That way, one doesn't have to probe for STARTTLS, then probe
for SASL AUTH mechanisms, then probe for each optional command separately.

As for what to do in a server or client, the server code I wrote does both
the SASL list in the capabilities and the list in response to "AUTH" with
no arguments in John's draft.  That's not hard to do.

On the client side, I'd suggest using AUTH with no arguments if you're
using the non-standard LOGIN or NTLM mechanisms since I believe those were
deployed by one vendor with whom some clients may wish to interoperate. 
Otherwise, I'd rely on the SASL capability response, presuming it doesn't
get cut from this proposal. 

		- Chris