Re: [NNTP] Article Reinstatement

I think we really need an effort to roll all these errata into 3977bis.

On 14 May 2011, at 20:37, Julien =C9LIE wrote:
>>> The low watermark can not decrease.
>>=20
>> Even when the client disconnects?
>=20
> Yes, the low water mark SHOULD NOT decrease.
>=20
> Section 6.1.1.2:
>=20
>   Except when the group is empty and all three numbers are zero,
>   whenever a subsequent GROUP command for the same newsgroup 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 newsgroup in this session, and it SHOULD be no =
less
>   than that in any previous response for that newsgroup ever sent to
>   any client.  Any failure to meet the latter condition SHOULD be
>   transient only.  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.
>=20
>>> It is not an RFC-compliant behaviour. min could not have been set
>>> to 2.

Yes, (as Clive correctly points out) very sensible.  But how do we =
distinguish, inside the server, an article that *might* be reinstated =
and one that just expired?

>> So what does a server do when the lowest-numbered article is pending
>> reinstatement and the client requests it?
>=20
> The news server just answers the article does not exist:
>=20
>   First form (message-id specified)
>     430                   No article with that message-id
>=20
>   Second form (article number specified)
>     423                   No article with that number
>=20
>   Third form (current article number used)
>     423                   No article with that number
>=20
> Note that reinstatement can be done on other articles than the =
lowest-numbered article.

Is there any language which specifically allows the use of these codes =
for reporting an invalid article number because of a (possible) =
reinstatement?  =46rom here it looks like just an implementation detail. =
 I'd otherwise assume that the server simply pretends the article isn't =
valid even though it might be, in the future.  There is a semantic =
difference that the server hides.

>> 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. :-)
>=20
> And also the fact that articles can expire and no longer be present in =
the news spool.  The low water mark does not necessarily point to a =
still retrievable article at the time an ARTICLE command is sent.

That's fine; such an article really would be no longer existent.

> 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
>>=20
>> By which we understand that an invalid article response will result
>> from requesting a removed article, yes?
>=20
> Not "invalid", but "inexistent".

Yes, OK, this needs to be rolled into bis.

> 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?
>>=20
>> 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. :-)
>=20
> It is up to the client to decide how to implement its retrieval of =
articles.  If it assumes the article stream always go forward (which =
happens nearly all the time), then it will miss reinstatements.  That's =
all.  The client just prefers rapidity to exhaustivity (sending a =
LISTGROUP every time, or every n times, it connects to a news group).

Yes, indeed.  This seems to be how I've come away with this.  I used to =
do such exhaustive checks, but noting that reinstated articles were =
removed and then the same numbers used on the reinstatements, I decided =
that the client would benefit from the speed, if we assume the reader is =
acting on behalf of the user at the time the articles are retrieved, =
rather than read (for caching).  This doesn't always work, but it does =
work 99% of the time.  Especially since many servers just don't do the =
reinstatement thing at all.

Cheers,
Sabahattin