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

Roy T. Fielding wrote:
> On Mar 12, 2008, at 3:32 PM, Brian Smith wrote:
> > Julian Reschke 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
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).

> > Right, but only after you've verified that the document is 
> > conformant to RFC 4287. If you aren't sure that the link
> > relation is conformant, then you can't use IRI resolution
> > to verify it. Also, you have to make sure that whatever
> > library you are using to do the IRI resolution actually
> > supports IRIs, and not just URIs.
> 
> No, you can do anything you like with the link relation.  
> There are absolutely no universal requirements on the 
> Internet -- they all exist within the context of a given 
> interoperation.  Outside of that context, data is just data.  
> E.g., email addresses are not just used for sending email.

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.

> > If the link header is going to be (re-)standardized, it has to be 
> > specified in a new standard. It is out of scope for 
> HTTPbis. And, RFC
> > 2277 says all new IETF standards must support UTF-8, which implies 
> > that all new IETF standards for URI processing must support IRIs.
> 
> 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. 

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.

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.

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

- Brian

Received on Thursday, 13 March 2008 02:59:45 UTC