[NNTP] 64-bit article counter extension strawman
Russ Allbery
rra at stanford.edu
Sun Jul 17 17:59:50 PDT 2005
Ken Murchison <ken at oceana.com> writes:
> I gave some more thought to this today and came up with the following:
> - Servers which support 64-bit (large) article counters advertise a
> capability such as 'LARGEGROUP' (or some better named capability).
> - If a group has exceeded the 32-bit article count, and the server
> supports the extension, then it uses a new 212 response code to
> GROUP/LISTGROUP which tells the client that the response may contain
> 64-bit numbers.
> - Similarly, a new 216 response code is used for LIST ACTIVE if any of
> the requested groups has exceeded the 32-bit article count.
> - Clients which don't support this extension will not understand the new
> response codes and *should* fail elegantly.
This is pretty nasty from a backward compatibility standpoint. Old
clients that rely on LIST ACTIVE would potentially be unable to use the
server at all. Plus, I hate to change the response code for a standard
command.
> As an alternative:
> - Servers which support 64-bit (large) article counters advertise a
> capability such as 'LARGEGROUP' (or some better named capability).
> - Servers always hide (411 response for [LIST]GROUP, ommission from LIST
> ACTIVE response) groups which have exceeded the 32-bit article count
> from clients until the client tells the server that it can support such
> groups.
> - A client tells the server that it supports large groups by using the
> new keyword 'LARGEGROUP' as an argument to the CAPABILITY command.
> - The server can then use the existing response codes for the
> [LIST]GROUP and LIST ACTIVE commands.
I like this a lot better; this was the sort of extension that I had in
mind.
One possible variation would be to add a new command other than GROUP for
accessing large-numbered groups and a new command other than LIST ACTIVE
for retrieving active file information, which would obviate the need for
client-side negotiation and storing additional server state to remember if
the client supports large-numbered groups.
--
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list