Re: [NNTP] Article Reinstatement

On 13 May 2011, at 18:06, Julien =C9LIE 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.
>=20
> The low watermark can not decrease.

Even when the client disconnects?

> Example: news.test has 5 messages, min=3D1 max=3D5.  Article 1 is
>> removed.  Server indicates on group entry to news.test, min=3D2 max=3D5=

>> no=3D4.  The client updates its counters to indicate that article 5 =
was
>> the last article seen.  Article 1 is replaced.  Client connects,
>> server indicates min=3D1 max=3D5 no=3D5.  How is the client to ensure =
the
>> retrieval of article 1?
>=20
> 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:
>=20
>   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=3D1 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.
>>=20
>> Does anybody have any ideas?
>=20
> I do not understand your point.
>=20
> Wouldn't it rather be:
>=20
> news.test has 5 messages, min=3D1 max=3D5 count=3D5
> 1. remove #1
> min=3D1 max=3D5 count=3D4
> 2. reinstate #1 and remove #3
> min=3D1 max=3D5 count=3D4

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