Re: ietf-nntp New wording on article numbers

[USENET news manager <[e-mail]>]

Chris Hall wrote:
>
>In article <[e-mail]>et>, "Clive D.W. Feather"
><[e-mail]> writes
>>Jeff Coffler said:
>>> I can guarentee consistent behavior
>>> for commands like LAST, NEXT, and ARTICLE commands (if the "current"
>>> article number would go out of range of my saved values, then I will
>>> give an appropriate response code).
>>> 
>>> Now, we can't require this (since it wasn't in the original spec, and
>>> since many servers today don't enforce this), but: shouldn't we recommend
>>> this behavior (so that, at least if recommendations are followed, NNTP
>>> behavior is nice and consistent across commands)?
>
>>For my next draft, I've added wording to NEXT saying:
>>
>>    A server MIGHT, but SHOULD NOT return an article number greater than
>>    the "last" value from the most recent GROUP command for this client.
>>
>>How does this look to people ?
>
>And similar words for LAST, I assume, to cope with the case of an
>article being reinstated !

That all sounds reasonable, but the reference to "consistent behaviour" is
misleading - consistent in the sense that LAST/NEXT wouldn't exceed the
range returned by GROUP, but I don't see that as very useful when (for
example) five NEXT commands and then five LAST commands may see very
different sets of articles due to cancellation or expiry. To a client,
seeing a consistent set of articles when moving to and fro (which is
unrealistic) would be far more useful!

>If LAST and NEXT are allowed to wander outside the range "first".."last"
>returned by GROUP, then the "arts" figure returned by GROUP could be
>exceeded -- which is a bit chewy.  Mind you, I don't see much use for
>the "arts" figure.

I may be wrong, but it seems unlikely (to me) that clients which (for 
example) allocate arrays sized according to the article number estimate 
would then use LAST/NEXT to find articles rather than XOVER and ARTICLE, 
etc. Indeed, with the trend to threaded newsreaders I can't see many uses
for LAST/NEXT (for online reading, maybe useful for "suck feed" 
implementation).

>For clients that remember the state of newsgroups, it's the value of
>"last" that matters, so that each time the client looks at a newsgroup
>it doesn't need to worry about stuff from the previous highest article
>number back.  The client can do that using the previous "last" figure,
>so the suggested recommendation is helpful.  However, since this cannot
>be depended on, the client is wiser to note the article number returned
>by the last ARTICLE, BODY or HEAD command.

If the client is using NEXT, then the highest article number actually seen
is the appropriate one to record - no assumptions can be made about higher
numbered articles, and it might be higher than GROUP returned. If the client
is using XOVER and ARTICLE (with article number), etc., then the highest
article seen (for example) in the XOVER data is the relevant one. In either
case, of course, the client is likely to record rather more information,
typically which articles have been read, and articles before the high
article seen in an earlier session may well still be relevant if they are
not yet marked as read. A client using NEXT could always ignore an article
received with a higher article number than expected, and stop NEXTing. 

Mmm... in spite of saying, above, that the recommendation seems reasonable,
I'm now starting to wonder about that. If it's only a recommendation,
clients still have to cope with servers NEXTing to articles beyond those
mentioned by GROUP. It can't be mandatory since it conflicts with existing
implementations. Therefore - are there any situations where there would be
any significant benefits from limiting the LAST/NEXT range to match the
range from GROUP (given that it's trivial for the client to behave as though
the server had done it)?

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)