ietf-nntp Articles without message IDs

Russ Allbery rra at stanford.edu
Mon Mar 31 13:59:03 PST 2003


Please, everyone, read through this and say something about your opinion.
We need to come to a decision on this, and I've had a hard time telling
what approach people would prefer to take based on the discussion so far.

The issue is that RFC 977 included some language concerning articles
without message IDs, saying that <0> should be used as the message ID in
those cases.  However, this was not well-integrated into the rest of the
standard (the effects on NEWNEWS weren't addressed, for example).  In
practice, every NNTP implementation that I'm aware of either requires that
an article already have a Message-ID header or adds one to the article
when it receives it, depending on how the article was received; I'm not
aware of any server that intentionally uses the <0> thing for articles
that got into the server database via any normal means.

The two alternatives as I see it are:

 1. Go with Clive's text, quoted below, which says that articles SHOULD
    have message IDs but reserves <0> for places where the protocol has
    to indicate a message ID for an article that doesn't have one.  State
    that <0> is not a valid message ID (which immediately takes care of
    making it invalid to offer such an article via IHAVE) and note that
    such articles are not returned by NEWNEWS.

 2. State that articles MUST have message IDs, but add a special exception
    to the text of POST saying that articles offered via POST need not
    have a message ID, but that in that case one will be added by the
    server.  Note at the beginning of the document this difference from
    RFC 977.

I believe that the application mentioned here earlier where articles were
accepted without message IDs assigned message IDs internally, so it would
comply with either of these proposals.  The main practical case where I
can see articles without message IDs arising is if someone is trying to
serve mail spools via NNTP without modifying the original messages at all,
since the message ID is optional in mail.  (Software that does this
currently that I'm aware of modifies the message to add a message ID.)

One disadvantage of keeping <0> is that it clearly doesn't have the
semantics of a real message ID (in particular, it's not unique).  In
retrospect, it probably would have been better to use <>, but too late
now.

Please take a moment to indicate your preference, and also if you find the
alternative completely unacceptable, please state why.

More information follows, including the proposed text if we want to retain
the <0> workaround.

Clive D.W. Feather <clive at demon.net> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> It comes about if you're serving out messages without a message ID, but
>> I don't really see any need for NNTP to allow for that possibility.

> Well, we've already got one person who's got a related situation.

Yeah, but he's doing something slightly different, namely assigning his
own message IDs.  That's fully conformant to a specification that doesn't
have the <0> business.  We may have to distinguish between articles
received and articles served out.

> And, as you pointed out to me, we can't assume that an NNTP server is
> only handling USEFOR-conformant articles. Can we safely assume that no
> such article will ever arrive?

No, but what we can decide is whether or not we're going to try to make
NNTP usable for articles that never have message IDs, or if we're going to
require that as soon as a server wants to serve out an article, it has to
ensure that that article gets assigned a unique message ID in one way or
another.

> Okay, fitting that into the text was easy:

>    Each article SHOULD have a message-id.  Two articles processed by
>    an NNTP server MUST NOT have the same message-id.  Note that RFC
>    1036 further requires that message-ids are globally unique for all
>    time.  Where an article does not have a message-id, the server MUST
>    use the placeholder "<0>" (without the double quotes) where it is
>    required to provide the message-id of that article.

>    For the purposes of this specification, message-ids are opaque
>    strings that MUST meet the following requirements:
> [...]
>    considered semantically identical according to the specification in
>    RFC 2822.

>    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 MAY synthesise a message-id
>    or MAY choose not to assign a message-id to that article (this will
>    restrict the ways in which this article can be accessed by the
>    client).

Maybe "the server MAY synthesise a message-id and add it to the article
headers following whatever article format specification is used for the
articles it is serving" instead, to clear things up for OVER and to make
behavior match existing practice.

> The issues are then as follows:
> * What text does POST need to say where the "same message-id" is?

I think we could just add text there saying "if the client assigned a
message ID to the post" or something along those lines.

> * NEWNEWS needs to say that articles without message-ids are omitted.

Yes.

> * Does OVER return the message-id or the contents of the Message-ID header?

The contents of the Message-ID header, I'd say.  If the server synthesises
a message-id, it should really add it to the article as well; if the
server is going to server out messages without message IDs, putting <0>
there would just be confusing.

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



More information about the ietf-nntp mailing list