Re: I-D ACTION:draft-nottingham-http-link-header-01.txt

Julian Reschke wrote:

> Brian Smith wrote:
>> ...
>>>> 1. There is too much flexibility in the syntax of the "rel"  parameter. 
>>>> For
>>>> example, the following all mean the same thing:
>>>>      rel=edit
>>>>      rel="edit"
>>>>      rel="\e\d\i\t"
>>>>      rel="http://www.iana.org/assignments/link-relations.html#edit"
>>>>      ....
>>>> If you want to be able to catch all variations, then you have to  write 
>>>> a pretty nasty regular expression.
>>> What leads you to believe that "\d" is the same as "d" in a URI 
>>> reference?
>>
>> "\d" and "d" mean the same thing according to the definition of
>> quoted-string in RFC 2616, AFAICT. We are supposed to unescape
>> quoted-strings before processing them, right?
>> ...
>
> That seems like a very academic argument to me... Why would a server ever 
> use escapes in a Link header? (except in order to prove a point, that 
> is... :-)

The main reason someone would do that would be to subvert the kind of 
filtering/editing that I mentioned in my original message. Note that the RFC 
2068 syntax for relationships was not defined in terms of quoted-string.

> What I'm missing a bit in this discussion is the fact that the Link header 
> already is specified, deployed and supported by some UAs (such as Firefox 
> (*) and Opera AFAIK).
>
> Thus I'd really prefer to *extend* it in a backwards-compatible way (as 
> proposed by Mark N.) instead of inventing something new.

We should use the Link header field as defined in RFC 2068 for 
rel=stylesheet and rel=prefetch and whatever other uses web browsers already 
have for it. My point is that if an application has to choose between 
creating a new header field or using the Link field for some new kind of 
metadata, it should choose a new header field whenever it would be easier to 
parse (*correctly*) than the Link header field is.

Cheers,
Brian