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

Julian Reschke wrote:
> Brian Smith wrote:
> > 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 too many HTTP headers?

That is a bogus argument. As Roy said earlier in the thread, "the link
relationship space is supposed to be small, universal, and standardized
(just like HTTP methods)." Besides, is somebody going to be able to able
to register a link relation with the same name as a registered HTTP
header, or vice versa? It would be nonsense to register a
"Content-Location" link relation. If somebody registers an "next" link
relation, it would be very confusing to then allow someone else to
register an "next" HTTP header with totally different semantics. So,
effectively HTTP link relations and HTTP headers share the same
namespace.

As far as I understand the LINK and UNLINK methods, they exist soley to
edit "Link:" header field values. But, why have a method that can only
edit one header field, when we could have a method that allows for the
editing of any header for a resource? Roy already said that PATCH is
supposed to have that ability. Once you have that method, the need for
LINK and UNLINK goes away, which also reduces the need for the Link
header.

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

I would agree, except that Roy already said that the semantics for HTTP
links do not have to match the semantics defined by Atom (or HTML, I
presume) for any link relation. And, the syntax has to be different from
one of them, because Atom link relations are case-sensitive and HTML
link relations are case-insensitive. So, we would end up with something
where the syntax is similar-but-different and the semantics are
similar-but-different. So, it is not really "the same mechanism" at all.

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

Let's say you want to check for an "edit" link. It would be simpler to
only need to either check if that the relation is "edit" or check that
it is "http://www.iana.org/assignments/link-relations/edit", instead of
always having to check for both. Already, some (many? most?) Atom
implementations fail to understand the longer form, so it is already an
interoperability issue for Atom. 

> Again, "Link:" is implemented.
> 
> 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.

Anything that is already in RFC 2616 should be fixed first, before
worrying about stuff that RFC 2616 removed from RFC 2068. 

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

Nothing regarding URI-IRI conversion is pretty. But, keep in mind that
it only would affect people who use link relations that where
IRI->URI->IRI conversion is not a no-op. Basically, it would not effect
users of European languages at all, but it would provide users of
non-European languages with a facility for using their own language if
they so desire.

Regards,
Brian

Received on Thursday, 13 March 2008 12:57:54 UTC