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

On 02/12/2008, at 2:54 AM, Julian Reschke wrote:

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

Ack.


>
>      >    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...)?

Ack.


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

Well, in the sense that it can be a link-extension, we are...

>
>
>>   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/

Ack.


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

See discussion with danc.


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

Ack.

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

It's not to put full URIs into HTML; rather, how to transform profiled  
relations into Link headers.


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

Good question. My inclination at this point is to say that's the case,  
and make it explicit.


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

Ack.


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

Urgh. Maybe.



Many thanks,


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 3 December 2008 02:32:50 UTC