ietf-nntp New wording on article numbers

[Chris Hall]

In article <199612291952.TAA20939 at lyra.csx.cam.ac.uk>, USENET news
manager <newsmaster at ucs.cam.ac.uk> writes
>Chris Hall wrote:
>>
>>In article <851804656.27539.0 at office.demon.net>, "Clive D.W. Feather"
>><clive at demon.net> 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!

Yes !  And yes, only a mug would depend on LAST and NEXT being
commutative !

>>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).

Even then LAST/NEXT are only really useful if the article number range
is sparsely populated.  Slurping articles or headers by NEXT requires
one NEXT and one ARTICLE/HEAD command per article.  Simply working up
the article numbers in ARTICLE/HEAD commands requires one command per
article fetched, and one for each unused article number.

>>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. 

Agreed....

>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.

....and yes, since the client cannot depend on the server not to step
NEXT beyond "last" (or LAST beyond "first"), then the client has to cope
whatever the RFC says.

> 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)?

I understand that the objective is to tidy up the wording to reflect
reality, rather than tighten up the design.  In that spirit one could
include two recommendations:

  1. for servers: to ensure that the behaviour of LAST/NEXT is
     consistent with all three of "arts", "first" and "last", it is
     recommended that the responses to LAST and NEXT honour the "first"
     and "last" returned by the response to the corresponding GROUP.

     Mind you, if the "arts" figure was the number of articles actually
     present in the range at the time of the GROUP command, then it can
     be invalidated by an article being reinstated !  My understanding
     is that the "arts" value should not be less than the number of
     articles the client may fetch.  In which case the "arts" value
     returned MUST be the maximum number of articles possible in the
     "first".."last" range (which I imagine will in general be last-
     first+1).  The only use for "arts" that I can see is where the
     server knows that the "first".."last" range is sparse, and bound to
     remain so.

  2. for clients: because the behaviour of LAST/NEXT may go beyond
     "first" and "last", it is recommended that the client be prepared
     to either ignore or otherwise deal with articles outside that
     range, and if not ignoring articles outside the range, be ready to
     deal with more articles than declared in "arts".

These are clearly pointing in opposite directions.  Consistent, however,
with the mantra (all together, now) "Be liberal in what you accept, and
conservative in what you send."

>                                John Line
-- 
Chris Hall                                       Chris.Hall at turnpike.com