[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