ietf-nntp New wording on article numbers

[Jeff Coffler]

In reviewing Clive's proposed wording changes concerning article
numbering:

First, this wording is good in that, at a specific point in time,
the last (high) article number might not be valid, and this is the
"correct" behavior (if an article came in, and then was expired, then
the server should be able to give the "high" article number even though
that "high" article number is no longer valid).

However, a question: For the NNTP server that I wrote, I save three
items of interest after a successful GROUP command: the group object
(internal, but useful for me), the low article number AT THE TIME OF
THE GROUP COMMAND, and the high article number AT THE TIME OF THE
GROUP COMMAND.  By saving this, 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)?

I reset the saved low/high numbers on each GROUP command.  Thus, if you
wanted to check if new articles came in, you could either do a GROUP
command or you could do a LIST command.  The GROUP command is more
efficient (much less network traffic in response).

Thoughts/comments?

	-- Jeff


----------
> From: Clive D.W. Feather <clive at demon.net>
> To: IETF NNTP mailing list <ietf-nntp at academ.com>
> Subject: ietf-nntp New wording on article numbers
> Date: Friday, December 27, 1996 12:32 PM
> 
> As promised. Comments welcome.
> 
> 
> Proposed wording for RFC 977bis concerning article numbering.
> =============================================================
> 
> New section:
> 
>     News is divided into named groups. Within each group exist articles.
>     Each article has three relevant properties:
>       - A Message-ID, which is unique over all articles in all groups; if
>         an article occurs in more than one group, it has the same
Message-ID
>         in all groups.
>       - An arrival timestamp, giving the time it arrived at the server.
>       - An article number, which is unique only within the group;
different
>         articles in different groups may have the same number, and an
>         article that occurs in more than one group may have different
>         numbers in each group.
> 
>     The server MUST ensure that article numbers are issued in order of
>     arrival timestamp; that is, later arriving articles MUST have higher
>     numbers than earlier arriving ones. The server SHOULD allocate the
first
>     unused number to each new article.
> 
>     Article numbers MUST lie between 1 and 999999999 inclusive [this
allows
>     one article per second for 31 years]. The client and server SHOULD
NOT
>     use leading zeroes in specifying article numbers. If the server loses
>     record of the most recent article number in a group, it MUST reset to
a
>     higher article number.
> 
> 
> 3.2.  The GROUP command
> 3.2.1.  GROUP
> 
> Replace the paragraph:
> 
>    The successful selection response will return the article numbers of
>    the first and last articles in the group, and an estimate of the
>    number of articles on file in the group.  It is not necessary that
>    the estimate be correct, although that is helpful; it must only be
>    equal to or larger than the actual number of articles on file.  (Some
>    implementations will actually count the number of articles on file.
>    Others will just subtract first article number from last to get an
>    estimate.)
> 
> by the following paragraphs:
> 
>     The successful selection response will return the article numbers of
the
>     first and last articles in the group at the moment of selection, and
an
>     estimate of the number of articles on file in the group. The estimate
>     MUST be at least the actual number of articles available. (Some
>     implementations will actually count the number of articles on file.
>     Others will just subtract first article number from last to get an
>     estimate.)
> 
>     The last article number MIGHT be less than the first article number.
In
>     this case, there are no articles in the group and the estimated count
>     MUST be zero.
> 
>     The set of articles in a group may change after the GROUP command is
>     carried out. That is:
>     * articles may be removed from the group;
>     * articles may be reinstated in the group with the same article
number,
>       but those articles MUST have numbers no less than the first article
>       number in the response;
>     * new articles may be added with article numbers greater than the
last
>       article number returned in the response.
> 
>     When a subsequent GROUP command for the same newsgroup is issued,
either
>     by the same client or a different client, the first and last article
>     numbers MUST be no less than those in the previous response for that
>     newsgroup.
> 
> 
> 3.1.2.  ARTICLE (selection by number)
> 
> Add the paragraph:
> 
>     A previously valid article number might not remain valid if the
article
>     has been removed. A previously invalid article number might become
valid
>     if the article has been reinstated, but such an article number MUST
be
>     no less than the "first" article number specified in the most recent
>     response to a GROUP command for that group.
> 
> 
> 3.5.  The LAST command
> 3.5.1.  LAST
> 
> Add the paragraphs:
> 
>     There might be no previous article in the group, even though the
current
>     article number is not the first one according to the last GROUP
command.
> 
>     Because articles can be removed and added, the results of multiple
LAST
>     and NEXT commands might not be consistent over time.
> 
> 
> 3.9.  The NEXT command
> 3.9.1.  NEXT
> 
> Add the paragraphs:
> 
>     There might be no subsequent article in the group, even though the
>     current article number is not the last one according to the last
GROUP
>     command. Similarly (and unlike the LAST command) there might be a
>     subsequent article in the group even though the article number *is*
the
>     last one; in this case, another GROUP command will return a higher
>     "last" value.
> 
>     Because articles can be removed and added, the results of multiple
LAST
>     and NEXT commands might not be consistent over time.
> 
> -- 
> Clive D.W. Feather    | Associate Director  | Director
> Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services
Ltd.
> Fax: +44 181 371 1150 | <clive at demon.net  | <cdwf at cityscape.co.uk>