ietf-nntp Clients should be able to set the Path

[Chris Lewis]

In message "Re: ietf-nntp Clients should be able to set the Path", 
'ccaputo at alt.net' writes:

>Usenet != NNTP

>Debates about how Usenet should be run are generally non-technical but
>involve policies that are technical.  Things like this should be
>encompassed in a document describing the policies of Usenet.  This
>document could make recommendations about things like whether POSTs can
>have Path: lines or whether messages should have NNTP-Posting-Host:.  This
>document would be the subject of mass debate and I'd further suggest that
>such a document wouldn't even be in the realm of the IETF because it has
>more to do with operations than engineering.  It could be a BCP, but it
>would be difficult to get consensus. 

If you haven't been following the thread, this whole discussion arises
out of a proposed BCP separate from RFC977bis (as per the consensus in
the BOF at the IETF that Stan mentioned, and should appear in the official
BOF report) that documents the technical considerations of a
convention on how NNTP servers can interact with RFC1036 message
headers.  Saying our discussions on "Path:"  or "NNTP-Posting-Host" etc
are non-technical and outside of the scope of the IETF, is tantamount to
saying that "Message-Id" is also outside the scope of the IETF, because
an alternative to Usenet need not be based on Message-Id, and the domain
name part is purely an operational issue rather than a standards one.

As I said in the very beginning, this is likely to be superseded by
a followon RFC1036 replacement, but as it's by no means certain that
that will ever happen, a BCP provides us with insurance that these
issues are documented, describing/clarifying current practise with
minimal extension.

As for difficulty of gaining consensus on the BCP, I think most would agree
it's almost there already, that only Path: stripping garners any serious
controversy, and that we're likely to be able to come up with a compromise
for Path amongst the various suggestions.  I personally would like to
see at least some sort of stripping, but if no consensus is reached on the
subject, I have no big trouble with dropping the issue entirely and
continuing with the remainder.

>NNTP will be used widely in Intranets that have their own set of policies. 
>I don't think we should preclude the ability for alternatives to Usenet to
>be based on NNTP.
>
>RFC977bis should strive to contain as little as possible about the actual
>headers of messages.  They are more of an application detail than a
>transport detail.

Yet, we must remember that NNTP servers do need to know some of the headers,
and some of the issues we're discussing here are only implementable with
information from the NNTP server.

H'm.  Does RFC977* say anywhere that IHAVE should check the messageid of the
received article against its argument?  Should we?  Perhaps that should
go in the BCP.
--
Chris Lewis, Senior Network Security Analyst, Nortel.
clewis at nortel.ca; Dept 4C16, Ottawa, Canada.  (613) 763-2935.