ietf-nntp Article concepts

[Juergen Helbing]

On Sat, 22 Mar 2003 08:38:00 +0000, you wrote:

>If an
>   article does not contain this header line, the server MUST NOT
>   allocate a message-id, and MUST use the placeholder "<0>" (without
>   the double quotes) where it is required to provide the message-id of
>   that article.

Beg your pardon for making perhaps unqualified comments.
But this section is invalidating a part of my own server soft - so I'd
like to know at least why I _must_ remove this feature from my sw:


If I'm receiving an article (any source, also Mail->News gateway...)
without a valid MsgId (or without any MsgId or with a corrupt
msgid-line) then I am assigning a new MsgId from my own pool. (I am
not adding this message to outgoing spools).

I need to have proper - and unique - MsgIds because my entire
conception (also my reader conception) is based ONLY on the msgid and
article numbers are only used for OVERviews....
So having not a valid MsgId but '<0>' for all those articles would be
identical to throwing them away (what I dont want). Because I could
never retrieve the message again (I dont support download by article
number. It also uses the msgid internally. So this one MUST be correct
- and unique).


I am having such articles sometimes in my database when I receive
corrupt articles - almost without any headers, but also with corrupted
headers: Defective database/spool at the sending side.
With a "multi-host-downloader" integrated I can usually fetch a good
copy from another server, but not always. 
So I want to keep the corrupt msg at least for debugging....


Is there a serious reason why a news-server _MUST_NOT_ (as you
specify) an own msg-id ?
I believe that the most serious concern would be that duplicates are
floating around on Usenet whenever an article is forwarded without (or
with a corrupt) msgid. 
But is is really necessary to forbid that a news-server handles such
articles internally - as long as it does not add such article to
outgoing feeds ?

The MsgId is _critical_ for the flooding concept - and a proper
"failure behaviour" should be specified if the line is lost during
transmission - or damaged on harddisks or anywhere else (even if this
happens not very often).

I believe that assigning <0> is not a good choice.
Perhaps using something as  <ownmsg @ invalid-dont-forward> might be
more appropriate.


Sorry if I'm writing too much nonsense. 
I am surely a "very special case"  ;-)

-- 
Juergen
-------
MyNews for Windows: www.winews.net