ietf-nntp Issue: reinstatement

[Chris Hall]

In article <851805333.28095.0 at office.demon.net>, "Clive D.W. Feather"
<clive at demon.net> writes
><RANT>
>Will people please note that I am *not* talking about either:
>(a) backfilling - allocating article numbers other than in strictly
>increasing order;
>(b) the crazy idea of using the same article number for two different
>articles.
></RANT>
>
>My definition of reinstatement: an article is removed (either because of a
>cancel or expiry), and then the server operator decides that this removal
>was an error and reinstates the article *with the same number*.
>
>In earlier discussion, I was under the impression that people wanted to
>allow this behaviour; the alternative is to state explicitly that, once an
>article has been removed, it will never reappear.

Which seems unnecessarily severe.

>Jon Ribbens:
>> There's a lot of wording taken up with this eventuality. I don't
>> see the need to document it.
>
>If it's allowed, then we need to include enough wording to describe the
>implications, even if it's rare. If it's forbidden, we should say so, so that
>client authors can rely on the fact.
>
>> Even if you do want
>> this stuff in, I don't see a need for the condition that the article
>> number MUST be no less than the first article number.

>Without that condition, the low water mark might decrease. Everyone was
>against that.

If the minimum article number is never to decrease, then it's not
possible in every case to reinstate an article -- it's obviously not
possible to reinstate an article that had the previous minimum article
number [unless it can be guaranteed that no client ever said GROUP
between the removal and the reinstatement !]. 

Either one lives with the curious limitation on reinstatement, or one of
reinstatement or increasing minimum article number has to go.

What difference does it make if the "first" article number in one GROUP
command is less than it was in the previous GROUP command ?

>From the client's perspective the only thing that matters is that new
articles available from the server have higher article numbers than old
articles.  So the client can, *without* missing articles, start from the
highest article number it saw last time (provided that is within the
"first".."last" range).

>I don't know what the concensus mechanism is for this list; when someone
>tells me we have a consensus one way or the other on this issue, I'll
>adjust the wording as needed.

The choices appear to be:

  1. ban reinstatement,

     so it's just tough if something gets removed mistakenly,
     mischievously or maliciously.

     This doesn't seem right.

  2. reinstate with its original article number,

     assuming there's some mechanism at the server to do that !  For
     NEWNEWS purposes the article would have to be reinstated with its
     original "timestamp".

     For clients that remember the state of newsgroups (eg. those that
     use NEWNEWS), there is a problem here.  Clients that look at a
     group in the interval between removal and reinstatement may well
     never see the article !  The longer the delay between removal and
     reinstatement, the greater the number of people who will miss the
     article.

     Reinstatement is a subtle form of back-fill, against which faces
     have been set.

  3. reinstate with a new article number (and new "timestamp"),

     which means that no client should miss the article, but some may
     see the article twice !

     Duplicating articles is anathema.  Nevertheless, I expect clients
     cover themselves against it, and simply ignore duplicates.  But, if
     the delay between removal and reinstatement is long, then there is
     the risk that the client has expired its memory of the article-id,
     and not be able to detect the duplication.

Looks like a choice between evils to me :-(.

If reinstating an article happens once in a blue moon, then option (2)
will recover the situation for as many people as possible, avoiding
article duplication.  But if clients are generally tolerant of
duplicated articles, then option (3) avoids loss of information -- to
the extent that news articles can be called information :-).

If reinstating articles is a common requirement, then there is a serious
problem here.  The client either has to be able to tolerate a form of
back-fill, or it has to tolerate duplicate articles.

Or, the server needs to be able to signal that the client needs to
reconsider what it remembers about the newsgroup.  This is kin to the
problem of resetting the article number range.
-- 
Chris Hall                                       Chris.Hall at turnpike.com