From: Charles Lindsey (chl@clw.cs.man.ac.uk)
Date: Mon Apr 23 2001 - 10:21:39 CDT
In <yl8zl45wrw.fsf@windlord.stanford.edu> Russ Allbery <rra@stanford.edu> writes:
>Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
I have been away for a week, and I see you have all been busy in my
absence :-) . However, that does give me the benefit of having seen the
whole of the fuss before I start to respond to it.
>> As for the X-headers themselves, they are a well established feature of
>> many internet protocols,
>They are a widely described feature of many Internet protocols and pretty
>uniformly controversial whenever people try to add them.
>Well, that pretty much makes them useless for future evolution of Usenet,
>so why would anyone use them apart from as a place to dump random junk?
>Under that rule, X-No-Archive could have never been started in the first
>place. I don't think that's useful; requiring people to write an RFC
>before they can add an additional meaningful header to a news article just
>isn't going to work, because the reality is that people won't do that, and
>since the software has to cope anyway there's no way of forcing them to.
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).
If you propose a header that is to be purely informational, then it can be
an X-header. If it is just for an experiment you are conducting, or for
use on a small cooperating subnet, then it can be an X-header. But if it
is for an experimental protocol which you hope/expect will become widely
adopted in due course, then you ought to be able to go to IANA and ask for
a provisional registration (perhaps with some time limit). There is plenty
of precedent for IANA to do that sort of thing.
But what is the proper way to bring about that state of affairs? It would
need agreement from all of the mail, news and HTTP communities, and I
don't think the USEFOR draft is the proper place to try to set it up (but I
might be able to do some future-proofing of the wording in the hope that
it might be brought in later).
But do people think that such an IANA registration of headers should be
pushed for as a longer term goal?
>> I think harm could arise if a reading agent saw an Xref header with an
>> article number left over from some upstream site and presumed that it
>> was meaningful on the local server (even if the local server did not use
>> article numbers for some reason).
>Good point. However, I think this is better dealt with as a constraint on
>the Xref header itself rather than as a constraint on all local headers.
>> So it is much better to get rid of them. But I agree this is a SHOULD
>> rather than a MUST, so I have changed it.
>No, I think a MUST is valid for Xref headers. Clients use that for
>crossposting; you can't be providing invalid Xref headers. But that
>restriction should be described as a property of Xref headers, not as a
>general property of all local headers.
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.
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.
2. Serving agents whose clients expect it to be meaningful SHOULD have
replaced with their own version before letting clients see it.
So a serving agent has to get two things wrong before trouble ensues,
which I think implies that SHOULD is strong enough.
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").
In John Stanley's example, Site B was clearly a cooperating subnet (maybe
a subnet of one) but site C had elected to become a part of that same
subnet (whether with B's approval or not). We make specific provision for
the boundary or scope of a local header to include a group of machines,
and indeed this is commonly done where several machines choose to use a
common set of article numbers. I have now tweaked the text a little more
to make it, hopefully, Stanley-proof:
Headers with the local property are significant only to a particular
serving agent, or cooperating group of such agents. They MAY be
removed by relaying agents before propagation beyond that group, and
SHOULD be removed (and replaced as necessary) by other serving agents
when received. The replaced header MAY be placed anywhere within the
headers (though placing it first is recommended). The principal
example is:
o Xref (6.16) - used to keep track of the article locators of
crossposted articles so that newsreaders can mark such articles
as read.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5