[NNTP] LIST EXTENSIONS (again)

[Clive D.W. Feather]

In message <418A867A.4020204 at oceana.com>, Ken Murchison <ken at oceana.com> writes
>>  In A, case 2, the client needs to know that 4321 exists and is
>>upwards
>>compatible; otherwise it will barf when it meets a 4321 server. In C, a
>>2.0 client automatically knows that 2.1 is upwards compatible.
>
>I think you're splitting hairs here.  Why does a 2.0 client know that
>2.1 is upwards compatible?  Just because of the version number?

Yes.

>Whether it seems obvious or not given your choice of syntax, it still
>MUST be explicitly document somewhere that 2.1 retains 2.0
>functionality (AFAIC 2.0 and 2.1 are still meaningless tokens at a
>protocol level).

No. That's the difference between A and C. If we went down path C, the
base specification would explicitly state that x.1 is upwards compatible
with x.0 and so on. The token is *structured*, unlike A and B.

In other words, the process is *reversed*; the author of RFC 4321 picks
a version number of 2.1 *because* it is upwards compatible, while the
author of 5555 picks 3.0 *because* it is not.

>The same would be true in the A case, RFC 4321 MUST explicitly state
>that it retains RFC 3977 functionality.  In either case, the client
>knows this because the author read the specs and programmed accordingly.

Not so.

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