active file too far ahead

[Brian Kantor]

>If so, INN 2.2 is broken.  Per Hedeland doesn't agree with you, he
>says my Gnus is broken since it relies on output from GROUP instead of
>LIST ACTIVE.

It was our intention that GROUP be authoritative for the current numbering
of readable articles in a group.  However, what it's authoritative about
is the RANGE of articles available for reading, not specifics.  It does
NOT say anything about the next number to be assigned to an incoming
article.  And it specifically can be overgenerous; it may tell you a range
of articles in which some or many of the articles are not available.

LIST ACTIVE requires that the client software interpret lines of an
internal file, whereas GROUP unambiguously tells the client what to
believe.  LIST ACTIVE may be informative; GROUP is authoritative.

Frankly, I don't like LIST ACTIVE at all as a means of getting article
numbers - it exposes too much of the internals of the news system to the
clients.  This seems "unclean" to me.

>Well, RFC 977 isn't completely clear, it says "last article".  It
>seems like INN 2.2 interprets that as last _available_ article.

Yes, this has always been a little cloudy.  Shows what 10+ years of
Usenet software development can do to a spec.

Even in B news, which was the only news system we had to base RFC977 on,
there was a brief period during which the highest article number in the
active file had been bumped up by the processing of an arriving new
article, but that article was not completely stored and therefore was not
yet available to be read.  We handled that ambiguity by ignoring it.  This
worked because the write of the active file back to disk in B news was
buffered and did not occur until after the article was stored, so that
even if the next article number had been allocated to the article, it was
not available to the NNRPD because it hadn't become visible in the active
file.  We assumed, at the time, that the active file numbers were good
enough for the GROUP response because they never predicted the availability
of an article that wasn't yet stored.

If used within its intended scope, GROUP may return either the last
article number assigned to a stored article, or it may return the
last article number assigned to a currently-stored article.  The effect
on the client is the same.

The client must be able to cope with successive GROUP response that
return increasing article numbers but which articles cannot be retrieved.
The news client cannot make assumptions that all the articles numbered
in the range given by the GROUP response are there and available.  It
can, however, make the assumption that no article will ever reappear
reusing a number previously given.  In other words, when you read to
the highest of the article numbers given by GROUP, you have read
everything that will ever be in that range.

>draft-ietf-nntpext-base-08.txt says:
>
>        No similar assumption [refers to lowmark which can never
>        decrease] can be made about the high water mark, as this can
>        decrease if an article is removed, and then increase again if
>        it is reinstated or if new articles arrive.

I could have sworn we deprecated reinstatement, but I guess I'm out of
that loop again.

>I think this mandates INN's behaviour...  I agree with your view,
>though -- has this been discussed on Usefor?

I don't know.  Haven't followed it in a long long time.
	- Brian