- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 12 Oct 2009 06:39:47 +0000 (UTC)
On Wed, 7 Oct 2009, Alex Russell wrote: > > As currently specified, HTML 5 includes a list of pre-defined good > values for http-equiv [2] and specifies a pragma extensibility mechanism > [3] which predicates new entries on being registered HTTP headers from > duly submitted RFCs. This is onerous and does not fit well with current > network-level practice. It is onerous intentionally; the idea is to reduce the use of this mechanism, as it has almost universally been misused. > RFC 2616 [4], section 6.2 provides a mechanism for coordinating servers > and clients to use extensions: > > However, new or experimental header > fields MAY be given the semantics of > response-header fields if all parties in > the communication recognize them to > be response-header fields. Unrecognized > header fields are treated as entity-header > fields. > > Server and client authors have used the "X-*" convention to denote such > extension fields as a forward-compatible prefix. In order for HTML 5 to > better represent real-world content, we'd like to request that an > exception be made to the "registered via RFC" rule for http-equiv > headers which are prefixed with "X-", or, alternately, that the spec > simply declare that unlisted keys and values will not be considered > invalid, but rather that only invalid values for listed keys trigger > validity errors. This would make X-UA-Compatible conforming, which is not desireable. We want to _discourage_ mechanisms that lead to vendor-targetting of that nature. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: > > 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. Indeed. On Fri, 9 Oct 2009, Julian Reschke wrote: > > 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. On Fri, 9 Oct 2009, Maciej Stachowiak wrote: > > I think the HTML5 requirement should be changed to allow any header in > the Permanent Message Header Field Registry. Effectively, this would > require either an RFC or an Open Standard. This seems just as good for > HTML5's purposes as requiring an RFC. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Sunday, 11 October 2009 23:39:47 UTC