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

Randall Gellens <[email protected]>
Newsgroups gmane.ietf.pop3ext
Message-ID <v04100ea5b1d450817810@[129.46.136.131]>
I apologize for the excessive quoting, but I added John Myers to the cc
list and don't know if he's seen this thread or not.

Since the POP Extensions draft references RFC 1734, which does not use
the empty auth command as a probe, I don't think we need to say
anything about that.  I think John's update should include advice on
supporting both CAPA and the empty auth command, in clients and
servers, as Laurence suggests.


At 10:04 AM -0700 7/16/98, Laurence Lundblade wrote:

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

--
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
My friends, no matter how rough the road may be, we can and we will,
never, never surrender to what is right
                  --Vice President  Dan Quayle, in a speech
                    to the Christian Coalition
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.