ietf-nntp <0> and message IDs

[Russ Allbery]

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

>    For the purposes of this specification, message-ids are opaque
>    strings that MUST meet the following requirements:

As Andrew mentioned, also rule out spaces (and tabs).

>    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 would add "unless required to by the relevant article format standard"
to the parenthetical, just to open the door for USEFOR to specify that
behavior in the duties of an injecting agent.

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

I don't have strong objections to this, but it might be worthwhile to try
to make it mildly more generic.  I'm not sure.  Instead of naming a
particular header, one could instead say something like:

    Therefore, in any subsequent session, the client SHOULD either check
    whether the article was successfully posted before resending or, if
    the client supplied a message ID with the original post, ensure that
    the same message ID is used when resending the post.  The latter
    approach is preferred since the article might not have been made
    available for reading yet...

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>