ietf-nntp <0> and message IDs

[Matthias Andree]

"Clive D. W. Feather" <clive at on-the-train.demon.co.uk> writes:

>    * 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?  I'd tend to think of ASCII 0x20 (SP) and 0x7f
(DEL) as non-printable, but adding a reference or appendix might then be
unmistakable.

>    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).

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 with various Message-ID
headers that Usenet will never be able to get rid of, because cancelling
(which acts by Message-ID as well, which is non-constant in this case)
will essentially be impossible. This effectively voids the uniqueness
requirement of RFC-1036.

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.

There are two solutions: a) don't forward without Message-ID, b) modify
the article.

b) is the current state of many implementations that I know (for example
leafnode and INN's nnrpd do this).


So, my suggestion is:

- take reference to usefor drafts, make sure that the Message-ID is only
  synthesized on POSTing a "proto-article" (MUST when POSTing, and MUST
  NOT for IHAVE and other transport means)

> In POST:
>
>    The client SHOULD NOT assume that the article has been successfully
>    transferred unless it receives an affirmative response from the
>    server. If the session is interrupted before the response is
>    received, it is possible that an affirmative response was sent but
>    has been lost. Therefore, in any subsequent session, the client
>    SHOULD either check whether the article was successfully posted
>    before resending or, if the article contained a header with name
>    "Message-ID", ensure that the contents of this header are identical
>    when resending it - the latter approach is preferred since the
>    article might not have been made available for reading yet (for
>    example, it may have to go through a moderation process). The server
>    SHOULD ensure, in this case, that the re-sent article is recognised
>    as a duplicate and not assigned a different message-id to the
>    original.

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.

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, and SHOULD use the suggested Message-ID if it does not
generate the Message-ID itself (to help newsreaders).

-- 
Matthias Andree