On Sun, Oct 11, 2009 at 11:39 PM, Ian Hickson <[email protected]> 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
