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

§ 4.

   “There are two kinds of relation types; registered and extension.”

Change “types;” to “types:”.

§ 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.

§ 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.

   “Note that while extension relation types are required to be URIs, but
   a serialisation of links MAY specify that they are expressed in
   another form, as long as they can be converted to URIs.”

Delete either “while” or “but”.

§ 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?

   “Here, the second link has a title encoded in UTF-8, uses the German
   language ("de"), and contains the Unicode code point \u'00E4' ("LATIN
   SMALL LETTER A WITH DIAERESIS").”

\u'00E4' is a character, not a code point. A code point in Unicode is
simply a number, so the code point here is 0xE4, or 228 in decimal.
The convention for representing a character, moreover, is U+HHHH; in
this case, you would use U+00E4. I would suggest changing this passage
to something like:

   Here, the second link has a title encoded in UTF-8, uses the German
   language ("de"), and contains the Unicode character U+00E4 ("LATIN
   SMALL LETTER A WITH DIAERESIS").

§ 6.2.

   “The Link Relation Type registry's initial contents are:”

This table doesn't contain all of the values from the Atom registry:

http://www.iana.org/assignments/link-relations/link-relations.xhtml

Update it to include “service” and “up”.

§ 7.

This Security Considerations section makes no mention of the authority
risks associated with the rev relation, as expounded by you in an
excellent recent essay. Though rev is said to be included for legacy
purposes, there is no “SHOULD NOT” about its usage. Should § 5 be
updated to say that rev SHOULD NOT be used?

Kindest regards,

-- 
Sean B. Palmer, http://inamidst.com/sbp/

Received on Friday, 17 April 2009 09:48:35 UTC