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