On Oct 9, 2009, at 4:58 PM, Alex Russell wrote:
On Fri, Oct 9, 2009 at 11:21 AM, Julian Reschke
<[email protected]> wrote:
True, but there is no real "X-" prefix convention for HTTP headers.
But, there is a registration procedure, defined in RFC 3864. It
defines two
registries, a provisional, and a permanent. The latter (and only
that)
requires:
Registration of a new message header field starts with construction
of a proposal that describes the syntax, semantics and intended use
of the field. For entries in the Permanent Message Header Field
Registry, this proposal MUST be published as an RFC, or as an Open
Standard in the sense described by RFC 2026, section 7 [1].
(<http://tools.ietf.org/html/rfc3864#section-4.1>)
The HTML5 requirement goes further than the IETF requirement; I would
consider that a bug.
The more general point is that neither the spec nor the Validator
doesn't seem to be savvy to any of this. The request that we observe
the defacto "X-*" prefix is just a softer form of the general request
that the spec should not call headers that it doesn't understand
"invalid", casting documents that use them for compatibility reasons
into invalidity purgatory. I'd strongly prefer that the spec were
silent on un-specified values, noting instead that they should not
cause a document to become invalid, rather than carving out special
handling for one prefix.
HTML5 has a lot of extension points where, to make an extension valid,
you have to provide an open standard specifying its behavior. The idea
is that if you want something to be conforming, you have to specify it
well enough to allow interoperable implementations. The design of X-UA-
Compatible seems to make interoperability impractical. And I suspect
Microsoft has no interest in specifying it in the form of an open
standard. So making it noncomforming is serving the goals of the spec,
just as using proprietary elements or attributes is nonconforming. You
could question the goals, but they seem reasonable to me.
Regards,
Maciej
