[NNTP] LIST EXTENSIONS and an NNTPv2 capability

Ken Murchison ken at oceana.com
Wed Oct 13 08:01:09 PDT 2004


Russ Allbery wrote:

[text removed]


I believe you have stated the problem(s) accurately.


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

I'd submit that LIST EXTENSIONS is no longer an optional command for the 
server.  Any server compliant with with RFC 977bis MUST implement LIST 
EXTENSIONS and MUST advertise at least the NNTPv2 capability, even if no 
extensions are implemented.  This serves to tell the client that 
previously optional/non-standard commands that we have standardized as 
part of the base specification (e.g. DATE) are supported.


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

First, I think that the base doc and/or any extension docs have to make 
it clear that if a NNTPv2 server implements an extension it MUST 
advertise the appropriate extension label via LIST EXTENSIONS.

As far as the legacy extensions which we are standardizing, we need to 
document somewhere that any server which supports one or more of these 
extensions and is upgraded to be compliant with RFC 977bis MUST also be 
upgraded to be compliant with the standardized versions of these 
extensions (including advertising it where appropriate).  This is the 
only way that I can see that a client which sees NNTPv2 advertised will 
know if these extensions are supported and how they will behave.

Unfortunately, I don't know where this should be documented.  I don't 
think we can put it in the base doc since we don't want the base doc 
referencing extension docs.  Putting it in the extensions docs doesn't 
really help because a server author may fail to reference them when 
upgrading to RFC 977bis compliance.  Perhaps the best thing would be to 
have a companion (Informational) document to RFC 977bis discussing 
compatibility/upgrade issues.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp



More information about the ietf-nntp mailing list