Completely agreed.
The only distinction I'd make is that if you *ever* want the
opportunity to extend (i.e., if the world is less than ideal), there
better be some accommodation for it now, or things will break in nasty
ways when it gets added and existing implementations trip across the
extensions.
If there's a really high degree of certainty about the current payload
of the header, the WG could make a conscious decision to freeze it,
with the understanding that any changes / additions would have to be
in separate (probably new) headers. IME, most people find this
unpalatable, but YMMV.
The other approach would be to allow extensibility in the BNF, but
place restrictions on the creation of extensions WRT backwards-
compatibility (and perhaps even restricting who can mint extensions;
e.g. to W3C REC-track docs).
Cheers,
On 29/01/2008, at 1:15 PM, Ian Hickson wrote:
On Tue, 29 Jan 2008, Mark Nottingham wrote:
1) You'll have to change it anyway if you want to support
extensions. I
haven't seen a discussion of this yet.
For what it's worth, I actually consider this a feature, not a bug.
Making
extensions to this should be _hard_, to reduce the temptation for
people
to actually extend it. Ideally, this would never be extended.
--
Ian Hickson U+1047E )
\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _
\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--
(,_..'`-.;.'
--
Mark Nottingham [EMAIL PROTECTED]
