ietf-nntp BCP for RFC977 server/RFC1036 interaction

[Brian Kantor]

IHAVE was *NOT* intended for the submission of new articles, and
I strongly believe it to be a misuse of the protocol to do so.

IHAVE was solely intended for peer-to-peer article exchange.

I treat any attempt to offer me articles with IHAVE without prearrangement
as a news peer to be someone attempting to forge articles.

POST was intended for the submission of new articles.  You *can*
use it in a batched mode, and I think that clients (non-peers)
should use it in all cases to enter new articles into the news system.

I believe that this is common practice;  once again I remind people
that RFC977 was written BEFORE the protocol and practices of NNTP were
actually implemented - and was made an internet standard over the
protests of its author.  Do *NOT* take it literally.

	---

NNTP-Posting-Host was intended to be viewed by humans, not to be machine
parsed.  I put it in there to aid in tracing forged article submissions.
I like the idea that both hostname and IP address be placed in the
header, but consider this:

In the IP/TCP world, we will always have an IP address of the posting host.
If dynamic, it's not very meaningful without other info, such a logs,
but it's better than nothing.  Here at UCSD we use static addresses,
which are recycled when the person leaves the university.  Thus the
hostname has meaning for a good long time (several years) but can
eventually change.  

How about
  NNTP-Posting-Host: Ip.Addr.of.host [<[username@]hostname]>] [(other info)]

which would yield such productions as
	123.45.67.89
	123.45.67.89 <wombat.ucsd.edu>
	10.45.67.89 <rick at seismo.uu.net>
	44.0.0.1 (Bob_Jones dialup IP)

which is short, can accomodate a username, and can be parsed both by
humans and machines, and doesn't violate the spirit of most of the
other kinds of headers.  And it's backward compatable.

And if the transport isn't IP, well, stick whatever info you can in there.
e.g.,	NNTP-Posting-Host: WB6CYT at WB6KDT (AX.25)
or	NNTP-Posting-Host: ihnp4!gary

Semantics are: For articles submitted by POST command, you delete any
submitted NNTP-Posting-Host line that is in the submission, and generate
one from whatever info your server has that it trusts.  An article that
is received via an IHAVE comes from a peer; you don't fiddle with the
NNTP-Posting-Host line at all - even if it doesn't have one.

[Note: the 'if not already correct' as previously suggested begs the
whole point of having the header line: the server accepting the article
has to check the whole darn thing anyway, which is harder than just
generating it itself, since on a POST command you MUST NOT trust the
nntp-p-h header the client may be submitting - he shouldn't BE
submitting one, and if he is, he's violating the intended protocol
of that header line probably with an eye towards forging it.]

	- Brian