I-D ACTION:draft-ietf-nntpext-base-06.txt

[Charles Lindsey]

In <Pine.GSO.3.96.981106133641.11277B-100000 at w0> Thomas Gschwind <tom at infosys.tuwien.ac.at> writes:

>On Fri, 6 Nov 1998, Charles Lindsey wrote:

>> In 9.1, "the server SHOULD allocate the next sequential number" and in
>> 9.1.1.1 "reinstatement of the previous article, not a new article reusing
>> the number". ...

>It might cause problems to existing implementations:
>* It keeps the low watermark down. This might be a problem for
>  newsreaders that use an array to maintain read articles or overview
>  records.

Maybe, but it is a poor implementation technique. Is it commonly used? I
asked for examples on the other list, but none was forthcoming.

All I am really asking for is for this to be one _legitimate_
implementation. Better methods will doubtless come along, but the point is
that implementing it in servers will enable to feature to work immediately
in all existing newsreaders. Any other implementation requires a
simultaneous upgrade of both server and newsreader.

>* The estimation of the number of unread articles would be highly in
>  error.

One hopes that most servers will give a better estimate, though that one
is indeed legal in the present draft.

>And it raises other problems:
>* How could the news server implement a wrap around of the watermarks
>  then? Are the low/high watermarks increasing indefinitely?

I didn't think wrap-arounds were ever meant to happen. That is why the
potential range of article numbers has been made so huge. Anyone know the
highest number actually used in any server they know of?

>* What happens when an article has already been removed on my news
>  server and the low watermark has been increased accordingly?

If the replaced (or superseded) article is no longer there, then it looks
like a brand new article and is treated as such.

>* It would allow people to miss the article.
>  - The original article was expired and thus marked as read by my news
>    reader.
>  - Now the article is reinstated with the old number.
>  - How can my news reader identify this.

It doesn't. That is the whole intention. The primary customers for this
treatment are FAQs that are posted every month, but are actually the same
as the previous version (you use Supersedes whenever the FAQ changes
enough that people should see it again).

>* There are two cache servers for News available: nntpcache and 
>  NewsCache. Both assume that an article does not change over time.  
>  What should they do? 

I was not aware of these. Details?

>As far as I understood, the primary intent is that an article I have
>read already should not reappear as unread.  Wouldn't it be easier to
>require the reading agent to check whether the superseded article has
>already been read? This could be easily implemented by using the Xref
>header of the superseded article! 

That sounds like the method Clive just proposed.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email:     chl at clw.cs.man.ac.uk  Web:   http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9     Fingerprint: 73 6D C2 51 93 A0 01 E7  65 E8 64 7E 14 A4 AB A5