W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 21 Sep 2009 18:17:25 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <2F4E6428-35B2-493C-83A1-DF52DC13E920@mnot.net>
To: Ian Hickson <ian@hixie.ch>

On 17/09/2009, at 3:14 PM, Mark Nottingham wrote:

>
> On 16/09/2009, at 5:44 PM, Ian Hickson wrote:
>>
>>>> Given that HTML and Atom only allow one of each attribute, I think
>>>> we're far less likely to have bugs if we say that all but the first
>>>> occurrance of each attribute is just ignored.
>>>
>>> That's an artefact of their syntax (SGML and XML-based,  
>>> respectively);
>>> do you expect people to use the same parsers?
>>
>> I expect implementations to use the same internal APIs, and those  
>> APIs are
>> designed with the expectation of a single value for each attribute.  
>> For
>> example, look for nsContentSink::ProcessLink() in the Mozilla  
>> codebase.
>
> You're proving my point; Mozilla has  
> nsContentSink::ProcessLinkHeader, which calls  
> nsStyleLinkElement::ParseLinkTypes() (as does ProcessLink()).
>
> That code does happen to only allow one rel value, but that's a bug,  
> as the current specification of the Link header in RFC2068 and  
> earlier clearly allow multiple rel attributes, and fixing it is a  
> matter of a line or two.
>
> Nevertheless -- how do other people feel about restricting to one  
> rel attribute in the Link header? Looking back at 2068, the BNF  
> implicitly allows multiple rel values, but it isn't explicitly  
> addressed in the prose, so Ian does have a point -- you could see it  
> either way.

I've just added:

The "rel" parameter MUST NOT appear more than once in a given link- 
value; occurrences after the first MUST be ignored by parsers.

and adjusted the examples to suit. Does that address your concern?


>>> As far as how it works in UI -- present the most appropriate title  
>>> based
>>> upon the users preferences.
>>
>> Could you give a concrete example of a Link: header that uses  
>> multiple
>> titles in this way and describe what you think the ideal UI for that
>> example would be?
>
>   Link: </TheBook/chapter6>; rel="last"; title*=UTF-8'de'letztes 
> %20Kapitel; title*=UTF-8'en'final%20chapter
>
> One example of a UI -- if it chooses to use the title instead of the  
> URL for displaying the link (e.g., in a toolbar dedicated to showing  
> links) would use the first title* if the users configured language  
> was German, and the second if it were English.

I've just changed the 'title'-related text to:

The "title" parameter, when present, is used to label the destination  
of a link such that it can be used as a
human-readable identifier (e.g. a menu entry). The "title" parameter  
MUST NOT appear more than once in a given link-value;
occurrences after the first MUST be ignored by parsers.

The "title*" parameter MAY be used encode this label in a different  
character set, and/or contain language information as per
<xref target="RFC2231"/>. When using the enc2231-string syntax,  
producers MUST NOT use a charset value other than 'ISO-8859-1'
or 'UTF-8'. The "title*" parameter MAY appear more than once in a  
given link-value, but each occurrence MUST indicate a
different language; occurrences after the first for a given language  
MUST be ignored by parsers.

When presenting links to users, agents SHOULD use the most appropriate  
"title*" value, according to user preferences. If
an appropriate "title*" value cannot be found, the "title" parameter's  
value, if available, can be used.

Does this work?


--
Mark Nottingham     http://www.mnot.net/
Received on Monday, 21 September 2009 08:18:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:10 GMT