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

Brian Smith wrote:
>> It is best to have one and only one registry, even if a few 
>> relations have entirely different meanings in different contexts.
>> It is still valuable to know that those contexts exist.
> 
> Still, nobody has justified why a registry of link relations is
> necessary for the Link header. If you are going to register a link

To avoid relation name collisions?

> relation, you are better off just making a new HTTP header that works
> like all the other link headers in HTTP (e.g. Location,
> Content-Location).

Besides avoiding having to many HTTP headers?

One reason is that in (X)HTML, you will need a link relation to include 
the information into the document. So it seems to be a better design to 
have the same mechanism both at document and transport level, in 
particular when it already is specified that way in HTML 4.01 and the 
proposed standard of HTTP/1.1 (which is RFC 2068).

> There must be some miscommunication here. My point is that the Atom way
> of having two forms of each registered link relation is more complicated
> than necessary, offers no real benefits, and should be avoided. The
> easiest way to avoid it is to just not have a registry at all. Barring
> that, at least make the rules for parsing link relations simpler than
> the Atom rules.

I fail to see how this is a problem in practice:

- reject references that are not simple names
- then resolve against the base URI

>> First, HTTP header fields and methods are a flat namespace.
>> Link and PATCH were defined in the original HTTP 
>> specifications and only removed to to a lack of known 
>> implementations.  They would only be "new" if their 
>> definitions were substantially changed, which I don't see 
>> happening.  Removing Link from 2616 was a very bad editorial 
>> decision and I don't see how putting it back in can be seen 
>> as anything other than an editorial correction -- it is not 
>> as if we are changing the meaning of HTTP in the process.
> 
> Even with that (very liberal) interpretation of the situation, these
> features still cannot be added in HTTPbis, because the working group is
> supposed to "remove or deprecate those features that are not widely
> implemented." Saying LINK, UNLINK, PATCH, etc. are "not widely
> implemented" would be putting it lightly. 

Let's focus on "Link" (the header). I do agree that PATCH, LINK and 
UNLINK (the methods) aren't widely implemented.

"Link" is part of HTTP/1.1, just not as part of the latest draft 
standard. It was left out because of missing support, or because people 
weren't aware of it.

As far as I recall, several user agents now do support Link: to specify 
CSS, so this has changed.

> It looks like it will take a lot of time just to resolve the core issues
> with RFC 2616, such as how content negotiation interacts with
> conditional requests, clarifying "idempotency" (or removing references
> to the concept if it is as unimportant as you say), making pipelining
> usable, and all the other issues that are in the issue tracker. I'm
> pretty sure there is no time to resurrect PATCH, LINK, UNLINK, Link:,
> and other such functionality while staying on schedule. And, I don't see
> how it is possible to get adequate implementation feedback on these (as
> yet unimplemented) old features in time to make any necessary
> corrections before October.

Again, "Link:" is implemented.

I do agree that we should prioritize the things that are on our issues 
list, and I also agree that discussing other things won't probably with 
the schedule.

As a matter of fact, I'm concerned that we aren't making sufficient 
progress to have any chance to meet our deadlines.

That being said, people discuss those things they are interested in. If 
these things belong to HTTP/1.1, I'd rather have the discussions here 
then somewhere else.

> I am not against those features, I just think they could easily be
> specified in separate RFCs so that HTTPbis can remain focused on the
> core problems with the functionality that is defined by RFC 2616.

Yes, but it's not 100% clear (to me) where to draw the line.

>> Second, there is no such requirement for IRIs -- URIs are 
>> fully capable of describing all possible IRIs (by definition) 
>> and thus do not prevent i18n.
> 
> If URIs were adequate for internationalization, then IRIs would never
> have been created. Anyway, I pointed out in a previous message how IRI
> link relations can be easily supported in the Link header while using
> Atom-like character-by-character comparison, by requiring IRI-to-URI
> conversion when writing the header field, and requiring URI-to-IRI
> conversion before comparing link relations to each other.

Understood, but not pretty at all :-)

BR, Julian

Received on Thursday, 13 March 2008 08:50:58 UTC