POST, IHAVE, and header-munging (was Re: ietf-nntp BCP for RFC977 server/RFC1036 interaction)

[Ade Lovett]

Brian Kantor writes:
>
>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.

	[and then]

>... 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.


Sigh.  This is >exactly< the argument I'm trying to avoid.

I *know* about 977.  I *know* it's not literal. I am *asking* for
sensible clarification of POST and IHAVE for offline newsreaders.

Consider the following scenario:
	- company A installs local news server, be it INN, CNEWS+refnntp or
	  some homebrew setup [assuming, for now, a Un*x system
	  at their end]
	- company A installs standard 33k6 dialup to local ISP, slurps
	  down articles from comp.something, and allows its employees
	  to post back to that group, using their local nntp server,
	  which isn't necessarily internet-connected 24x7
	- company A wants locally-posted articles propogated out to
	  the rest of the universe.

Since the articles aren't 'new' -- they've already been POSTed to
a local (offline) nntp server, it is entirely reasonable that
they be transferred to local.isp via IHAVE.

Now consider scaling company A up to n-thousand company A's..  as
a sensible ISP, do you really want n-thousand news 'peers' ??

The problem here is that POST and IHAVE are orthogonal methods
of injecting articles from point-A to point-B; this nicely fits
in to the distinct online-reader/news-peer setup that used to be
with us, but, as 'guardians' of the protocol we have to realise
that things are not as black and white as that any more, and we have
a new class of end-user systems for which neither POST nor IHAVE
are 'correct'.

The question is what to do about such 'gray' people..  I *know* there
are pieces of software available to, for example, make an INN system
propogate outbound articles via POST rather than IHAVE, but such software
can only really be considered as being a hack around a 'deficient'
protocol.  Deficient in that it at the time of writing, it lacked the
necessary crystal ball to see what people in general would be doing
with nntp in the heady days of mid-1997 :)

Whilst I'm in the business of writing backend-transport and
client-facing nntp-servers, I don't have much of an ax to grind
over what the actual magic runes in 977:next_generation should be
with regards to header-munging to allow for traceability (amongst
other stuff) of articles 'distributed' not only via the
client->server POST command, but also offlineserver->server IHAVE
command (as opposed to peer->server IHAVE/TAKETHIS command)

What I would like to see is the issue of offlineserver->server
article transfer addressed.  What NNTP command, if any, should be used.
What headers may be munged. etc.. etc..

If it's as simple as "IHAVE is for peer->peer transfer, we don't
care about offlineserver's, they can go to hell" then that will make
me happy insomuchas it *clarifies* the RFC with respect to current
practices.  It then becomes >my< problem (as opposed to the Internet
community at large) to explain this to my particular management, before
nuking IHAVE from my coding, and having to figure out alternate
methods to handle all those offline-servers that we have.

-aDe

-- 
Ade Lovett, Demon Internet Ltd.