[NNTP] Version numbers

[Clive D.W. Feather]

[Splitting off a sub-thread.]

Russ Allbery said:
> Okay, I've read and I think digested all of the long threads about the
> NNTPv2 label and related issues.  I'm pleasantly surprised that everyone
> agreed that we should have the protocol version advertised; I thought that
> was going to be controversial!

You weren't going to get an argument from me.

> I think we need to be able to say what version of the base protocol
> specification the server follows (everyone agrees on this).  I would
> prefer to copy IMAP as closely as possible here because IMAP has done this
> and we know that it works in practice,

Can you summarize?

> I don't think we need to know what version of an extension the server
> supports because I don't expect extensions to have versions.

Okay, I can live with that.

> If a command changes in a non-backward-compatible way, I think a new
> command should be introduced instead and the old one left alone and
> deprecated.

I can live with that as well.


> If a command changes but in a backward-compatible way, this is why we have
> additional arguments to the extension advertisement.  Like with OVER
> MSGID, we can define a way to advertise the new capability with more
> specificity than is offered by a version number.

True.

> I see what Clive is getting at by making the extension label "NNTP 2" or
> the like instead of "NNTPv2", but I think it's better to go the route that
> lets us advertise compatibility with multiple NNTP versions rather than
> going the route that lets clients compare numbers.

There's two or three points that are getting conflated here.

Firstly, given that we're hacking this into LIST EXTENSIONS rather than
working through a capability system from scratch, I'd much much rather
that everythign about the core protocol was in one entry. I see Mark has
made comments about parsing and syntactic sugar, but I think he's wrong
here.

So what I'm suggesting is that there is a line with pseudo-extension-
label "_NNTP_" (or "*", or anything that couldn't be a real extension)
that represents "the core protocol". Then the arguments to that label give
the various properties we're documenting. I'd further make it simple by
saying:
- arguments beginning with a digit represent the supported version(s);
- arguments beginning with a letter indicate support for options.

> Again, I'd rather
> follow IMAP here.  I don't see a need for minor protocol revisions
> indicating backward-compatible changes; I think that is subsumed by the
> ability to advertise compatibility with multiple revisions (listing both
> NNTPv2 and NNTPv3 extension labels, for instance).

As I've already said, there are three ways to do this.

(A) Version numbers are magic cookies. Server advertises its own version
and the client has to know which versions it can work with.
(B) Version numbers are magic cookies. Server advertises all the
versions it supports and the client is happy if any of them appear.
(C) Version numbers are structured. Server advertises its own version
and client deduces whether it can work with that.

If version 3 is upwards compatible with version 2, then the server
information line for a v3 server is:

  (A)      "_NNTP_ 3"          Old client needs to learn about 3.
  (B)      "_NNTP_ 2 3"        Old client sees the 3.
  (C)      "_NNTP_ 2.1"        Old client knows it supports 2.N
                               for all N (since it was written for 2.0).

I personally think C is better than B and I think that A is really
horrible in our problem domain (many client implementations, few server
implementations).

> I don't think using an RFC number instead of an arbitrary version number
> is a good idea for the reasons that Ken stated.

Okay; it seemed a good idea at the time.

I'm proposing numbers, rather than "V2", because they're less likely to
be used as extension or capability labels and so we can reserve the
entire namespace right now. Using "V2" means we have more risk of
running into another use of that name-format (e.g. "V21" is or was an
ISP in the UK). It's not a huge deal, but on the other hand versioning
*is* something I've had experience of in the past and this seems within
my editorial purview.

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