ietf-nntp My notes from the NNTP WG meeting at the 37thIETF

[Nat Ballou]

> From: Jack De Winter <jack at wildbear.on.ca>
> To: Chris Newman <Chris.Newman at INNOSOFT.COM>; Rich Salz <rsalz at osf.org>
> Cc: ietf-nntp at academ.com
> Subject: Re: ietf-nntp My notes from the NNTP WG meeting at the 37thIETF
> Date: Friday, December 20, 1996 1:38 PM
> 
> [... this is actually a follow-up to two of Jack's messages ...]
> 
> >Using AUTHINFO GENERIC as defined seems the fast path to getting
> >977bis out.  Adding new commands belongs in extensions.
> 
> I agree with this.  My contention is that there may be existing
> implementation that may use AUTHINFO GENERIC in a way that could
> contradict with the SASL stuff.  If we specifically put information
> into the spec that says words to the effect of 'AUTHINFO GENERIC
> allows the use of any protocols defined through the SASL framework'...
> then I would give it my rubber stamp.
> 
> Once again, if we can implmenent AUTHINFO GENERIC so that it is in
> effect SASL, then I agree with it 100%.  Otherwise, I am concerned
> about any implementations that may have done something else with it.
> And I would strongly object to AUTHINFO GENERIC SASL as the space
> occupied by SASL should be for authentication type, not the SASL
> framework.

O.K. - now I understand where you are coming from - and I agree
with making AUTHINFO GENERIC support the SASL framework for NNTP. 

> p.s. What would be the best way of showing a list of the valid
>  authentication types in NNTP?  LIST AUTHINFO?  AUTHINFO LIST?

A while back, I threw out the following behavior for the AUTHINFO
command :

	C: AUTHINFO GENERIC
	S: 281 List follows
	S: KERBEROS_V4
	S: GSSAPI
	S: .

That is, an AUTHINFO GENERIC command with no arguments would return 
a CR/LF separated lis of authentication providers supported by the 
server.  This is similar to Myer's AUTH SASL proposal for POP3/IMAP.
This is a simple change to AUTHINFO GENERIC that is unlikely to
break any existing clients and provides a simple method for clients 
capable of negotiating authentication providers.

Nat