headers
Sabahattin Gucukoglu | 12 Jun 2011 05:57

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 ÉLIE wrote:
>>> The low watermark can not decrease.
>> 
>> Even when the client disconnects?
> 
> Yes, the low water mark SHOULD NOT decrease.
> 
> Section 6.1.1.2:
> 
>   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.
> 
>>> 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?
(Continue reading)

Permalink | Reply |
headers
Julien ÉLIE | 12 Jun 2011 11:12
Favicon

Re: [NNTP] Article Reinstatement

Hi Sabahattin,

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

… and move the NNTP protocol to Draft Standard at the same time.

> But how do we
> distinguish, inside the server, an article that *might* be reinstated
> and one that just expired?

I think it is implementation-specific, and therefore not to be dealt 
with in an RFC.

>>> So what does a server do when the lowest-numbered article is
>>> pending reinstatement and the client requests it?
>>
>> The news server just answers the article does not exist:
>
> Is there any language which specifically allows the use of these
> codes for reporting an invalid article number because of a (possible)
> reinstatement?

The article does not exist.  The language is to respond 430/423/420.
(Please note that I wrote twice 423 in my previous mail; it was 423+420.)

Maybe you were asking for a new code telling that the article does not 
exist but may be reinstated?
It could be something to look at in RFC3977bis.  However, clients do not 
currently expect this possible new response code to existing commands
(Continue reading)

Permalink | Reply |
headers
Clive D.W. Feather | 12 Jun 2011 14:05

Re: [NNTP] Article Reinstatement

Sabahattin Gucukoglu said:
> I think we really need an effort to roll all these errata into 3977bis.

I'm not clear that there is an error here.

>>>> 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?

That's up to the implementer.

>>> So what does a server do when the lowest-numbered article is pending
>>> reinstatement and the client requests it?
>> The news server just answers the article does not exist:

Exactly.

> Is there any language which specifically allows the use of these codes for reporting an invalid article
number because of a (possible) reinstatement?

Until and unless the article is reinstated, it does not exist. Full stop.

Reinstatement is either:
(1) a rare event (e.g. because of an erroneous cancel)
(2) a side-effect of running a server farm that isn't perfectly in sync.

>> 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.
(Continue reading)

Permalink | Reply |

Gmane