[NNTP] Large article numbers extension

[Clive D.W. Feather]

Firstly, let us learn from the past and *not* call this - or make it - a
"64 bit" facility. Hence the new subject line.

For the purposes of this message, I call the proposed extension BIGNUM.

Let's start by defining a bit of notation: {MC} is the largest article
number that the client can cope with, {MS} is the largest article number
that the server can cope with, and {MA} is the largest article number
currently in use in the server. Draft 27 requires that {MC} and {MS} both
be no less than, and that {MA} be no greater than, 4294967295. {MU} is the
minimum of {MC} and {MS}.

Clients normally get article numbers from the server, rather than making
them up out of whole cloth, so that direction is less of a problem. If it
does send a number greater than {MS}, it has violated a MUST and the server
can respond appropriately (probably a 501 or 400).

So, as I see it, we have three problems to address:
(1) How does a server tell a client that it has article numbers greater
    than 2^32-1 (or 2^31-1) sitting around?
(2) How does a client tell a server that it can cope with article numbers
    greater than 2^32-1?
(3) What does a server do if it has an article number greater than the
    client can cope with?

Question 1 is the easiest. In the CAPABILITIES output, the server includes
the label BIGNUM with argument {MS}:

    [C] CAPABILITIES
    [S] 101 Capability list:
    [S] VERSION 2
    [S] READER
    [S] NEWNEWS
    [S] LIST ACTIVE NEWSGROUPS
    [S] BIGNUM 9876543210987654321
    [S] .

In the absence of this capability, the client assumes {MS} is 4294967295.

Question 2 is also pretty easy. {MC} is sent as a command and {MU} returned
in the response:

    [C] BIGNUM 314159265358979323
    [S] 202 314159265358979323 is our mutual minimum
    [C] BIGNUM 31415926535897932386468
    [S] 202 9876543210987654321 is our mutual minimum

Until this command is used, the server assumes {MC} is 4294967295.

We're now left with question 3. The server provides article numbers in the
following places:

    211 response from GROUP/LISTGROUP
    LIST ACTIVE 215 response content
    NEWGROUPS 231 response content

    22x response from ARTICLE/HEAD/BODY/STAT/LAST/NEXT
    HDR 225 response content
    LISTGROUP 211 response content
    OVER 224 response content

The division is for a reason. The first three cases report the high water
mark of a newsgroup, and are therefore the first place the problem will
appear. The other four cases are less problematic because a number greater
than {MC} can only appear in four situations I can think of:
- GROUP or LISTGROUP was used with a group whose high water mark is greater
  than {MC};
- the high water mark on entry was {MC} but a further article appeared
  later;
- the server is sending an article number, rather than 0, when the client
  specified a message-ID;
- the client used an article number greater than {MC} as an argument.

The third of these can simply be forbidden, and the fourth is already a
MUST NOT. The other two can be addressed simply by using the generic
response
    401 BIGNUM
(possibly with a second argument giving the maximum article number in the
group).

So now we're down to one basic situation: how to report a group with large
article numbers in GROUP, LISTGROUP, LIST ACTIVE, and NEWGROUPS. Here is
what I would propose:

* If the client has not used the BIGNUM command, the server acts as if
  the high water mark is 4294967295, except that NEXT fails with 401 BIGNUM
  instead of 421 ("no next article").
* If the client *has* used the BIGNUM command, article numbers greater than
  the current {MC} are prefixed with a tag (e.g. a plus sign) to indicate
  that they are too big.

Thoughts?

----

A couple of bits of syntactic sugar.

I could live with the BIGNUM command *also* being permitted as an argument
to CAPABILITIES:
    [C] CAPABILITIES BIGNUM 314159265358979323
though I don't see it as a significant need.

I could also live with a notation like "^31" being allowed, in both
directions, as a synonym for 2 to that power minus 1; that is:

    BIGNUM ^40

is equivalent (if my calculator isn't lying) to:

    BIGNUM 1099511627775

though, again, it isn't a major issue.

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