[NNTP] Article Numbers Becoming Invalid (RFC 3977)

Sabahattin Gucukoglu mail at sabahattin-gucukoglu.com
Sat Dec 26 19:25:51 PST 2009


On 26 Dec 2009, at 22:25, Julien ÉLIE wrote:
>> RFC 977 makes no special mention of article numbers being no longer valid,
>> but assigns a code 430 for "Article not found".  RFC 3977 does away with
>> that code, but then describes the possibility of articles being removed.
>> It doesn't say why or how.
> 
> RFC 3977 still uses the 430 error code.
> 
> Both RFCs 977+2980 and 3977 have:
> 
>  Response code 423
>     Generated by: ARTICLE, BODY, (X)HDR, HEAD, (X)OVER, STAT
>     Meaning: no article with that number or in that range.
> 
>  Response code 430
>     Generated by: ARTICLE, BODY, (X)HDR, HEAD, (X)OVER, STAT
>     Meaning: no article with that message-id.

OK, I see the problem here: RFC 977 defined both codes for use with the article <number> syntax, while RFC 3977 didn't.  So we ignore RFC 977, and all is right with the world again. :-)

The problem was that maybe the RFC 977 use of code 430 meant something, say, "That article number is in range but its data can't be found on disk" or some such.  But I see now that codes 423 and 430 mean the same thing, for number and Message-ID respectively.  Probably should be noted somewhere though - I am seeing a Tornado use 430 exclusively (I have no access to an inn install).  Suck, a program with similar uses but for feeding a local spool, gets around this entirely by just using xhdr.
> 
>> Shall I just ignore errors about invalid article numbers,
> 
> Yes.
> 
Fair enough.  It's easier this way anyway.  It means I spend most of my time reading article data instead of trying to find them, or receiving very long lists of headers or article numbers each time I get run from cron.

I still have a concern though: RFC 2980 clears up the detail of article numbering, monotonically increasing.  So how does a news server work efficiently if the last article number just added is instantly removed?  Now, the group's high watermark is lowered again, and a new article will replace the recently removed article, thus destroying the server-only-uniqueness of article numbers (and therefore any use of the numbers as place markers in the news stream).  And even if that isn't the case, the server will have to note a next article number that is greater than the high watermark it reports, in order that it not reuse the recently removed article's number.  How does it do that, if at all?  If it doesn't reset the high watermark, it's a liability to clients taking the maximum number as gospel, since they will fail to receive the article with the highest article number.  How clear is all of this?
> 
> If you receive 500 to LISTGROUP, then try GROUP, and if 12 is your
> last article number in your rc file, try to collect 13, 14, 15, etc.
> until you have a valid article number.  Then use NEXT until you
> receive 421.

This seems like the next obvious thing to try, thanks.  Right now it just blindly tries every article number from min to max, which works 99% of the time, of course.  Perhaps these removals are the results of spam filtering?  This is the Tornado server provided by my ISP, but haven't checked the reliability of other servers yet.

Cheers,
Sabahattin



More information about the ietf-nntp mailing list