ietf-nntp Section 9.1* - low article number, and article ordering

[David Riley]

Section 9.1 states:
            The server MUST ensure that article numbers are issued in
            order of arrival timestamp; that is, articles arriving later
            MUST have higher numbers than those that arrive earlier. The
            server SHOULD allocate the next sequential unused number to
            each new article.


Section 9.1.1.1 states:
          . 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)
and
            Except when the group is empty and all three numbers are zero,
            whenever a subsequent GROUP command for the same news group 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 news group 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.

Section 9.1.1.2 states:
            There MAY be no previous article in the group, although 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.

I think we should consider loosening some of these restrictions.  In large
installations, news services are typically spread across multiple machines.
In order to do this, articles must be centrally numbered and then
distributed to the leaf nodes (which might involve multiple hops).  Using
standard Usenet distribution techniques (multiple paths possible due to a
mesh network, multiple streams, etc.), articles might arrive slightly out
of order at the final reader site.  Furthermore, configurations involving
chaining, caching, or distributed data stores, might have different
articles available at any given time due to intermittent failures.

Because of these issues, I believe that the low article number might be
able to change, and go lower.  Furthermore, commands like LAST might
actually be able to retrieve an article that is lower than the previously
reported low number.

We should consider loosening these restrictions from MUSTs to SHOULDs, and
comment on the fact that in distributed configurations, out of order
article reception, and intermittent failure of "master" servers, might
result in article numbers lower than the reported low article number
becoming available.

-- 
David Riley
David.Riley at software.com - Software.com, Inc. (Vancouver, B.C.)