Feedback on draft-nottingham-http-link-header-03, was: Fwd: New Version Notification for draft-nottingham-http-link-header-03

Hi Mark,

here's some feedback on the latest draft...:

> 1.  Introduction
> 
>    This document defines typed link relations, independent of the
>    context they occur in.  It does so by clarifying the status of the
>    link relation registry established by Atom, and registering in it the
>    relations that are defined by HTML.

I think it does a bit more than "clarifying", as it establishes a new 
registry.
       >    Furthermore, an HTTP header-field for conveying typed links was
>    defined in [RFC2068], but removed from [RFC2616], due to a lack of
>    implementation experience.  Since then, several use cases for doing
>    so have surfaced.  However, because it was removed, the status of the
>    Link header is unclear, leading some to consider minting new
>    application-specific HTTP headers instead of reusing it.  This
>    document addresses this by re-specifying the Link header with updated
>    but backwards-compatible syntax.

Would it be useful to note that some UAs already support the Link header 
for linking to stylesheets (I think Opera and Firefox...)?

> 5.  The Link Header Field
> 
>        Link           = "Link" ":" #link-value
>        link-value     = "<" URI-Reference ">" *( ";" link-param ) )
>        link-param     = ( ( "rel" "=" relation-type )
>                       | ( "rev" "=" relation-type )
>                       | ( "type" "=" type-name )
>                       | ( "title" "=" quoted-string )
>                       | ( link-extension ) )
>        link-extension = token [ "=" ( token | quoted-string ) ]
>        relation-type  = URI-Reference |
>                       <"> URI-Reference *( SP URI-Reference) <"> 

I note that we lost the "anchor" parameter defined in RFC 2068, Section 
19.6.2.4, so we are not strictly speaking backwards-compatible... 


>    The title parameter MAY be used to label the destination of a link
>    such that it can be used as identification within a human-readable
>    menu.

-> s/MAY be/may be/ or /is/

> 6.2.  Link Relation Type Registry
> 
>    New relation types can be registered by IETF Review, as outlined in
>    [RFC5226].  Specifications of new values should use the following
>    template:

As far as I understand RFC5226, Section 4.1, this requires an RFC. Is 
that the intent?

> Appendix A.  Notes on Using the Link Header with HTML
> 
>    <html>
>      <head profile="http://example.com/profile1/">
>        <link rel="foo" href="/foo">
>      </head>
>      [...]
> 
> 
>    could be represented as a header like this;
> 
> 
>    Link: </foo>; rel="http://example.com/profile1/foo"

Maybe use "bar" instead of one of the "foo"s...

Also: is this the proposal how to embed full URIs into HTML4? Or should 
people just use the full URI in the rel value?

Other points:

- Comparison rules: I understand we only define link comparison for 
relations used in the HTTP Link header, and the rule is 
character-by-character, case-sensitive?

- We miss a "I18N Considerations" Section. It probably should mention 
IRIs in general, and how to I18Nize the title parameter (-> RFC 2231???)

- Do we need to talk about migration issues from the old base URI to the 
new base URI? Should both be treated the same when comparing relation 
values?

Best regards, Julian

Received on Monday, 1 December 2008 15:55:41 UTC