From: Brad Templeton (brad@templetons.com)
Date: Sun Apr 29 2001 - 23:40:54 CDT
On Sun, Apr 29, 2001 at 12:55:02PM -0700, Russ Allbery wrote:
> Brad Templeton <brad@templetons.com> writes:
>
> > There were two different proposals for how to identify local headers, so
> > they can be distinguished from others, with XRef grandfathered in but
> > eventually changed.
>
> > The first was to have them start with L-, however later I felt that the
> > use of MIME syntax made more sense, since new headers should be defined
> > in an extensible fashion anyway.
>
> News software already knows how to handle Xref and wouldn't know how to
> handle L-Xref. What purpose is served by doing this?
The proposal, in either form, was to grandfather Xref, though encouraging
its migration within local systems. The idea is that new local headers
could easily be added without causing trouble for other systems. I
contend that this level of extensibility is essential for a USENET that
is capable of growth.
We have adequately demonstrated -- sadly with my participation -- that
we can't act at any speed to extend USENET through a standards group!
What's essential is to take this opportunity to create an environment
where others can experiment and have existing software do the best
possible job of dealing with the enhancements.
>
> News software already knows how to handle Xref and would break on the
> inclusion of a ";site=domain.name" string in the Xref header, since that's
> syntactically invalid for Xref. What purpose is served by doing this?
Again, Xref would be grandfathered, as would all existing headers for some
time to come.
>
> I an opposed to all proposals along these lines for the reasons stated on
> this mailing list over the past two weeks. They're solutions in search of
> a problem.
That's a reason to support extensibility! The whole point of designing
for extensibility is that you don't know the problems, or solutions,
of the future, so you design as best you can to allow new features and
experimentation without fear of breaking older software.
Often we've felt that we could fix a problem by extending an existing header
but we can't. That should be a clear lesson about extension.
This is hardly a new philosophy, in fact at this point I had thought it
was close to a motherhood issue -- I'm surprised to see any opposition to it.
All tools should handle extension tags on all headers for which they are
possible. Of course, on existing headers, no software should generate
extension tags yet. That comes years down the road, when software that
can't handle them is obsolete. Designing a new header without extensibility
would be crazy.