From: Russ Allbery (rra@stanford.edu)
Date: Mon Apr 30 2001 - 11:24:04 CDT
Clive D W Feather <clive@demon.net> writes:
> Xref is a perfect example of a local header. Note that slaving takes
> part within a cooperating subnet, and local headers may be preserved
> within such a subnet.
I have a major problem with this whole cooperating subnet business. I
think it's a cop-out. Particularly in this case.
That's separate from the idea of removing Xref headers when you feed a
news server outside your local domain... but how do you define domain?
There are some servers at Stanford that slave and some that don't.
They're all in .stanford.edu. I think this is completely the wrong metric
to try to use.
And like it or not, Xref slaving is now *part of the protocol*. It's
something that people use on the wire that could well stand to be
standardized at some point along with the rest of the stuff that's been
added to netnews since RFC 977 and RFC 1036. We can't just ignore it
because it happens within a "cooperating subnet." There are
interoperability issues surrounding how you parse Xref for slaving that
would be made easier by having a real standard.
> Brad's example of his C- headers is another case.
Brad is describing a news-based publishing system where the articles that
are made available to the public are different than the articles that
people work with internally. I don't see why there's any advantage, in
that specialized of a case, for using some generalized local header
concept (which may not even fit; what if there are several internal
domains that all want to see the full article?) rather than doing
precisely what they did, namely put a "prepare for public consumption"
step in the process of feeding the messages off-site.
So I'm still not convinced. I think there's a very high probability that
if they had a local header convention in software, they would have had to
tweak it anyway.
There's also the question of *why* we're standardizing such a thing.
Obviously, sites can configure their servers to strip or not strip any
headers they want; they're not permitted to do that for transit traffic,
but for locally originating traffic they pretty much have free reign. I
think adding headers to transit traffic and then removing them again,
regardless of the reason, is *dangerous*; you run a large risk of
accidentally releasing a corrupted (modified) message back into Usenet
proper. Accordingly, we shouldn't be encouraging it.
So you're left with just locally originating traffic like Brad's C-*
headers. So what, exactly, would have been the benefit to Clarinet had
local headers been standardized? What would that have made easier? What
would people have done differently in the presence of a generalized
standard for this? In reality, what they did was treat the internal news
system as basically a generalized posting agent that allowed a bunch of
unusual features (previewing of messages, for example) before passing the
articles along to the outside world, using the netnews protocol
internally. I think that's a complicated setup, but I think it's
consistent with our draft without the whole local headers concept. And
I'm just not understanding the benefit in this case to standardization.
Is it so that other sites would remove local headers if Clarinet's leaked?
I disagree with that as useful. The whole point of an internal system
like that is that you make sure it *doesn't* leak. If it does leak,
that's a serious bug and you fix it. In the meantime, having it patched
up by an external site is actually *counter-productive* since it takes
longer then to find the leak, plus I guarantee that some folks would
disable stripping of such headers just to see what was leaking. And
there's really absolutely no way to stop that, nor is there really any
justification to stop that; a standard that says you're required not to
pay attention to some of the headers you receive is rather absurd.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>