[NNTP] LIST EXTENSIONS (again)

Tue Nov 2 07:37:16 PST 2004

Ken Murchison said:
>> (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.

It is.

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

Two things. Firstly, I want the number separate from the pseudo
extension-label, to make it clear that it is a number and not an arbitrary
string. Whether it's "_RFC_ 3977" or "_NNTP_ 2" is secondary.

Secondly, we're back the the versioning issue again.

There are three basic cases to consider and, as far as I can see, three
approaches we could follow.

Case 1: a new specification makes absolutely no changes to what's on the
wire; it just clarifies things.

Case 2: a new specification is completely upwards compatible but adds new
facilities. Note: a MODE NEW command that *changed* the semantics of
existing commands is fine, so long as an unsuspecting client doesn't see
the changes.

Case 3: a new specification is not upwards compatible for whatever reason.

Approach A: the server lists the latest RFC to which it conforms. The
client needs a list of RFCs that it can handle.
- Following a case 1 change, the number does *not* change; the server
  continues to reply "3977" and not "4321".
- Following a case 2 change, the number does change; the server replies
  "4321". The client needs to know that it can talk to either 3977 or 4321
  servers even if it doesn't grok the extra features of the latter.
- Following a case 3 change, the number does change; the server replies
  "4321". The client needs to know that it can talk to 3977 but not 4321
  servers, or it needs separate code paths contingent on the two.

Approach B: the server lists all the RFCs to which it conforms. The client
needs only know a single RFC (unless it has multiple code paths).
- Following a case 1 change, the number does *not* change; the server
  continues to reply "3977".
- Following a case 2 change, the number does change; the server replies
  "3977 4321". The client recognises 3977 and works, or it recognises
  4321 and uses the additional features.
- Following a case 3 change, the number does change; the server replies
  "4321". The client needs to know that it can talk to 3977 but not 4321
  servers, or it needs separate code paths contingent on the two.

Approach C: there are major and minor version numbers; what we have now
is 2.0. The client needs only know its current version number.
- Following a case 1 change, the number does *not* change; the server
  continues to reply "2.0".
- Following a case 2 change, the minor number changes and the server
  replies "2.1". A 2.0 client knows that 2.1 is upwards compatible and
  talks 2.0. A 2.1 client can use the extra features with a 2.1 server,
  and ignores them with a 2.0 server.
- Following a case 3 change, the major number changes; the server replies
  "3.0". A 2.x client knows that it can't handle this, or it has separate
  2.x and 3.x code paths.

Approach C is my preference and matches (e.g.) HTTP. I only suggested an
alternative because people choked on the major.minor idea previously.

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

I haven't done it. I'd very much like it to be done, but the RFC editors
don't seem to be talking to me - they still haven't answered my comment
about them mangling the last few drafts (as Ken, I think, first realized).

Russ? Can you have a go at this?

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

Note, I think that's stronger than what we had before.

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

These are features of the core protocol, not extensions. Therefore, in my
opinion, they belong with the support information for the core extension.
Note how we have "OVER MSGID" rather than separate "OVER" and "OVER-MSGID"
capabilities.

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

Nor do I. I have no objection to splitting them; I'm just getting chary of
making complex-looking proposals (even when they're actually conceptually
simple).

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

I'd prefer:

  [C] LIST EXTENSIONS
  [S] _NNTP_ 2.0 MODE_READER LIST_ACTIVE_TIMES LIST_NEWSGROUPS
  [S] STREAMING
  [S] .

for the reasons given above.

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

Of course.

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

Agreed.

Um, I'm not going to swear there's no other significant options that are
worth noting here. Can anyone think of any?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |