[NNTP] Thoughts on article number resetting/rollover

[Andrew - Supernews]

>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:

 Ken> The whole discussion of the 2^32 limit for article numbers and
 Ken> rollover got me thinking a little.  Rolling the numbers over is
 Ken> really no different than if the server unilaterally resets the
 Ken> article numbers for some reason (server crash, software
 Ken> change/upgrade).

It's actually very different.

The most common cases where article numbers are reset are (in roughly
descending order of probability):

1) the client ends up talking to a completely different server, where
there is no relationship between the old and new numbers at all
(e.g. when a service is outsourced, or the outsource provider is
changed; ISPs are _incredibly_ bad at managing this changeover, and
will almost never give users any warning)

2) the group is reset completely on the server with all articles
removed, and the numbering reset either to 0 or to some arbitrary
point

Everything else is likely to be down in the noise; in particular,
renumbering of existing articles within a group is something that
servers as a rule simply do not do.

 Ken> We need look no farther than IMAP (which also has a 2^32 limit
 Ken> for article/message numbers BTW) for a solution.  Each mailbox
 Ken> on an IMAP server has a UIDVALIDITY metadata item (usually a
 Ken> timestamp).  Any time the existing UIDs of a mailbox are
 Ken> reset/reordered, the server changes the UIDVALIDITY on the
 Ken> mailbox (new messages appended to the mailbox does NOT cause any
 Ken> change to UIDVALIDITY).  When the client sees a change in the
 Ken> UIDVALIDITY, it flushes its cache and re-reads the mailbox to
 Ken> get the new message UIDs and contents.

Hard to coordinate this between independent, non-cooperating servers
(see the outsource case above).

 Ken> A mechanism like this seems like a pretty trivial extension to
 Ken> NNTP (one extra param in the GROUP, LISTGROUP, and LIST ACTIVE
 Ken> responses)

You think you can alter those responses without breaking _every single
client_ in existence?

-- 
Andrew, Supernews
http://www.supernews.com