- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 16 Nov 2010 18:36:07 -0800
- To: David Singer <singer@apple.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Maciej Stachowiak <mjs@apple.com>, Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, "public-html@w3.org" <public-html@w3.org>
On Nov 16, 2010, at 5:10 PM, David Singer wrote: > On Nov 16, 2010, at 10:26 , Roy T. Fielding wrote: > >> On Nov 16, 2010, at 10:00 AM, David Singer wrote: >>> On Nov 16, 2010, at 4:58 , Julian Reschke wrote: >>> >>>> Also, *if* we agree that the algorithm is for http-equiv only, then the whole note about being a "willful" violation of HTTP becomes questionable; it should be rewritten to actually state what the difference is, and why this is the case (and as demonstrated before, "compatibility with legacy content" as single reason is incorrect). >>> >>> >>> It's worth noting that something that is not part of the HTTP protocol per se, and hence not subject to its rules, can hardly be said to be in willful violation of them. Differ from them, perhaps. >> >> The sole purpose of http-equiv is to state that this metadata name is >> defined by the HTTP standard and provided in the HTTP field-value syntax. >> Otherwise, use the name attribute. > > > I think we're trying to say two contradictory things. "This metadata name is defined by the HTTP standard and provided in the HTTP field-value syntax" (precisely), and then also "but the syntax and parsing rules are not, in fact, as defined in the HTTP syntax, but differ from them". This isn't a 'willful violation' of HTTP, but merely a contradictory pair of statements. As mentioned before, there is no reason for any difference in syntax. In fact, there is none in practice. The only reason that this is an issue at all is because the draft contains incorrect statements and unimplemented algorithms, apparently based on bugs in a single browser. The solution is to remove the contradiction from the spec by restoring the original text that defined meta and http-equiv. ....Roy
Received on Wednesday, 17 November 2010 02:36:38 UTC