ietf-nntp <0> and message IDs

[Clive D.W. Feather]

Matthias Andree said:
>>    * A message-id MUST NOT contain octets other than printable US-ASCII
>>      characters.
> To refine this: Is there any consensus on "printable" characters? A
> normative reference?

There isn't a consensus, but I define the term earlier in the document.

>>    This specification does not describe how the message-id of an article
>>    is determined. Many servers will extract the message-id from the
>>    contents of a header with name "Message-ID", but this is not required
>>    by this document. In particular, if the article does not contain such
>>    a header, the server MUST synthesise a message-id (but need not
>>    modify the article to add such a header).

That last sentence is wrong, now I think of it:

   If the server does not have any way to determine a message-id from
   the article itself, it MUST synthesise one (it need not modify the
   article to add such a header unless required to by another
   specification).

is better.

> I find this contradictory and unhelpful. If the server must synthesize a
> message-ID, IMO it must also record the message-id in the article --
> otherwise, forwarding an article without Message-ID header to a
> different host _may_ generate a flood duplicates

Not our problem. NNTP is only concerned with local publication of articles
and not their further distribution.

> This effectively voids the uniqueness
> requirement of RFC-1036.

No, because a Usenet NNTP server still has to conform to 1036 and its
requirements as well.

> I can understand you don't want to mix the article representation and
> the NNT protocol, but some relations simply cannot be relaxed without
> danger.

However, with Russ's agreement, I could add a sub-section on the
relationship between this document and Usefor, which would spell out how
our requirements would be met in that context.

>> In POST:
[...]
> One might just omit the first alternative and just require that the same
> Message-ID "MUST" be used when re-POST-ing the article. If there's a
> clear preference, then why offer the inferior alternative.

Because there might be reasons to not provide a message-id at all. The
article format being transferred might not use the Message-ID header.

> Note also that INN for example suggests a message ID in the 340 response
> to the POST command:
> 
> 340 Ok, recommended ID <b6rttc$jm3$1 at hermes.example.org>
> 
> The protocol might suggest that a client MAY use the suggested
> Message-ID,

If that response were meant to be meaningful, it would not conform to our
standard.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | *** NOTE CHANGE ***
Demon Internet      | WWW: http://www.davros.org | Fax:    +44 870 051 9937
Thus plc            |                            | Mobile: +44 7973 377646