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

What Randy says below was my recollection too, but Steve has pointed out a
problem with this. Seems as long as there are clients that support only
AUTH and servers that support only AUTH we'll have to continue to implement
both AUTH and CAPA probing in both clients and servers for a while. (All
the more reason to get this on the standards track :-)

Implementing both for the servers is dead simple trivial. The client is a
little more work and introduces an additional RTT if CAPA fails, but I
don't think there are any major difficulties. There are far far worse
attrocities in standards these days, and I don't think there's anything we
can do about it anyway.

LL


At 5:32 PM -0700 7/15/98, Randall Gellens wrote:
>At 7:37 AM -0700 7/10/98, 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.
>
>This issue came up in discussions on John's draft, and the general
>consensus (as I recall it) was that new clients should only implement
>the CAPA mechanism, and new servers should implement both, so that they
>support both new CAPA clients and any clients which have already
>implemented the empty-AUTH mechanism.