W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Review Comments for draft-nottingham-http-link-header-05

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>
Message-ID: <op.usi0z5cs64w2qv@annevk-t60.oslo.opera.com>
On Fri, 17 Apr 2009 11:47:39 +0200, Sean B. Palmer <sean@miscoranda.com>  
> § 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='&lt;style.css&gt;;
>          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
Received on Friday, 17 April 2009 10:35:32 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC