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

[Nat Ballou]

> From: Jack De Winter <jack at wildbear.on.ca>
> To: Nat Ballou <NatBa at MICROSOFT.com>; brian at nothing.ucsd.edu;
moore at cs.utk.edu
> 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 10:57 AM
> 
> [...]
> 
> >Actually, I'm totally confused by AUTHSASL proposal.  Why is it not 
> >just AUTHINFO GENERIC SASL or something similar?
> 
> There is a problem with the AUTHINFO GENERIC command... there is no
> specification of mechanisms for it.  If someone is using the AUTHINFO
> GENERIC command and has an established set of rules for it, then perhaps
> they could share.  Otherwise, it looks like something that may be the
> same thing as AUTHSASL, but with no definitions.  As such, someone may
> have interpretted it in a different way.  Following all of that, assuming
> that someone has done an implementation that may not fit into the same
> mold, we don't want to break it for them.

Again - you lost me.  The whole reason for adding AUTHINFO GENERIC was
to provide an extendible mechanism for adding new authentication
mechanisms.
I consider SASL to be such an authentication extension.

> Its mostly a backwards compatibility issue.  From my reading, it looks
> like that AUTHINFO GENERIC was supposed to end up being something like
> SASL.  After all, it is defined in terms of the IMAP and POP3
> authentication mechanisms, which are effectively SASL.  

Agreed - so why can't AUTHINFO be like AUTH in IMAP?

> If we had to do away with AUTHSASL in favour of something else, I would
> want it to replace AUTHINFO GENERIC.  As this may cause backwards
> compatability issues, I choose to call it something completely different
> instead.  Also, there may be compatibility problems as the specification
> for GENERIC states that first parameter is the authenticator, and that
> may be in question.  There is also the concept of getting a list of the
> supported authentication types, etc.
> 
> In other words, there are a lot of little things that may get in the
> way.  Creating a separate command is a lot easier than worrying about
> the legal wrangling in the main document.  Remember, we want to get the
> 977bis out and then add on to it.

Using AUTHINFO GENERIC as defined seems the fast path to getting
977bis out.  Adding new commands belongs in extensions.

Nat