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

Brian Smith wrote:
> 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. 

OK, thanks for clarifying.

So making this a non-specific Atom registry probably requires making 
these relations have generic semantics.

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

RFC 4287 says that relative references 
(<http://greenbytes.de/tech/webdav/rfc4287.html#rfc.section.4.2.7.2>) 
must be simple names:

"Note that use of a relative reference other than a simple name is not 
allowed."

It continues specifying how to compare relations:

"If a name is given, implementations MUST consider the link relation 
type equivalent to the same name registered within the IANA Registry of 
Link Relations (Section 7), and thus to the IRI that would be obtained 
by appending the value of the rel attribute to the string 
"http://www.iana.org/assignments/relation/"."

So it seems to me that this *is* URI resolution.

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

I don't think this is true.

Also, we're not really talking about something new here; what's being 
discussed is restoring what RFC 2068 already said about "Link:".

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

If this would be a new standard, I would agree.

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

Interesting thought :-)

BR, Julian

Received on Wednesday, 12 March 2008 14:44:37 UTC