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

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

As a matter of fact, it isn't in Mark's draft either:

<http://tools.ietf.org/html/draft-nottingham-http-link-header-01#section-3>:

        Link           = "Link" ":" #("<" URI-Reference ">"
                       *( ";" link-param ) )

        link-param     = ( ( "rel" "=" relationship )
                       | ( "rev" "=" relationship )
                       | ( "title" "=" quoted-string )
                       | ( link-extension ) )

        link-extension = token [ "=" ( token | quoted-string ) ]

        relationship   = URI-Reference |
                       <"> URI-Reference *( SP URI-Reference) <"> )


So what was the problem?

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

I agree that in some cases, a new header makes more sense.

That being said, I don't see (yet) the parsing issue.

Also, a new header would be something that wouldn't be expressible in 
HTML or Atom link elements...

BR, Julian

Received on Monday, 5 May 2008 19:15:47 UTC