[NNTP] LIST EXTENSIONS (again)

[Ken Murchison]

Clive D.W. Feather wrote:

> Okay, let me have another go, this time assuming that we only want a
> minimal version indication for LIST EXTENSIONS. Here's a proposal:
> 
> (0) Adopt the "restrict characters in command names and extension labels
> proposal".

If this is the proposal to allow upper/lower and numeric chars (with a 
few extras), I agree.


> (1) Make LIST EXTENSIONS mandatory.

Absolutely.


> (2) Require a version entry in the output from LIST EXTENSIONS. However,
> rather than "NNTPv2", I would suggest:
> 
>     _RFC_ 3977

My only problem with tying the capability to a particular document 
revision, is that the document may be updated in the future to fix 
errata, ambiguities, etc without changing the underlying functionality. 
  For example, RFC3977 gets updated by RFC4321 without change of 
functionality, should the server then advertise "_RFC_ 4321" or continue 
to advertise "_RFC_ 3977"?  I don't think either case is optimal.  By 
choosing a somewhat arbitrary string like "NNTPv2", we're RFC 
revision-proof, and still have the intended behavior.


> (this assumes that _ is not a permitted character); 3977 is the number of
> the final RFC for NNTP. [This approach has been used successfully in other
> standards, and allows more flexibility than just an arbitrary string.]

Has RFC3977 actually been reserved for the new NNTP spec (ala 
RFC282[12]), or did you just pick this as an example?  I think reserving 
3977 it is a good idea, but we'd need to move fast if it hasn't already 
been done, since the RFCs are up to at least 3955 already.


> (3) A conforming server MUST NOT advertise any extension label, other
> than one beginning with X, not in the IANA registry.

Agreed.


> (4) Any specification in extensions should be phrased along the lines of:
> 
>     This specification requires that the server conform to [NNTP],
>     indicated by "_RFC_ 3977" or some higher number in the output from
>     LIST EXTENSIONS.
> 
> or:
> 
>     If the server conforms to [NNTP], indicated by "_RFC_ 3977" or some
>     higher number in the output from LIST EXTENSIONS, then ....
>     Otherwise ....

Yes, we would need some sort of language along these lines.


> (5) I'd *like* to see this entry also used to indicate at least some
> of the optional things that are in the core protocol. For example:
> 
>     _RFC_ 3977 MODE_READER         indicates MODE READER is significant
> 
>     _RFC_ 3977 LIST_OPTIONAL       indicates all four optional LIST
>                                    commands (excludes OVERVIEW.FMT) are
>                                    supported

I like the idea of advertising whether MODE READER is required and which 
optional LIST commands are supported, but I don't see where our new 
token needs to be used as part of this.

Is it realistic to assume that if a server supports one of the optional 
LIST commands, that it would support all of them?  I don't know, I'm 
just asking (especially since Cyrus nntpd which I wrote only currently 
supports LIST NEWSGROUPS).  It seems like it would be better to 
enumerate them as part of the extension label, e.g.:

[C] LIST EXTENSIONS
[S] MODE_READER
[S] LIST ACTIVE.TIMES DISTRIBUTIONS DISTRIB.PATS NEWSGROUPS
[S] .

Obviously, any combination of the four LIST arguments is valid.

If we nail down capabilities for these two items, then a client can 
learn everything it needs to from LIST EXTENSIONS and no longer has to 
guess or do a trial-and-error.  This is a "good thing" IMHO.

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