ietf-nntp New wording on article numbers - draft 3
Clive D.W. Feather
clive at demon.net
Fri Jan 10 00:50:50 PST 1997
Draft 3, after further discussions. This topic seems to have about wound
down, so can I ask the project editor to just take this and merge it in ?
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.
This timestamp is not directly exposed to the client, but can be
derived using the NEWNEWS command.
- 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 4 294 967 295 inclusive. The
client and server SHOULD NOT use leading zeroes in specifying article
numbers, and MUST NOT use more than 16 digits. In some situations the
value zero replaces an article number to show some special situation.
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
(these numbers are referred to as the "reported low water mark" and
the "reported high water mark"), and an estimate of the number of
articles on file in the group.
If the group is not empty, the estimate MUST be at least the
actual number of articles available, and MUST be no greater than one
more than the difference between the reported low and high water
marks. (Some implementations will actually count the number of
articles on file. Others will just subtract the low water mark from
the high water mark and add one to get an estimate.)
If the group is empty, one of the following three situations will
occur. Clients MUST accept all three cases; servers MUST NOT represent
an empty group in any other way.
(1) The high water mark will be one less than the low water mark,
and the estimated article count will be zero. Servers SHOULD use this
method to show an empty group. This is the only time that the high
water mark can be less than the low water mark.
(2) All three numbers will be zero.
(3) The high water mark is greater than or equal to the low water
mark; the estimated article count might be zero or non-zero; if non-
zero, the same requirements apply as for a non-empty group.
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
reported low water mark (note that this is a reinstatement of the
previous article, not a new article reusing the number);
* new articles may be added with article numbers greater than the
reported high water mark (if an article that was the one with the
highest number has been removed, the next new article will not have
the number one greater than the reported high water mark).
Except when the group is empty and all three numbers are zero,
whenever a subsequent GROUP command for the same newsgroup is issued,
either by the same client or a different client, the reported low
water mark in the response MUST be no less than that in any previous
response for that newsgroup sent to any client. The client may make
use of the low water mark to remove all remembered information about
articles with lower numbers, as these will never recur. This includes
the situation when the high water mark is one less than the low water
mark.
No similar assumption 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.
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 reported low water mark 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 reported low water mark. There MUST
NOT be a previous article when the current article number is the
reported low water mark.
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 reported high water mark. 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 high water mark. A
server MIGHT, but SHOULD NOT return an article number greater than
the reported high water mark.
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>
More information about the ietf-nntp
mailing list