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

[Thomas Gschwind]

On Sun, 8 Nov 1998, Charles Lindsey wrote:

Shouldn't this discussion also/mostly belong to usenet-format at clari.net? 
However, I do not not like to move discussions between mailing lists or
send a mail to different lists.

> >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.
I don't know. I have just looked into the tin source code. tin would
not be affected. NewsCache would be affected (This is not a big issue
since it is not yet in widespread use and I would fix it if necessary).

If we want to implement it this way, we should _really_ check several
news readers!

> 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.
This is indeed an advantage. However, I think it raises more problems
than it solves. Another problem pointed out by Clive
<clive at on-the-train.demon.co.uk>:
Clive> To continue your example, what if there's already been a reply
Clive> pointing out your trivial mistake. Now you overwrite the article
Clive> and people start flaming the replier for forging the error !

> >* 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.
Unfortunately, the active database lists the low and high watermarks
only. Thus, the news reader would have to issue the group command for
each newsgroup (as implemented by Netscape). However, other news readers
(eg. tin) use only the active database.

> >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?
Clive pointed out that it was never sorted out how to implement wrap
around and that the consensus was that 9digit numbers would be enough
(Highest number on news.tuwien.ac.at 81381654). So this is not so
important.  

If I were to implement wrap around, I would specify to subtract 
1.5*10^9 from every article number as soon as all the article numbers
are above 1.5*10^9. The news reader could identify a wrap around based
on the fact that the high watermark is lower than the last article read. 
Thus articles are equal modulo 1.5*10^9. 

> 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).
I think that we are speaking about two different kinds of replaces?
* In one case the old article is replaced to fix a typo (or similar) and
  the old expiry time should apply.
* In the other case, we want to replace a FAQ and the expiry time of the
  new article should apply.
However, in either case I feel not very happy about having different
articles under the same article id/per group article number.

> >* 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?
nntpcache can be found at http://www.nntpcache.org/
NewsCache can be found at http://www.infosys.tuwien.ac.at/NewsCache/.
The current version of NewsCache is 0.99.12 and was writte by me (I hope
to release 1.0 within this year). If you have any questions regarding
NewsCache, contact me. 

As long as the replacement is mainly for typos and it is not a hard
requirement to distribute the new article instead of the old one, it
does not matter. However, if this is to be used for something like a
regularly posted FAQ, it gets hairy. How can a news reader (Both caches
act like a news readers) get aware of the replacement? 

> >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.
Yes, our solutions seem to be similar.

Thomas
--
Thomas Gschwind                      Email: tom at infosys.tuwien.ac.at
Distributed Systems Group            Tel: +43(1)58801x18412
A-1040, Argentinierstrasse 8         Fax: +43(1)5058453