- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 17 Apr 2009 12:34:43 +0200
- To: "Sean B. Palmer" <sean@miscoranda.com>, "Mark Nottingham" <mnot@mnot.net>
- Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
On Fri, 17 Apr 2009 11:47:39 +0200, Sean B. Palmer <sean@miscoranda.com> wrote: > § 4.1. > > “[...] However, the URI form > of a registered relation type SHOULD NOT be serialised when an > application specifies the use of a relation type, because a consuming > implementation may not recognise it.” > > Why not MUST NOT? You say that applications can identify the tokens > *internally* using URIs, but not that they may do so externally. So > logically, you can't serialise a token using its URI, because there is > nothing at all to say that there is an external equivalence between > tokens and their URIs. > > I suggest adding, to make this clear, that registered relation types > MUST be compared character for character, as well as in a > case-insensitive fashion. I agree with this comment. I'm not that interested in dealing with bug reports that we need to handle <link rel=http://www.iana.org/assignments/relation/stylesheet href=...> and such. > § 4.2. > > “Applications that don't merit a registered relation type may use an > extension relation type, which is a URI [RFC3986] that uniquely > identifies the relation type.” > > Why not use reversed domain names? For example: > > Link: <http://example.org/>; rel=index; > rel="start net.example.rel.other" > > The advantage is brevity. Since the specification also says that > clients SHOULD NOT dereference the URIs identifying the relation > types, it doesn't seem to matter that the extension type be a URI, > except for consistency with the URI forms of the registered relation > types. I agree with this comment as well. Using URIs as identifiers leads to consumers trying to retrieve the URI. (See Netscape RSS DTD, W3C systeam.) > § 5. > > “[...] It is semantically equivalent to the > <LINK> element in HTML, as well as the atom:link feed-level element > in Atom [RFC4287].” > > Doesn't this mean that HTML user agents will have to support the > following? > > <meta http-equiv="Link" value='<style.css>; > rel="stylesheet"; type="text/css"'> > > Why burden HTML user agents in this way? Could you specify that Link > has no meaning when used in conjunction with meta/@http-equiv in HTML? FWIW, HTML5 makes it clear that http-equiv does not work this way. (And in HTML4 it was actually a processing instruction for servers that was never implemented IIRC.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 17 April 2009 10:35:32 UTC