K 10
svn:author
V 6
kondou
K 8
svn:date
V 27
1998-11-04T08:43:49.000000Z
K 7
svn:log
V 1316
nnrpd/commands.c:
nnrpd/post.c:
	- posted on news.software.nntp by olaf@bigred.inka.de (Olaf Titz)
	- I don't know if this has been proposed before, but it just has come
	  up in a discussion about the cancel-lock feature:

	  Often a client needs to know the Message-IDs of its own postings, for
	  bookkeeping purposes or to generate a Cancel-Lock header. This means
	  it has to generate its own IDs, which can lead to bogus domains and
	  ambiguity problems. Or does it have to generate the IDs itself? A
	  simple, backwards compatible NNTP protocol extension helps out:

	  When the server sees a POST command, it generates the Message-ID it
	  wants to use for the posting and returns this Message-ID in the 340
	  response. This Message-ID constitutes only a recommendation; the
	  client can use this ID, it can generate its own, or it can post
	  without Message-ID in which case the server will use exactly this
	  Message-ID for the posting.

	  The client identifies that the 340 response contains in fact a
	  Message-ID by the usual syntax /\<[^@>\s]+@[^@>\s]+\>/. If this
	  pattern is not contained in the response, it proceeds as usual with
	  generating its own ID.

	  This way, the client knows the Message-ID before sending the article
	  to the server and the server generates known good IDs.

END
