From: Russ Allbery (rra@stanford.edu)
Date: Mon Apr 23 2001 - 22:45:03 CDT
Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> I think the proper way for new headers is for IANA to keep a definitive
> list of defined headers for mail, news and HTTP (there is much, but not
> total, commonality between them).
That would certainly be one direction in which this could go. Someone who
wanted to do us all a favor could take that on as an action item and at
least figure out what procedures would be involved in setting such a thing
up. I think it's been tried for mail before, unsuccessfully, and there
are some informational RFCs with informal lists.
> But do people think that such an IANA registration of headers should be
> pushed for as a longer term goal?
It sounds like a reasonable idea to me.
> Currently, as I said before I went away, it is a SHOULD (so John Stanley
> has been tilting at windmills for all of this week). I think SHOULD is
> about the right level for generic local headers. We could say something
> stronger for the Xref header in particular if people want it that way.
My personal opinion is (1) that generic local headers should be removed
entirely and that Xref should be separately documented as a weird case for
replication reasons and (2) that accuracy of Xref when served to a reading
client should be a MUST.
These two opinions are seperate; fixing one of the above problems doesn't
fix the other and vice versa.
> But bear in mind that there are two levels of defence here.
> 1. Serving agents SHOULD (was MUST) remove it on arrival, to avoid
> confusions.
To clarify, I think this SHOULD is fine.
> 2. Serving agents whose clients expect it to be meaningful SHOULD have
> replaced with their own version before letting clients see it.
This SHOULD, however, should be a MUST. And *all* clients should be able
to expect meaningful Xref headers; it's part of the article format now,
and it's how crossposted articles are handled.
> So a serving agent has to get two things wrong before trouble ensues,
> which I think implies that SHOULD is strong enough.
I don't understand your logic here. Two SHOULDs are equivalent to one
SHOULD in determining conformance. I don't believe a conforming
implementation should be permitted to return invalid Xref information, at
least to the extent of ensuring that the newsgroup and article number
information is accurate (I don't care about the path portion). Invalid
Xref information breaks clients.
> Note that Xref is the only local header we have defined (and the lists
> of "examples" of header properties we give in 4.2.2 are in fact
> complete, though we do not formally say so). Future standards,
> cooperating subnets, and even individual sites may choose to define
> additional local headers. Ideally, they should not let them escape (we
> say they MAY remove them before they leave the local boundaries) but we
> cannot expect external sites necessarily to recognise them as local
> (another reason why "SHOULD be removed" is more appropriate than "MUST
> be removed").
We're borrowing all this trouble just to provide a specification for
something that no one uses. I think this is pointless, and think we
should refrain from trying to make up protocols for local headers until
such time as someone actually comes up with one and wants to standardize
it. In the meantime, Xref is unique since its accuracy is actually part
of the protocol and required to convey expected information from the
server to the client, *and* since it's also used for slave replication.
Any other local header I would argue should just be stripped before
sending the article off the server. You can't do that in all cases with
Xref because of replication.
Furthermore, the right place to handle local headers is in overview, not
in the actual article, and putting into the standard language that seems
to encourage people to modify the articles is in my opinion a bad idea.
Again, this would also be the right way to handle Xref except for
replication and historical behavior.
The correct solution to this problem is to realize that we're trying to
solve a nonexistent problem and simplify the draft accordingly. Xref is
the last header that we should be trying to generalize; Xref is to a large
degree a weird hack that happened to work and now is too widespread and
widely used to fix, and bad cases make bad law.
The advantage of doing this is that we can move closer to fully
enumerating all headers that a transit server is permitted to change
without including this nebulous class of "all local headers."
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>