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

Re: draft-nottingham-http-link-header-01.txt - problem with default relationship base URI

From: Jonathan Rees <jar@creativecommons.org>
Date: Fri, 30 May 2008 12:07:52 -0400
Message-Id: <96E4AA2E-6E00-4B8B-A3CD-2AE46F10820E@creativecommons.org>
Cc: ietf-http-wg@w3.org
To: Julian Reschke <julian.reschke@gmx.de>

OK, good.

Regardless of where the documentation lives it looks like you should  
either use a base URI that ends in / or specify concatenation instead  
of relative URI resolution (which would be inelegant).

My vote would be for /, with a non-200 response to respect the idea  
that relations (in the sense of logical entities) don't have  
representations (in the sense of RFC 2616). The response could be,  
say, a 303, redirecting to a file containing documentation (maybe  
wrapped in RDF) for that relation.


On May 30, 2008, at 11:44 AM, Julian Reschke wrote:

> Jonathan Rees wrote:
>> Re http://tools.ietf.org/id/draft-nottingham-http-link- 
>> header-01.txt :
>> 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.
>> My understanding of the way that a relative URI gets combined with  
>> a base URI (RFC 2396 section 5.2) is that if you combine the above  
>> base URI with "next" you get
>> http://www.iana.org/assignments/next
>> not
>> http://www.iana.org/assignments/link-relations.html#next
>> and I think you intend the latter, not the former.
> This is a known problem; IANA is serving the link relations page at  
> <http://www.iana.org/assignments/link-relations.html>, but RFC4287  
> says that the base URI is <http://www.iana.org/assignments/relation/ 
> >. See <http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 
> 0543.html>.
> > ...
> BR, Julian
Received on Friday, 30 May 2008 16:08:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:46 UTC