[NNTP] LIST EXTENSIONS (again)

[Clive D.W. Feather]

Ken Murchison said:
> The main point is that we need a way to specify the core functionality 
> and behavior to the client.  I *think* we are all in agreement on this 
> point.

Indeed (well, I agree).

>> Case 3: a new specification is not upwards compatible for whatever reason.
> Hopefully case 3 is never allowed to happen without *very* good reason, 
> but discussing it OK.

We need to think about it, otherwise we risk being hit over the head later
when it happens. Look how OVER is incompatible with the old XOVER, and some
of the similar debates of the past.

>> Approach C is my preference and matches (e.g.) HTTP. I only suggested an
>> alternative because people choked on the major.minor idea previously.
> A and C seem to be functionally identical to me and just differ in the 
> syntax.

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.

*B* and C are functionally equivalent - the server indicates all the client
versions it can work with and the client needs to know only its own
version. B does it explicitly, while C does it implicitly.

Let me present it another way. Let's suppose that we have RFC 3977, a
compatible update in 4321, and an incompatible one in 5555. There are
three types of server, which issue responses:

  Server type:       3977            4321            5555
                   ---------------------------------------
  Approach A         3977            4321            5555
  Approach B         3977            3977 4321       5555
  Approach C         2.0             2.1             3.0

There are *four* types of client:
  (P) 3977 that doesn't know 4321 exists ) this distinction only
  (Q) 3977 that *does*  know 4321 exists ) matters in approach A
  (R) 4321
  (S) 5555

When they meet, we get:

  Server type:       3977            4321            5555
                   ---------------------------------------
  Client type P:     works          [1][3]             reject
  Client type Q:     works          [2][3]             reject
  Client type R:      [4]            works           reject
  Client type S:    reject          reject           works

[1] Reject in approach A, because 3977 != 4321.
[2] Works in approach A because the client knows that 4321 encompasses
    3977 as a subset.
[3] Works in approach B because server response includes 3977; works in
    approach C because 2.1 >= 2.0 but indicates compatibility.
[4] Works in approaches A and B because the client knows 3977 was a subset
    of 4321; works in approach C because 2.0 indicates compatibility. In
    both cases the client needs to know which features to avoid.

> My main point was that we should enumerate the 
> optional LIST commands.

Agreed (again).

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