- From: Sean B. Palmer <sean@miscoranda.com>
- Date: Fri, 17 Apr 2009 12:29:35 +0100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, www-archive <www-archive@w3.org>
On Fri, Apr 17, 2009 at 11:34 AM, Julian Reschke wrote: > The disadvantages are: [...] > > - incompatibility with RDF properties If you want compatibility with RDF properties, the specification will have to state that all URI extension relations MUST return a 303 See Other response when dereferenced, as a consequence of this finding: http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039 Otherwise, you will have the situation where there can be valid URI extension relations which aren't compatible with RDF, and that the only way to test will be to dereference and place burden on the server. > and Atom link relations. Atom link relations are IRIs, whereas the Link header extension relations only cover URIs. So there's a similar incompatibility case here, though at least this doesn't require a server dereference to test. Overall I see the case that you're making for URIs, but it would be great if this could be tempered with some prose that mitigates against the inherent disadvantage of using URIs which Anne van K. has pointed out. > It seems that clarifying the use of meta/@http-equiv is something > the HTML WG should do. The basic problem here is what happens when an HTML 2 to 4.01 document is accessed on the filesystem. The behaviour of user agents peeking at http-equiv is, as Anne van K. points out, not allowed by the HTML 4.01 specification (and none others back to HTML 2; I've checked). But it's certainly the case that, for example, browsers will try to sniff the encoding from an http-equiv value for Content-Type when the HTML file is on the filesystem. So this is a de facto thing. I'm not sure whether this user agent behaviour is limited to sniffing an encoding or whether there are other things that get deployed. Refresh, potentially, though again this is something that HTML 4.01 explicitly tells people not to do and yet is still, as far as I know, widely supported. Kindest regards, -- Sean B. Palmer, http://inamidst.com/sbp/
Received on Friday, 17 April 2009 11:30:16 UTC