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

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2008 17:39:05 +0200

Jamie Lokier wrote:
> ...
> How about:
> 
>     Generic-Link: URL=value
> 
> Which is required to be written in exactly that form, the URN denotes
> the relation type, and the URN is always unquoted, absolute, and in
> a canonical form.
> 
> It seems to satisfy the same easy parsing and substitution
> requirements that motivate foo-Link, while providing the flexibility
> of URNs for unregistered relation types.
> ...

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.

BR, Julian

(*) for instance: 
<http://developer.mozilla.org/en/docs/Link_prefetching_FAQ>

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2008 17:42:36 +0200

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

BR, Julian

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 5 May 2008 10:46:25 -0700

Julian Reschke wrote:

> Brian Smith wrote:
>> ...
>>>> 1. There is too much flexibility in the syntax of the "rel"  parameter. 
>>>> For
>>>> If you want to be able to catch all variations, then you have to  write 
>>>> a pretty nasty regular expression.
> 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).
>

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2008 21:14:58 +0200

Brian Smith wrote:
> 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?

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

---

From: Phil Archer <[email-masked]>
Date: Tue, 06 May 2008 12:38:09 +0100

Julian Reschke wrote:
[..]

> Firefox (*) and Opera AFAIK).

I decided to try and test this out. To which end I created a simple page 
at [1] that does not have an HTML link to a stylesheet but then 
configured the server to include such a link using HTTP.

The results show that IE and Firefox do not implement HTTP Link but that 
Opera 9 does. However... the link you give to the Firefox Link 
Pre-fetching FAQ is interesting.

It posits a single relationship type of 'prefetch' - simply a hint to 
the browser that it might be worth fetching whatever it points to 
because the page that's about to be parsed probably includes a link to 
it. Hmmm... that's not quite the same is it? It still needs the link 
within the HTML to actually use whatever it prefetched.

IMHO, that _is_ a case for Brian's suggestion of a specific header.

It fits the semantics of link in that it does point to a related 
resource, but the relationship type is stretched a little I think. 
Suppose that, for whatever reason, you prefer to use your own stylesheet 
  - the prefetch might have exactly the opposite of the desired effect - 
i.e. using bandwidth to fetch something irrelevant.

Meanwhile, by using rel="stylesheet", my HTTP Link header pointing to 
the stylesheet is ignored by Firefox.

 From a POWDER point of view it's important that links encoded within 
HTTP or HTML should be semantically identical and therefore present 
publishers with alternative ways of producing the same result - simply 
because not all publishers are the same.

> proposed by Mark N.) instead of inventing something new.

+1 to that.

Phil

[1] http://www.fosi.org/archive/httplinktest/

---

From: "Anne van Kesteren" <[email-masked]>
Date: Tue, 06 May 2008 12:42:21 +0100

> the stylesheet is ignored by Firefox.

Works fine for me:

   http://id.annevankesteren.nl/

-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 May 2008 13:51:41 +0200

> Pre-fetching FAQ is interesting.

Hm. You're sending:

Link: <styles.css>; /="/"; rel="stylesheet" type="text/css"; 
title="Style Sheet";

Shouldn't that be:

Link: <styles.css>; rel="stylesheet"; type="text/css"; title="Style Sheet";

?

BR, Julian

---

From: Phil Archer <[email-masked]>
Date: Tue, 06 May 2008 13:02:19 +0100

Sorry...

OK, I've removed the /="/" but but I still get the same results - 
Firefox doesn't recognise the stylesheet link.

So why does it work with Anne's page?

His header is

Link: <fancy.css>; rel=stylesheet

mine is now

Link: <styles.css>; rel="stylesheet" type="text/css"; title="Style Sheet";

So it looks like I should try removing the quotes around stylesheet, or 
may the type and title? ... whichever, the two implementations (Firefox 
and Opera) are not in alignment. C'ést la vie I guess.

Phil.

Julian Reschke wrote:
> Phil Archer wrote:
>> I decided to try and test this out. To which end I created a simple 
>> page at [1] that does not have an HTML link to a stylesheet but then 
>> The results show that IE and Firefox do not implement HTTP Link but 
>> that Opera 9 does. However... the link you give to the Firefox Link

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 May 2008 14:33:05 +0200

> and Opera) are not in alignment. C'ést la vie I guess.

There's still a ";" missing between rel= and type=.

BR, Julian

---

From: Phil Archer <[email-masked]>
Date: Tue, 06 May 2008 13:46:19 +0100

I can only apologise for my incompetence.

Thanks, Julian - it all works now, so the results are clearly that 
Firefox (2) and Opera (9) already implement HTTP Link (and that I need 
to be a lot more careful with my syntax).

Meanwhile, I'm working with Jonathan Rees to turn some of the material 
he's gathered at http://esw.w3.org/topic/FindingResourceDescriptions 
into a note to send to the TAG for possible discussion of this issue. 
Let's hope we can get it resolved...

Phil.

Julian Reschke wrote:
>> So it looks like I should try removing the quotes around stylesheet, 
>> or may the type and title? ... whichever, the two implementations 
>> (Firefox and Opera) are not in alignment. C'ést la vie I guess.
>

---

From: Martin Duerst <[email-masked]>
Date: Wed, 07 May 2008 16:07:46 +0900

Dear HTTP WG,

This was brought up in the LTRU WG by Mark Davis:

>Unfortunately, the specs are ill-defined regarding the q values. Take the >following example:
>
>a, b;q=0.7, c, d;q=0.5, e, f;q=0.9, g
>
>The specs do not distinguish between at least two different possible >reasonable interpretations of what the q values of c, e, and g are: 
    * >   c;q=1.0, e;q=1.0, g;q=1 // always 1 
    * >   c;q=0.7, e;q=0.5, g;q=0.9 // always same as previous 
> Our guess is that the user meant #2, but it is only a guess.

I read RFC 2616, and indeed didn't find any specification of
the defaults for q values in the case of Accept-Language.

Looking at other subsections of Section 14, there is an explicit
default of q=1 for Accept and Accept-Charset, but I also didn't
find a default for Accept-Encoding.

Please add this issue to your issue list unless you already
have it listed.

Regards,   Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 07 May 2008 19:43:51 +1200

> the defaults for q values in the case of Accept-Language.
take another look at section 14.4, para 2.

"Each language-range MAY be given an associated quality value which 
represents an estimate of the user's preference for the languages 
specified by that range. The quality value defaults to "q=1". For example"

> Please add this issue to your issue list unless you already

also the whole concept of q values only makes any sense if the default 
value is 1.

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

---

From: Julian Reschke <[email-masked]>
Date: Wed, 07 May 2008 13:49:21 +0200

> also the whole concept of q values only makes any sense if the default 

I'd recommend that we state the default just once in the section that 
introduces qvalues 
(<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p3-payload-latest.html#rfc.section.3.4>) 
and remove the description everywhere else.

BR, Julian

---

From: Martin Duerst <[email-masked]>
Date: Wed, 07 May 2008 19:36:06 +0900

Dear HTTP WG,

Please accept my appology for the double confusion:
- Sending out the same change request just a few hours after Mark.
- Not being able to find the text about the default value
  despite reading that subsection several times.

Regards,    Martin.

At 16:07 08/05/07, Martin Duerst wrote:
>>Unfortunately, the specs are ill-defined regarding the q values. Take the 
>>following example:
>>
>>The specs do not distinguish between at least two different possible 
>>reasonable interpretations of what the q values of c, e, and g are: