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

[Jack De Winter]

At 12:54 PM 12/20/96 -0800, Nat Ballou wrote:
>> 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.

SASL is not such a type, it is the framework.  It contains those types.
Once again, allowing SASL to work would depend on truly defining an
extensible framework within 977bis, not just saying 'here it is and
plug in what you will'... there is a big difference.

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

My turn Nat... 'again, you lost me'...

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

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.

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 576-3873		http://www.wildbear.on.ca/

Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.