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: Fri, 25 Sep 2009 10:22:55 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <0EA81A4E-47DF-46B4-97F1-EA005B538771@mnot.net>
To: Ian Hickson <ian@hixie.ch>

On 24/09/2009, at 7:34 PM, Ian Hickson wrote:
>>
>> 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'm not talking about one rel value, I'm talking about one  
> attribute, of
> any of the attributes. One "hreflang", one "media", one "type", etc.

and I said "attribute." See subsequent proposals.


>>>>> Why should HTML5 define how rel=stylesheet of a CSS file applies
>>>>> to an XML document? That doesn't sound right at all.
>>>>
>>>> My understanding was that HTML5 is not only defining the HTML
>>>> syntax, but also the model for what a "web browser" is and does; if
>>>> that's the case, it's one place to put it.
>>>
>>> That is not the case. HTML5 defines HTML, and how all classes of  
>>> HTML
>>> processors, whether search engines, editors, or anything else, are  
>>> to
>>> process HTML.
>>>
>>> It does not define how an XML+CSS processor is to handle an HTTP
>>> header.
>>
>> OK. The point is that some XML+CSS spec needs to define this  
>> behaviour.
>
> I don't see why an XML spec or a CSS spec or even an XML+CSS spec  
> would
> define the behaviour of an HTTP header. Surely the spec for the HTTP
> header would be the one to define the behaviour of the HTTP header.

It's not defining the relation of an HTTP header, Ian; it's defining  
the semantics of a link relation when used with XML and CSS.


>>>>> Regardless of who manages the registry, I would like to request
>>>>> that the registration mechanism be made significantly simpler than
>>>>> the one described in the spec.
>>>>
>>>> Do you have concrete suggestions for the IANA process to be used?
>>>
>>> I would suggest that the IANA host a wiki that anyone can edit.
>>
>> The point of having a registry is to act as a gateway, to assure
>> appropriate review and coordination. Allowing anyone to edit the
>> contents removes these benefits; people wanting to mint new relations
>> without coordination or even review can do so by using extension
>> relations.
>
> People will and do mint keywords without coordinating with us or  
> asking
> for our review.
>
> Our choice is just whether we want them to register these keywords  
> first,
> or whether we want them to not register them first.
>
> Whether they register them will depend on whether we make it easy or  
> not.
>
> I'm not making any judgements about whether this behaviour is  
> desireable,
> good, bad, or the right way to do things. It's just how things are.
> Ignoring it is just going to make the registry irrelevant in practice.

Of course they will do this; the draft already takes the stance that  
unrecognised (i.e., not in the registry, or not implemented by the  
app) relation types have purely localised meaning; i.e., they may mean  
something in a particular context, but all bets are off beyond that.

Allowing people to register up-front without any review or  
coordination allows people to register without forethought, leading to  
very fuzzy semantics and interoperability problems -- ultimately  
causing more problems than it solves. We're already seeing this with  
the Atom relations registry.

Early experience with reviewing relations (e.g., "hub") is also  
promising; developers have expressed a willingness to work with the  
community to do the right thing, and we've been able to find ways to  
meet their requirements while still assuring that the relations are  
well-defined and fit into the link framework.


> Also, it's worth noting that the HTML5 RelExtensions registry today  
> is a
> wiki. That registry allows people to register arbitrary keywords. If  
> we
> want that registry to be a subset of the registry you are defining,  
> then
> it needs to be as easy (or easier) to register things in the  
> registry you
> are defining as in the RelExtensions wiki. Otherwise, people will  
> register
> keywords for HTML's rel="" attribute, since doing so is trivial, but  
> will
> not bother to register them in the "higher level" registry, because  
> doing
> so will be more work than they want to do.
>
> If this happens, then either the goal of preventing clashes between  
> HTML
> and Atom won't have been met (at least, not by the registry with the  
> more
> onerous registration requirements).

Yes, but that seems like a problem completely of your own creation, Ian.



> On Mon, 21 Sep 2009, Mark Nottingham wrote:
>>
>> 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?
>
> I couldn't find the updated I-D on tools.ietf.org; is this the version
> with this fix?:
>
>   http://tools.ietf.org/html/draft-nottingham-http-link-header-06

No, I haven't updated the I-D yet, since it's in last call. See:
   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt
with diff at:
   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html


> In general, if the attributes can each only be listed once, and the  
> spec
> says how to handle (e.g. ignore) duplicates, then my concern is  
> addressed.

OK.


> 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?
>
> Seems reasonable, though I am still skeptical as to the use of the  
> title*
> feature in practice. It seems better to me to just have one title
> attribute, in one language, and to upgrade HTTP to support UTF-8 in
> headers.

That's already been discussed extensively, and that's not the  
direction things are going in (certainly for pre-existing headers like  
Link).

Cheers,

--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 25 September 2009 00:23:48 GMT

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