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

Message-ID: <[email protected]>
Priority: NORMAL
X-Mailer: Simeon for Win32 Version Mercury a9 Build (12)
MIME-Version: 1.0
Content-Type: Multipart/signed; BOUNDARY=Part9807160804.F; protocol="application/pgp-signature"; micalg=pgp-sha1

--Part9807160804.F
Content-Type: Text/PLAIN; CHARSET=US-ASCII


On Wed, 15 Jul 1998 17:32:43 -0700 Randall Gellens <[email protected]> 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.

Hmm ... that works as long as all servers that support AUTH also support CAPA.
I presume that it was the concensus of the group that there were no servers 
that supported AUTH without supporting CAPA as well.   I do know that the 
current Cyrus server release supports AUTH but not CAPA.    That's why I 
raised the issue.   I have implemented both in the client and do the probe
because I know of at least one deployed POP3 server that does it.

I think that we need to pick one way or the other and make both documents 
agree on the choice.   There can't be that many implementations yet.   This
would force any server implementations of AUTH to do the right thing (yet to
be defined).   As long as both go to Proposed in agreement, we should be able
to get consistent implementations.

Am I worrying over nothing?   What other implementations, client or server, 
are their of AUTH and/or CAPA?

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

--Part9807160804.F
Content-Type: Application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.1.1 (C) 1997 Pretty Good Privacy, Inc. (Diffie-Helman/DSS-only version)

iQA/AwUBNa4Iati5Jj9Fn5KMEQL85ACgxq0Kg7FKaxRHQVH79a92+YX3/BMAn1CG
CZUtzdF0PLy4SVdKuMKsQYK0
=/6hC
-----END PGP SIGNATURE-----

--Part9807160804.F--