ietf-nntp <0> and message IDs

[Clive D. W. Feather]

-----BEGIN PGP SIGNED MESSAGE-----

In message <ylof3l4nza.fsf at windlord.stanford.edu>, Russ Allbery
<rra at stanford.edu> writes
>I think we have consensus on eliminating the <0> wart and requiring that
>all articles have message IDs (possibly assigned by the server if the
>incoming message didn't have one).
>
>If anyone disagrees that that's the consensus, please speak up now.
>Otherwise, Clive, please go ahead and make those changes,

Okay, here's the main changes.

In the introduction:

   It changes the default character set to UTF-8 instead of US-ASCII.
   It now requires all articles to have a message-id, eliminating the
   "<0>" placeholder used in RFC 977. It also extends the newsgroup name
   matching capabilities already documented in RFC 977.

In article concepts:

   Each article MUST have a unique message-id; two articles offered 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.

   For the purposes of this specification, message-ids are opaque
   strings that MUST meet the following requirements:
   * A message-id MUST begin with "<" and end with ">", and MUST NOT
     contain the latter except at the end.
   * A message-id MUST be between 3 and 250 octets in length.
   * A message-id MUST NOT contain octets other than printable US-ASCII
     characters.
   Two message-ids are the same if and only if they consist of the same
   sequence of octets. Other specifications may define two different
   sequences as being equal; an NNTP server that also conforms to such a
   specification must consistently use only one or the other. As an
   example, the message-ids:

      <abcd at example.com>
      <"abcd"@example.com>
      <"ab\cd"@example.com>

   are considered distinct by this specification even though they would
   be 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 MUST synthesise a message-id (but need not
   modify the article to add such a header).

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.

- -- 
Clive D.W. Feather     |  Internet Expert  | Work: <clive at demon.net>
Tel: +44 20 8371 1138  |  Demon Internet   | Home: <clive at davros.org>
Fax: +44 870 051 9937  |  Thus plc         | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk 2.0.5

iQEVAwUBPo7ovCNAHP3TFZrhAQFcggf/eyOWKSWRqoCnf3pNea728ok1dxnApEWf
FB56YgDMlIuWIdWQXMHFmhw8F9mgV6ulgsK1Nv8TDF0yjNzBFSy+8yyxKUMYXCu0
y8JG7CfMyRNd0uGlmY5P99BKXv2bvYU17W6FCaBSUlrJJ3adSRRoUew6DSh1jiiX
g+9Ix1v5pWFHmDxEw1PhtNqPKVJ+KGuALXDRBSquBMF4M+CpAL/G1a14AarXIB0f
noBuEsgvlvRg/pzX+RiLzj9YLS9tDJJ6dkEAol+iUnaAjLX8Ek2JJsSce7hGYGtM
3D8yOZ0KK0vDXwll4RU8fqGXiPU1NYahk3q12wnU6uzJAilS8ueLJg==
=Og1j
-----END PGP SIGNATURE-----