[NNTP] LIST EXTENSIONS and an NNTPv2 capability

Russ Allbery rra at stanford.edu
Tue Oct 12 15:06:28 PDT 2004


Okay, let's see if I can explain this in a way that makes it both fairly
simple and shows why people want it.  I'm going to cc Mark Crispin in the
hope that he'll be willing to clarify any portions of this that I didn't
quite get right.

I'm sorry that this has taken me so long; I have rather too many balls in
the air just at the moment and am scrambling desperately to try to keep
track of all of them.

The way that a proper client of a protocol that supports an extension
mechanism should behave is that immediately after connecting, it inquires
as to the capabilities of the server.  Subsequently, it assumes those
listed capabilities are accurate and does not attempt to use any
capabilities that were not advertised.  I realize that this is not how
NNTP clients have ever worked in the past -- this is something that we're
seeking to change by adding a proper extension mechanism.  This is how
everyone else does it (IMAP, POP, SMTP, etc.), and we're trying to bring
NNTP in line with other Internet protocols.

Given this new approach, and given the way a client should be implemented
when complying with our draft, there are two problems with the LIST
EXTENSIONS mechanism as currently present in our base draft.  After
talking with Mark Crispin about this, I think that this is something that
we can and should correct before the draft is published, since we do have
the opportunity.

The first problem is that, since LIST EXTENSIONS has been around as an
idea for quite some time, there is at least one known badly bogus
implementation.  Netscape Collabra implements LIST EXTENSIONS, but the
information that it returns cannot be relied upon.  In particular, it
advertises OVER but doesn't implement OVER properly.  We'd previously
discussed this problem and had tentatively decided to live with it, but
there's a better solution described below.

The second problem is that, based on our drafts, at least one
implementation (INN) and possibly others have started adding LIST
EXTENSIONS.  However, the extension list was not finalized, and in
particular AUTHINFO was not advertised by the early INN implementation
even though AUTHINFO USER was supported.  A client that uses the extension
mechanism properly would therefore think that those servers didn't support
authentication when they do.

The proposed solution is this:  Specify in our base draft that any server
that fully complies with the new specification advertise the NNTPv2
capability as part of LIST EXTENSIONS.  Clients can then ignore or treat
with dubiousness any server that doesn't advertise that capability, thus
solving the Collabra problem.

We also need to somehow specify that any server that implements AUTHINFO
USER needs to advertise it if it advertises the NNTPv2 capability.  I'm
not completely sure of the best way to do that; one way would be to
specifically mention the three legacy extensions that we're standardizing
(AUTHINFO, STARTTLS, and CHECK/TAKETHIS or STREAMING), and another would
be to require that the server advertise an extension for any commands that
don't begin with X.  A third approach would be to recognize that this
blessing of widely implemented commands that predated the extension
mechanism is a one-time transition.  This probably requires some more
discussion to find the best approach from a transition standpoint.

However, the goal is to make LIST EXTENSIONS reliable, including for
everything that we're blessing under its existing command names, so that
clients can just read the output and then use that information without
having to second-guess it.  Without doing this, LIST EXTENSIONS is both
badly different from the way that other protocols use it and not actually
useful for clients.

I think this approach has a lot of merit, and that it's easy enough to add
the NNTPv2 requirement to the existing draft.  I also think that this is a
minor enough change that it's worth doing this late in the process,
although I'd appreciate it if Scott would check me on this.
(Unfortunately, Mark had missed the IETF-wide last call notification and
this issue didn't come up until afterwards.)  Note that this method of
advertising a protocol version in the extensions output has also been used
successfully with IMAP.

Thoughts?

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the ietf-nntp mailing list