W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: Reviving HTTP Header Linking: Some code and use-cases

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 15 Mar 2008 08:55:30 +1100
Cc: Harry Halpin <hhalpin@ibiblio.org>, ietf-http-wg@w3.org
Message-Id: <1A312602-11D3-4721-A300-D3EFF0DEAFEE@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>


Thanks for the feedback. Responses inline...

On 15/03/2008, at 12:04 AM, Julian Reschke wrote:

>
> Mark Nottingham wrote:
>> I've submitted a draft-01 (perhaps against my best judgement; this  
>> discussion is rapidly consuming the mailing list...), which should  
>> appear shortly. In the meantime, it's available at <http://www.mnot.net/drafts/draft-nottingham-http-link-header-01.txt 
>> >.
>> It is in no way a finished product; it's just a straw-man that  
>> tries to cover the issues, so it's easier to appreciate what they  
>> are (even if we don't go in this direction).
>> ...
>
> Mark,
>
> I think this absolutely heads into the right direction.
>
> A few comments...:
>
> 1.  Introduction
>
>   A means of indicating the relationships between documents on the Web
>   has been available for some time in HTML, and was considered as a
>   HTTP header in [RFC2068], but removed from [RFC2616], due to a lack
>   of implementation experience.
>
> JRE: include reference for HTML

Ack

>       relationship   = URI-Reference |
>                      <"> URI-Reference *( SP URI-Reference) <"> )
>
>
> JRE: we probably should state that relationship names that include a  
> semicolon need to be quoted.

Ack

>   Relationship values are URIs that identify the type of link.  If the
>   relationship is a relative URI, its base URI MUST be considered to  
> be
>   "http://www.iana.org/assignments/link-relations.html#", and the  
> value
>   MUST be present in the link relation registry.
>
> JRE: why a new base URI? What's wrong with "http://www.iana.org/assignments/relation/ 
> " (<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section. 
> 4.2.7.2>)?

Hmm. That's the actual URI of the registry; we should ping IANA on  
this, but yes.

> 6.1.  Normative References
>
> JRE: I think RFC2434 and RFC3864 could be classified as informative.

Probably.


>
>
>   to map the profiled link relations to URIs.  For example, in 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"
>
> JRE: do we need to talk about profile URIs where concatenation does  
> not work well, such as "http://www.w3.org/2003/g/data-view"?

I'm not sure; I thought about it, but would like to see a use case  
where it's important. Not that there isn't one, but my limited  
imagination couldn't come up with one at 10pm last night.


>   HTML defines link relation values as case-insensitive, while the  
> Link
>   header's syntax does not.  Therefore, it is important to case-
>   normalise relation values in HTML before comparing or converting  
> them
>   to Link headers.
>
> JRE: impact on registration procedure? Avoid names that only differ  
> in case?

Nice catch.

>
>
>   Atom conveys links in the atom:link element.  When serialising an
>   atom:link into a Link header, it is necessary to convert any IRIs to
>   URIs, since HTTP headers cannot directly contain UTF-8.
>
> JRE: that's a bit misleading. For instance, a IRI that contains non- 
> ASCII Latin-1 characters could be put into an HTTP header, we just  
> don't want to allow that and chose URIs as format.

hmm.

>
>
>   Additionally, since the base URI for link relations in Link headers
>   is fixed, extension links (i.e,. those not in the registry) MUST be
>   serialised as absolute URIs.
>
> JRE: s/serialisized/represented/?

Sure.

>
>
>
> BR, Julian
>
>


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 14 March 2008 21:56:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:37 GMT