From: Russ Allbery (rra@stanford.edu)
Date: Fri Apr 13 2001 - 16:12:51 CDT
Charles Lindsey <chl@clw.cs.man.ac.uk> writes:
> I agree that is maybe a bit too strong, but I see no other way to word
> it that does not give carte blanche to upstart implementors (a certain
> Mr Gates springs to mind) to invent new "features" that turn out to make
> Usenet unusable for everyone else. That has happened too many times in
> the past.
No standard can stop that. I think trying is more harmful than useful in
this particular case. News software is going to be extended beyond the
capabilities described in this draft, and that SHOULD NOT basically says
that anyone who does anything at all with news headers not anticipated by
our draft is no longer strictly conforming. I don't think that's a useful
stake to put in the ground.
> 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.
> And they should not be used except for informative purposes, or where
> their interpretation only affects things external to Usenet (in the way
> that X-No-Archive did not affect anything within Usenet, though it did
> affect what was done in archives that were not a part of Usenet itself).
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.
>> Did you mean "can be"? If a server does not care about some header that
>> is local to some other site, and it does not understand that header, it
>> should not do anything with it. Or it should be free to keep it if it
>> likes it.
> 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.
> Yes. It is so by definition since if the "-- " is absent, then it is not
> a "personal signature". So if you want it to be regarded as a signature,
> then you MUST do it properly. There have been user-agents that have done
> this wrongly in the past, and have caused much grief and flammage as a
> result.
The grief and flammage in my opinion stems directly from attempting to
apply structure to unstructured content via ad hoc rules and trying to
standardize the ad hoc rules that people have used to do that I don't
think is a viable long-term solution to the problem.
-- Russ Allbery (rra@stanford.edu) <http://www.eyrie.org/~eagle/>