- From: Alex Russell <slightlyoff@chromium.org>
- Date: Mon, 12 Oct 2009 10:53:15 -0700
On Sun, Oct 11, 2009 at 11:39 PM, Ian Hickson <ian at hixie.ch> wrote: > 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. So just to clarify: should we standardize X-UA-Compatible at the IETF, the validator would no longer complain about it, assuming that you'll accept it in the wiki (which I'd like to be clear on)? Regards
Received on Monday, 12 October 2009 10:53:15 UTC