[NNTP] Article Reinstatement

[Sabahattin Gucukoglu]

On 13 May 2011, at 18:06, Julien ÉLIE wrote:
>> If a client should not be aware that an article has been removed
>> pending reinstatement, it has no reason to suspect that the low
>> watermark will ever decrease.
> 
> The low watermark can not decrease.

Even when the client disconnects?

> Example: news.test has 5 messages, min=1 max=5.  Article 1 is
>> removed.  Server indicates on group entry to news.test, min=2 max=5
>> no=4.  The client updates its counters to indicate that article 5 was
>> the last article seen.  Article 1 is replaced.  Client connects,
>> server indicates min=1 max=5 no=5.  How is the client to ensure the
>> retrieval of article 1?
> 
> It is not an RFC-compliant behaviour.
> min could not have been set to 2.

So what does a server do when the lowest-numbered article is pending reinstatement and the client requests it?

> RFC 3977, Section 6.1.1.2:
> 
>   o  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).

This does make sense, but doesn't apply to the high watermark.

> [...]
>   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.

Looking back at my original message, I see that I made an assumption that the high and low watermarks were always valid articles, but I can see now that the RFC has us covered in the special case of reinstatement.  Good. :-)

> The low watermark may certainly indicate its
>> presence, but it can hardly assume that an article was reinstated
>> simply because on this occasion min=1 is the smallest value seen; the
>> article numbered 1 may already have been fetched under normal
>> conditions, or the heuristic will not work at all if group expiration
>> on criteria other than number of articles has occurred, for
>> instance.
>> 
>> Does anybody have any ideas?
> 
> I do not understand your point.
> 
> Wouldn't it rather be:
> 
> news.test has 5 messages, min=1 max=5 count=5
> 1. remove #1
> min=1 max=5 count=4
> 2. reinstate #1 and remove #3
> min=1 max=5 count=4

By which we understand that an invalid article response will result from requesting a removed article, yes?

> So a client that comes between action 1 and action 2 will never see #1; it won't ask for #1 afterwards because the high water mark is 5.  The same way as a client coming after action 2 will never see #3.
> But is it really a problem?

Taking into account the use of article reinstatement, probably not in many cases, but you can imagine that if you are a news puller or offline reader, you want to go forward in the article stream and not worry about what came before.  Any circumstance that results in article deletion should be permanent, from the client's perspective.  But yes, it's just me, picking nits. :-)

Cheers,
Sabahattin