[NNTP] AUTHINFO diffs

[Ned Freed]

> Ken Murchison <ken at oceana.com> writes:

> > Right, the suggestions are to wait for the updated DIGEST-MD5 or go with
> > TLS+PLAIN.  We just need to select at least one mandatory to implement
> > (not necessarily mandatory to use) mechanism, so that two conforming
> > implementations can always be configured to interoperate.

> > IMO, PLAIN is the simplest to implement, but this is going to then
> > mandate that every implementation also supports TLS.  The only mechanism
> > other than PLAIN or DIGEST-MD5 which we could mandate would probably be
> > GSSAPI.

> I would rather not require TLS.

Agreed.

> Adding SASL support is significantly
> easier than adding TLS support.

Agreed as well. There are libraries available for both, but generally speaking
adding TLS  is a trickier proposition.

> Requiring GSSAPI feels like a non-starter
> to me as well; some Cyrus SASL builds don't even include GSSAPI with the
> default module set due to the other library dependencies.

I'm not an NNTP implementor so I hesitate to call this a total nonstarter, but
GSSAPI certainly has proved to be a nonstarter for many implementations of
other protocols. (Poor library quality is part of this, but not all. GSSAPI is
simply too complex.)

> This makes me think that we should probably wait for DIGEST-MD5, as much
> as I dislike that.  :/  Do we have any feel for how long that delay is
> going to be?

Well, there's already a draft (draft-ietf-sasl-rfc2831bis-05.txt, right?), so
don't have to wait to cite it. Unless the IESG has created even more procedural
folderol I'm unaware of, there should be no problem last-calling a document
with a normative reference to such a draft. Actual publication as an RFC would
have to wait for that reference to resolve, but having a draft that's in the
RFC Editor queue is where this WG's responsibility ends. If it makes sense for
a document to sit in that state for a while, so be it.

IMO only, of course.

				Ned