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

Nat Ballou <NatBa@microsoft.com> Fri, 27 December 1996 20:32 UTC

Received: from cnri by ietf.org id aa27736; 27 Dec 96 15:32 EST
Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa15332; 27 Dec 96 15:32 EST
Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id OAA21520 for ietf-nntp-outgoing; Fri, 27 Dec 1996 14:23:59 -0600 (CST)
X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id OAA21515 for <ietf-nntp@ACADEM2.ACADEM.COM>; Fri, 27 Dec 1996 14:23:54 -0600 (CST)
Received: from tide03.microsoft.com (firewall-user@tide03.microsoft.com [131.107.3.13]) by academ.com (8.8.4/8.7.1) with ESMTP id OAA17761 for <ietf-nntp@academ.com>; Fri, 27 Dec 1996 14:23:52 -0600 (CST)
Received: by tide03.microsoft.com; id MAA20809; Fri, 27 Dec 1996 12:23:46 -0800 (PST)
Received: from unknown(157.54.17.74) by tide03.microsoft.com via smap (V3.1) id xma020804; Fri, 27 Dec 96 12:23:17 -0800
Received: from IMSMAIL ([157.55.65.201]) by imail2.microsoft.com (8.7.3/8.7.1) with ESMTP id MAA03862 for <ietf-nntp@academ.com>; Fri, 27 Dec 1996 12:23:40 -0800 (PST)
Received: from natba1 - 157.54.22.213 by ims.microsoft.com with Microsoft SMTPSVC; Fri, 27 Dec 1996 12:27:54 -0800
From: Nat Ballou <NatBa@microsoft.com>
To: ietf-nntp@academ.com
MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US
Subject: Re: ietf-nntp My notes from the NNTP WG meeting at the 37thIETF
Date: Fri, 27 Dec 1996 12:20:08 -0800
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1160
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <067cb5427201bc6IMSMAIL@ims.microsoft.com>
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

> From: Jack De Winter <jack@wildbear.on.ca>
> To: Chris Newman <Chris.Newman@INNOSOFT.COM>OM>; Rich Salz <rsalz@osf.org>
> Cc: ietf-nntp@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