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

Brian Smith wrote:
> Roy T. Fielding wrote:
>> However, RDF pretty much screwed us all on that one, so the 
>> reasonable next step is to allow URIs and have all flat names 
>> be relative to the same link relationship registry as Atom.
> 
> HTTP cannot share the same link registry as Atom unless the Atom link
> registry is completely redone. The whole registry is specific to Atom or
> feed processing.

How so?

> Furthermore, the Atom mechanism for registration means that any
> registered link relation has two names: "xxx" and
> "http://www.iana.org/assignments/relation/xxx". This has made processing
> links in Atom feeds unnecessarily tedious. It would be better to come up

I wouldn't call it two names, but just two notations. Before comparing, 
resolve all references against 
""http://www.iana.org/assignments/relation/" and everything should be fine.

> with a new mechanism that either required everything to be an IRI or at
> least didn't allow registered link relations to be used with the IRI
> form.

IRIs are indeed a problem if we want to use them inside an HTTP header.

> The Atom mechanism does comparisons character-for-character. An IRI and
> its URI equivalent do not match. That means that RFC 3987 IRI-URI
> conversion cannot be used for the Link header; instead, something like
> percent-encoded Unicode would be needed.

Sounds like a good reason for not allowing link relations that aren't 
URIs (or URI references).

> The "title" subfield is also problematic. It must be properly
> internationalized, including proper support for Ruby annotations and
> BIDI text. If that can happen, then I would like to see a "Title:"
> header field too, so that I can HEAD a document to get its title. 

Is there a problem with the title parameter (of the link header), except 
for the ugly rules for non ISO-Latin1 characters?

BR, Julian

Received on Wednesday, 12 March 2008 13:35:44 UTC