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

Julian Reschke wrote:
> > 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?

Just as an example, look at "edit". It is defined to always link to an
Atom entry. All the link currently-defined relations are defined by Atom
RFCs. 

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

You cannot resolve the references using URI resolution.
"../relation/next" is not the same as "next". You have to compare
everything character-for-character. 

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

That is against IETF policy. New standards have to allow the use of IRIs
wherever URIs are allowed. At least, that is what I was told on the Atom
mailing list. While I have read RFC 2277, I'm not an expert on IETF's
internationalization policy. However, I personally believe it is wrong
to create new standards where things may be named in European languages
but not in non-European languages.

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

It is just like putting localizable text in an XML attribute. See
http://www.w3.org/TR/2008/NOTE-xml-i18n-bp-20080213/. I'm not sure the
title subfield is worth fussing over too much.

I also think that the Link header is only useful for unregistered link
relations. Any time we would register a link relation, couldn't we just
register a HTTP header with the same name?

- Brian

Received on Wednesday, 12 March 2008 14:29:18 UTC