ietf-nntp New wording on article numbers - draft 2

[Chris Hall]

In article <ZP0TqJAMnAzyEwKe at on-the-train.demon.co.uk>, "Clive D.W.
Feather" <Clive at on-the-train.demon.co.uk> writes
>Jack De Winter <jack at wildbear.on.ca> writes
>>>Don't use "current", that has temporal signifigance, and the
>>>"current" high water mark will change when a new article arrives
>>>(you just don't know it yet).  Use "the high water mark reported"
>>>or something like that.

>>There was one gent who said that he cached the information when the
>>group command was issued.  How would this affect your description here?
>>In that sense, current is kind of foggy, and having an indication of
>>significance might make the problem worse or better.

>"current" is defined to be the value returned by the most recent GROUP
>command on this connection. However, since people have obviously missed
>this point, I've changed the wording to use "reported" instead.

>>Agreed.  I think the point we need to address here is: what happens if
>>a client is keeping track of articles, the lwm goes above the article
>>and it is reinstated?  what happens if the client thinks it has read
>>the article (I fetched all of the articles that were there from 1 to
>>20, but did not get 13 as it was not there.  It is now reinstated.
>>How do I know that 13 has been reinstated and that I should look at it?)

I think the short answer is that you don't, unless you check everything
in the range each time you talk to the server.  For those using NEWNEWS,
the article is reinstated with the original timestamp, so unless the
client is extremely peculiar, a reinstated article will be missed by
those who collected news while the article was AWOL.

>I've assumed that the client is keeping a record of the form:
>    1-12,14-16,18-20
>If 13 reappears, it will see it and fetch it then.

I suppose that the client could do a series of NEXTs across the range
and check off the known articles against the available ones -- fetching
information about the unknown articles.

Or the client could probe the gaps in the previously known range, to see
if they've been filled in.  (Except the server is not promising that the
article number range is ever densely populated.)

If clients generally worked in either of these ways, then the dreaded
backfill would not have been a problem :-)

Others will correct me if I'm mistaken, but I think that clients that
store information assume that they do not need to worry about articles
with numbers less than the largest article number they've seen to date.
(Equivalent, in fact, to NEWNEWS, but without the complicating time
element.)  Hence the insistence on newer articles having higher numbers.
Hence also, some people will never see an article that has been
reinstated.

The significance of the LWM is, I think, otherwise.  A client that is
storing information could use the LWM to drive its expiry mechanism.  It
could take the view that there is no point storing information about
articles that are definitely no longer available on the server.  Such a
client would be assuming an LWM which only increases.  Do such things
exist ?

Of course, you know and I know that some servers reset their article
numbering scheme every now and then.  So clients may generally assume
simple behaviour of LWM and article numbers, but must be prepared for
the occasional complete upheaval !  Is anyone aware of clients that push
the panic button if they see the LWM go backwards ?

>However, if the LWM goes to (say) 15, the client is entitled to assume
>that article 13 will never reappear. It can thus change its record to:
>    1-16,18-20
>
>I've then said that 13 MUST never reappear, because you've reported a
>LWM of 15.
-- 
Chris Hall                                       Chris.Hall at turnpike.com