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

From: Joe Gregorio <[email-masked]>
Date: Tue, 1 Sep 2009 10:30:29 -0400

On Mon, Aug 31, 2009 at 10:38 PM, Mark Nottingham <[email-masked]> wrote:

>
> On 31/08/2009, at 11:42 PM, Joe Gregorio wrote:
>
>  Regardless, I don't believe a flat registry with one document per rel type
>> is going
>> to be sufficient. There should be a mechanism within the registry to
>> specify per-media-type
>> 'clarifications' for each rel type. This is particularly important in the
>> case of new
>> formats that come along later, like JSON has in the past couple years,
>> that
>> weren't around when a rel value was registered.
>>
>
> I strongly disagree; the whole point of registered relations is that their
> semantics are independent of format. While there are certainly
> format-specific considerations for each, that can be handled in the world of
> that format (whether it's in a huge, monolithic spec, or something more
> agile).

Right, I'm just looking for the ability to add a link from the registry to
that 'huge, monolithic spec'.

   Thanks,
   -joe

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 16 Sep 2009 15:38:07 +1000

On 30/08/2009, at 12:23 PM, Ian Hickson wrote:

> On Thu, 20 Aug 2009, Mark Nottingham wrote:
>> On 31/07/2009, at 10:20 AM, Ian Hickson wrote:
>>>
>>> Comparing relation types case-sensitively (e.g. as in 4.2 Extension
>>> Relation Types) is incompatible with HTML's processing of rel=""; I
>>> would like to request that all relations always be case-insensitive.
>>
>> Is that specific to HTML5? How does HTML5 process rel?
>
> All versions of HTML have been case-insensitive throughout their  
> rel=""
> procesing, as far as I can tell.

How do other people feel about changing extension relation types to be  
compared case-insensitively? It's certainly weird to compare URIs in  
this fashion, but AFAICT this won't break anything as long as authors  
are aware of it.

>>> I think for the best compatibility with legacy implementations, the
>>> spec should say that there must only be one occurance of each
>>> attribute, and that multiple link types in one Link: header should  
>>> be
>>> listed in one rel="" attribute. (That is, only allow rel="a b", not
>>> rel=a;rel=b.)
>>
>> Do you have data to back this up?
>
> As far as I can tell, Mozilla only supports one of each attribute. Are
> there UAs that support more?

How did you test that?

> 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'm concerned that this would disallow internationalisation of title,
>> for example (e.g., you couldn't express both an english and a spanish
>> title for a link).
>
> That sounds like one of those things that looks good on paper but  
> doesn't
> really ever translate to implementations. Are we really expecting  
> authors
> to provide multiple titles per link? How would that work in UI?

I think Julian covered why it's necessary to have this.

As far as how it works in UI -- present the most appropriate title  
based upon the users preferences.

>>> I would like to request that each link type be defined as either  
>>> being
>>> a hyperlink or an external resource link, as defined in HTML5, and
>>> that this be added as one of the things that must be defined in the
>>> registry.
>>
>> I'm not sure what an "external resource link" is, could you please
>> remind me?
>
> When you mirror a page ("Save As ... Complete" or "Save As ...  
> Archive"),
> external resource links are those that are fetched and included with  
> the
> source document, whereas hyperlinks are those that are considered to  
> be
> separate.
>
> A style sheet, for instance, is an external resource link. A regular  
> <a
> href=""> is just a hyperlink.

Ah, thank you.

There are many such aspects; e.g., to other applications, it's  
important to know whether spiders should follow a link.

Rather than trying to record all of these different facets in the  
registry, it would be better if there was one place for it that  
defined that application -- whether it's "saving an archive of a Web  
page" or "spidering a resource," with references to registered and  
unregistered relations as necessary.

>>> Similarly, the registry should define whether or not link relations
>>> are allowed at the document level (<link rel>, Link:) and at the
>>> phrasing level (<a rel>, <area rel>). Some types in HTML5 only apply
>>> to one or the other.
>>
>> That's a job for HTML5 as an application of the relations, not the
>> registry.
>
> So every time someone adds something to the registry, we have to  
> update
> HTML5 to say whether that keyword can be used with HTML?

What I imagine will happen is that if someone wants to specify a new  
relation that has an effect on browsers, they'll write a specification  
for it and define the new relation, as well as any considerations for  
a particular application (e.g., web browsing) that it implies. Whether  
that "updates" HTML5 depends on how you structure the spec, allow  
extensibility, etc.

At any rate, doesn't HTML5 already define what to do when a relation  
type with unrecognised or inapplicable semantics is encountered? If  
so, that should cover this.

>>> Ideally, I would like the Link: header section to more clearly  
>>> define
>>> how some of the keywords defined in the spec should actually be  
>>> used.
>>> For example, how should the rel=stylesheet keyword affect the CSSOM?
>>> Where do resources imported in this way fall in the CSS cascade? How
>>> should it affect documents with MIME types like text/plain? Do
>>> rel=icon links interact with those specified in the document? If so,
>>> where should they be considered as falling in terms of tree order?
>>
>> Again, a job for HTML5.
>
> 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.

Alternatively, the CSS spec itself (or an adjunct to it, since it's  
already out there) could explain its applicability (when the type is  
text/css, of course).

It doesn't make any sense to put it in the Link header section,  
because HTTP headers have nothing to do with the specific application  
or ANY of the media types here.

> It's the linking mechanism, in this case the Link: header, that should
> define how it works, just like how HTML5 defines how <html:link>  
> works in
> XML, or how the XML Style Sheet PI spec defines how <?xml-stylesheet>
> works in XML.

This leads to a situation where every time someone comes up with a new  
application of linking, they have to update Atom, HTML, the Link spec  
and whatever other serialisations are defined; that seems unworkable  
for a variety of reasons (multiple processes, document updates, etc.).

>>> I would like to request that the registration mechanism be made
>>> significantly simpler than the one described in the spec. For  
>>> example,
>>> a simple mechanism could be just to edit a wiki listing all the
>>> extensions.
>>
>> In the IETF, IANA is the mechanism for managing registries like this.
>
> 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 like to request some guidance on what HTML5 would have to do
>>> to be compatible with this draft, and what benefits would come from
>>> it. There are clear benefits to the Link: header section, assuming
>>> that how it fits into the general Web platform is defined (as
>>> requested above). But how does the registry fit into the  
>>> RelExtensions
>>> registry for HTML5? How should they interact?
>>
>> If HTML5 chooses to adopt this framework, it would need to:
>>  1) Define the syntax for serialising and parsing links in HTML5,  
>> using the
>> terms defined in the draft (see Appendix C), and
>
> Does what HTML5 already says on the matter satisfy this?
>  2) Associate concrete behaviours with the general semantics of the
>> registered link relations it finds interesting, and
>
> I don't understand how we can do that since most of the link relations
> that people will want to use with HTML5 haven't even been thought of  
> yet.
>  3) Define how undefined / unrecognised relations are to be handled  
> (with a
>> heavy bias towards must-ignore), and
>
> Ok.
>
>>  4) Optionally, define additional registered and/or extension link  
>> relations.
>
> Ok. Is what HTML5 already has for this adequate?

I'll address these in a separate e-mail, as I've already taken long  
enough to answer this, and it will take some digging to come up with  
helpful suggestions.

>>> The "up", "first", "last", and "payment" types are woefully
>>> underdefined. What is the expected UA behaviour when discovering a
>>> link with rel=payment? What are the authoring requirements? What are
>>> the implementation requirements?
>>
>> I'd agree that "payment" is ill-defined, but most of the questions  
>> you
>> ask need to be answered (once again) in the context of a particular
>> application of linking, not by the registry.
>
> So how rel=payment works will differ for Atom and for HTML?

No. As far as it goes, it doesn't work at all at the moment, AIUI;  
i.e., a UA is free to ignore the relation type and treat it link any  
other link (which is as it should be). I'm not sure what the automated  
cases for it are.

> It seems pointless to have a registry at all, if the behaviours are  
> scoped
> to each use of the term, rather than being related to the term.

People will want to do different things with relations like "prev,"  
"index" and "alternate"; not all link relations are purely functional  
(indeed, most should not be) and there will be unintended reuse of  
them for things we can't foresee.

Take, for example, the "duplicate" relation type currently being  
discussed; while it's immediately useful for MetaLink, there are many  
other potential uses for it, and the client behaviour with each is  
potentially different.

BTW, I was wandering through <http://www.w3.org/TR/html5/history.html#linkTypes 
 > and found "sidebar." Why use a link relation type here when the  
target attribute is already available?

--
Mark Nottingham     http://www.mnot.net/

---

From: Ian Hickson <[email-masked]>
Date: Wed, 16 Sep 2009 07:44:17 +0000 (UTC)

On Wed, 16 Sep 2009, Mark Nottingham wrote:
> > > > I think for the best compatibility with legacy implementations, 
> > > > the spec should say that there must only be one occurance of each 
> > > > be listed in one rel="" attribute. (That is, only allow rel="a b", 
> > > > not rel=a;rel=b.)
> > > 

http://www.hixie.ch/tests/adhoc/http/link/009.html

Opera also only supports one of each attribute.

> > we're far less likely to have bugs if we say that all but the first 
> > occurrance of each attribute is just ignored.
> 

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.

> > > I'm concerned that this would disallow internationalisation of 
> > > title, for example (e.g., you couldn't express both an english and a 
> > > spanish title for a link).
> > 
> > doesn't really ever translate to implementations. Are we really 
> > expecting authors to provide multiple titles per link? How would that 
> > work in UI?
> 

Do you mean here?:

   http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0634.html

If so, I do not find his reasoning convincing.

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

I continue to fear that this feature will not ever be properly 
implemented.

> [snip various answers saying that various things shouldn't be registered 
> in the registry but that each registered link type should have a 
> corresponding specification that defines how the link type works in all 
> the situations that might support it]

I think this basically makes the registry worthless. At least for HTML5, 
there are several aspects that we need to have in a machine-readable 
fashion for each link type, including:

 - whether the link type is allowed on <link>
 - whether the link type is allowed on <a> and <area>
 - whether the link type is a hyperlink or references an external resource

If the link registry isn't going to be providing this, then it's not 
really solving the problems for which HTML5 needs a registry.

I guess to avoid name clashes the HTML5 link registry can require that the 
link type be registered with your registry and that the semantics defined 
for HTML5 be consistent with those referenced by the specification given 
in the registry.

> > Why should HTML5 define how rel=stylesheet of a CSS file applies to an 
> > XML document? That doesn't sound right at all.
> 

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.

> > define how it works, just like how HTML5 defines how <html:link> works 
> > in XML, or how the XML Style Sheet PI spec defines how 
> > <?xml-stylesheet> works in XML.
> 
> and whatever other serialisations are defined; that seems unworkable for 
> a variety of reasons (multiple processes, document updates, etc.).

If someone comes up with a new way to link a style sheet to a document, 
then yes, I expect them to define how this works with the technologies 
that they have then affected.

> > > > example, a simple mechanism could be just to edit a wiki listing 
> > > > all the extensions.
> > > 
> > the registration mechanism be made significantly simpler than the one 
> > described in the spec.
> 

I would suggest that the IANA host a wiki that anyone can edit.

> > > > link with rel=payment? What are the authoring requirements? What 
> > > > are the implementation requirements?
> > > 
> > > you ask need to be answered (once again) in the context of a 
> > > particular application of linking, not by the registry.
> > 
> No. As far as it goes, it doesn't work at all at the moment, AIUI; i.e., 
> a UA is free to ignore the relation type and treat it link any other 
> link (which is as it should be). I'm not sure what the automated cases 
> for it are.

Does it not have a specification that defines this?

> > scoped to each use of the term, rather than being related to the term.
> 
> (indeed, most should not be) and there will be unintended reuse of them 
> for things we can't foresee.

I don't think there's much point having a single registry then. We should 
just have different registries for each linking mechanism, if that's going 
to be the practical scope of the registry anyway.

> other potential uses for it, and the client behaviour with each is 

What happens when it's defined one way for Atom, and another way for HTML, 
and then each group wants to extend their processing to HTTP linking when 
used with SVG?

> BTW, I was wandering through 
> <http://www.w3.org/TR/html5/history.html#linkTypes> and found "sidebar." 
> Why use a link relation type here when the target attribute is already 
> available?

The target="" attribute would create a new window instead of gracefully 
falling back to using the current window like rel="".

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Sam Johnston <[email-masked]>
Date: Wed, 16 Sep 2009 11:32:04 +0200

> for HTML5 be consistent with those referenced by the specification given

Right, as I see it specifications should define concrete relations either
with reference to existing generic relations or by specifying new ones. HTML
does not yet do this if I understand well, but it would be a simple change
to add an IANA petition.

For example, I was looking for a relation to describe the "most recent
version" of a resource (as distinct from a specific version in a VCS). I'd
have used "current" were it not for its definition in RFC 5005 as "a feed
document containing the most recent entries in the feed" (for which 'recent'
would have been a better term IMO). Now I need to either try to shift the
existing definition or find another like 'latest' - without regard to the
registry we'd have ended up with two conflicting definitions.

> I would suggest that the IANA host a wiki that anyone can edit.

Agreed, a generic version of the
RelExtensions<http://wiki.whatwg.org/wiki/RelExtensions>wiki page
would be perfect.

> Does it not have a specification that defines this?

The existing definition as "a resource where payment is accepted" seems
adequate to me - in a UI a prefabricated link to PayPal would suffice but
for automated mechanisms there will presumably be some competition, with
each having its own content type.

> to be the practical scope of the registry anyway.

There are applications which meed to span multiple formats - for example
OCCI has Atom and XHTML renderings and it would be intensely confusing if
there were different relations for the same LINK element depending on the
format (not to mention if these were conflicting!).

I see Mark's proposal as a great way to achieve inter-format
interoperability - something which will be increasingly important as we move
forward.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 11:54:57 +0200

Sam Johnston wrote:
> ...
> version" of a resource (as distinct from a specific version in a VCS). 
> I'd have used "current" were it not for its definition in RFC 5005 as "a 
> feed document containing the most recent entries in the feed" (for which 
> 'recent' would have been a better term IMO). Now I need to either try to 
> shift the existing definition or find another like 'latest' - without 
> regard to the registry we'd have ended up with two conflicting definitions.
> ...

<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html>

 > ...

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 16 Sep 2009 12:30:54 +0200

> Opera also only supports one of each attribute.

The current two implementations are buggy anway. I don't think it makes 
sense to restrict the header syntax to what Mozilla and Opera came up 
with in terms of support.

It's clear that bug-fixing, test cases and more implementations are 
needed; if this occurs there's no reason to kill these bugs in Mozilla 
and Opera as well.

> If so, I do not find his reasoning convincing.

I didn't "reason", I just stated how to deal with this case in UAs: "The 
UI would select the language best suited for the user."

What part of this didn't convince you? Are you saying that UAs are 
incapable of matching language tags?

> really solving the problems for which HTML5 needs a registry.

1) I note that HTML 5 doesn't have a proposal for this either.

2) What's the use case for this being machine-readable? Are you 
suggesting that implementations would look this up anytime they need it? 
  How is this supposed to scale?

 > ..

Then having a single registry with a well-documented registration 
procedure will be useful (as opposed to a Wiki).

BR, Julian

---

From: Sam Johnston <[email-masked]>
Date: Wed, 16 Sep 2009 12:54:31 +0200

On Wed, Sep 16, 2009 at 11:54 AM, Julian Reschke <[email-masked]>wrote:

> <
> http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html
> >
>

Thanks Julian - glad to see progress being made on this front. It doesn't
solve my main grievance (that being URL shorteners eroding the web at an
increasingly rapid rate) but it does deal with some useful use cases...
here's hoping browser back buttons morph into 4-way joysticks before long
and who doesn't think browsing versioned web pages with a time machine style
interface would be cool? :)

While we're at it here's some feedback for the authors (copied):

   - 'version-history' could safely be shortened to 'history' (and should
   IMO)
   - 'latest-version' could become 'latest' or the existing 'current' could
   be commandeered if the existing definition is deemed close enough.
   - 'working-copy' seems a little too specific and I'm not sure I grok the
   use case(s)... perhaps something like 'local' or 'replica' would be better?
   - 'predecessor-version' should be 'prev-version' in line with HTML's
   definition of 'prev' and RFC 5005's definition of 'prev-archive' - may as
   well keep the link relations coherent.
   - 'successor-version' should similarly be 'next-version'.

A word on 'prev' vs 'previous': HTML 4
defines<http://www.w3.org/TR/html401/types.html#type-links>'prev' but
concedes that some UAs accept 'previous' as a synonym while HTML
5 effectively obsoletes
<http://www.w3.org/TR/html5/history.html#linkTypes>'previous' by not
mentioning it. RFC 5005 further confuses things by
defining <http://tools.ietf.org/html/rfc5005#section-3> 'previous' only to
go on and define
<http://tools.ietf.org/html/rfc5005#section-4>'prev-archive'. Which is
it? draft-nottingham-http-link-header-06 currently
expresses no preference but it arguably should as servers should send one or
the other even if clients accept both.

Sam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 16:20:31 -0700

> -----Original Message-----
> From: Sam Johnston [mailto:[email-masked]]
> Sent: Wednesday, September 16, 2009 2:32 AM

> I'd have used "current" were it not for its definition in RFC 5005 as
> "a feed document containing the most recent entries in the feed" (for
> which 'recent' would have been a better term IMO). Now I need to either
> try to shift the existing definition or find another like 'latest' -
> without regard to the registry we'd have ended up with two conflicting
> definitions.

This should not be a problem with the proposed registry. Since it will require more generic definitions that focus on the semantic meaning of the relation type rather than the specifics of the implementations using it, it will allow a consistent meaning with implementation details left to each protocol where it is used. It should also put more review on defining general purpose (short name) relation types when protocols are free to define URI based extension types.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 16:59:35 -0700

> From: Ian Hickson [mailto:[email-masked]]
> Sent: Wednesday, September 16, 2009 12:44 AM

>  - whether the link type is a hyperlink or references an external

Why?

The whole point of relation types is that if you see one you don't understand you simply ignore it. It is perfectly reasonable to define a required set so that clients get consistent results using a baseline. But to try and enforce the introduction of new relation types like they were an XML schema goes against the very nature of the mechanism. It's like requiring <A> links to have "value" and be "relevant".

> really solving the problems for which HTML5 needs a registry.

It gives HTML5 a consistent semantic meaning without imposing rules on how you utilize that relation. It ensures that developers using multiple technologies don't have to use the same relation type with different semantic meaning which causes mistakes and abuse. Machines don't care about whether a relation type is an English word or a binary array. People do. And it would be a significant improvement it we could have a single registry to define what is the meaning / intention of this short relation type.

For example, I have been using the relation type 'describedby' a lot recently. It has different processing rules for LRDD, XRD, POWDER, etc. But it *means* the same thing. LRDD and POWDER both use this relation type in HTTP headers, but it is the context of the application and not the transport that dictates its meaning. If an application needs something more precise and would like to enforce more rules on it (such as cardinality), it should define an extension URI relation type.
 
> for HTML5 be consistent with those referenced by the specification given

This would be the right way to handle this. In the future, if many technologies will find it useful to define such custom registries for their own processing rules of relation types, it might make sense to enhance the common registry to hold such information. But given the very different styles of managing such registries (IANA vs. wiki, etc.), it will probably be hard to find a common way to record the information and keep all these different communities happy.

> I would suggest that the IANA host a wiki that anyone can edit.

That is a horrible idea.

The registration and semantic meaning of common terms for relation types should be based on wide consensus and not random whims of individuals changing a wiki. We are talking about cross-protocol cross-community registry to establish common basic terminology. Making it lightweight is really not a priority.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 16 Sep 2009 17:01:47 -0700

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Tuesday, September 15, 2009 10:38 PM
> 

Works for me.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 17 Sep 2009 15:14:18 +1000

> example, look for nsContentSink::ProcessLink() in the Mozilla  

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.

> titles in this way and describe what you think the ideal UI for that

    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.

> really solving the problems for which HTML5 needs a registry.

Just so I understand, a straw-man use case: if I wanted to define a  
HTML5 extension that modified the page by fetching chunks, implemented  
in JS (e.g., something functionally similar to <http://www.mnot.net/javascript/hinclude/ 
 >), I could register a relation type for those links that included  
the fact that they're external resources, so that browsers would  
automagically download them as well when a user does "save as"?

If that's in-scope, I guess it's nice-to-have, but it seems like a lot  
of trouble. Won't most such extensions actually require browser  
changes, thus reducing the value of having this information machine- 
readable? Do you intend for this machine-readable information to be  
used at compile time, or runtime?

Also, what's the value of having the information about where a link is  
allowed machine-readable? Won't it simply be ignored if it's not  
understood and in a valid place?

> for HTML5 be consistent with those referenced by the specification  

Yes, that's one approach that could be taken.

> It does not define how an XML+CSS processor is to handle an HTTP  

OK. The point is that some XML+CSS spec needs to define this behaviour.

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

>> i.e.,

It doesn't, because the Atom registry policy is first-come-first- 
serve; i.e., it operates like a wiki, where anyone can put something  
into it, without review / appropriate levels of documentation / etc.

> and then each group wants to extend their processing to HTTP linking  

Why do you want to constrain implementations of even one of these  
formats to treat "duplicate" in the same way (much less across  
formats)? All the link relation is doing in this case is indicating  
that the linked resource has certain attributes (sharing  
representations with the context IRI); there is no "right" behaviour  
in handling this, and its presence doesn't imply that the client has  
to implement any particular behaviour, handling or protocol.

> falling back to using the current window like rel="".

Given that the intent of a sidebar is to open it in a different pane  
without replacing the current content, is that a bad thing?

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 21 Sep 2009 18:17:25 +1000

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

> You're proving my point; Mozilla has  
> nsContentSink::ProcessLinkHeader, which calls  
> nsStyleLinkElement::ParseLinkTypes() (as does ProcessLink()).
>
> 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?

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

---

From: Sam Johnston <[email-masked]>
Date: Mon, 21 Sep 2009 13:43:58 +0200

On Mon, Sep 21, 2009 at 10:17 AM, Mark Nottingham <[email-masked]> wrote:

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

Looks good.

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

While this may or may not always be the case for Atom, for HTTP and HTML the
document is subject to the usual HTTP conneg, which includes languages. If
you're retrieving the document itself in French then presumably you want the
title (including non-ASCII characters) in French too. I've said this before
but I still don't grok [from the document] why both are required.

Sam

---

From: Julian Reschke <[email-masked]>
Date: Mon, 21 Sep 2009 14:13:30 +0200

Sam Johnston wrote:
> ...
> While this may or may not always be the case for Atom, for HTTP and HTML 
> the document is subject to the usual HTTP conneg, which includes 
> languages. If you're retrieving the document itself in French then 
> presumably you want the title (including non-ASCII characters) in French 
> too. I've said this before but I still don't grok [from the document] 
> why both are required.
> ...

This has nothing to do with Atom vs HTML, or HTTP.

A resource can support language based conneg, in which case the link 
header *likely* will just use a single title attribute.

But just because that is possible doesn't mean that the header format 
can not also support other use cases.

It's truly optional.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Tue, 22 Sep 2009 23:36:02 +0000 (UTC)

On Wed, 16 Sep 2009, Eran Hammer-Lahav wrote:
> > 
> > I think this basically makes the registry worthless. At least for 
> > HTML5, there are several aspects that we need to have in a 
> > machine-readable fashion for each link type, including:
> > 
> The whole point of relation types is that if you see one you don't 
> understand you simply ignore it. It is perfectly reasonable to define a 
> required set so that clients get consistent results using a baseline. 
> But to try and enforce the introduction of new relation types like they 
> were an XML schema goes against the very nature of the mechanism. It's 
> like requiring <A> links to have "value" and be "relevant".

Whether the link type is allowed in the various places in HTML that take 
link types is necessary because otherwise the validator can't say whether 
the link type is being used correctly.

Whether the link type is a hyperlink or references an external resource is 
necessary so that UAs (like wget) can automatically support "save as whole 
page"-like functionality even in the face of relationships they don't 
support. (For example, it would mean wget doesn't need to be revved each 
time browser vendors come up with a new way to hook resource to a 
document, as they did with rel=icon, for instance; it could just update 
itself from the registry).

> It gives HTML5 a consistent semantic meaning without imposing rules on 
> how you utilize that relation. It ensures that developers using multiple 
> technologies don't have to use the same relation type with different 
> semantic meaning which causes mistakes and abuse. Machines don't care 
> about whether a relation type is an English word or a binary array.
> People do. And it would be a significant improvement it we could have a 
> single registry to define what is the meaning / intention of this short 
> relation type.

Those are fine goals, but they're not the goals that led to us creating a 
registry for HTML5.

> For example, I have been using the relation type 'describedby' a lot 
> recently. It has different processing rules for LRDD, XRD, POWDER, etc. 
> But it *means* the same thing.

That seems like two contradictory statements. Surely the meaning of a 
relationship is the processing rules it requires. What else could a link 
type mean?

> > link type be registered with your registry and that the semantics 
> > defined for HTML5 be consistent with those referenced by the 
> > specification given in the registry.
> 
> This would be the right way to handle this. In the future, if many 
> technologies will find it useful to define such custom registries for 
> their own processing rules of relation types, it might make sense to 
> enhance the common registry to hold such information. But given the very 
> different styles of managing such registries (IANA vs. wiki, etc.), it 
> will probably be hard to find a common way to record the information and 
> keep all these different communities happy.

Ok.

> The registration and semantic meaning of common terms for relation types 
> should be based on wide consensus and not random whims of individuals 
> changing a wiki. We are talking about cross-protocol cross-community 
> registry to establish common basic terminology. Making it lightweight is 
> really not a priority.

If it's harder to register a link type in this registry than in HTML5's, 
then HTML5's will end up a superset, and we will have failed to accomplish 
the goal of avoiding clashes.

---

From: Ian Hickson <[email-masked]>
Date: Thu, 24 Sep 2009 09:34:19 +0000 (UTC)

On Thu, 17 Sep 2009, Mark Nottingham wrote:
> > > > 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.
> 
> 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 

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.

> would use the first title* if the users configured language was German, 
> and the second if it were English.

I am skeptical that this will ever be implemented in widely deployed 
consumer software, but ok.

> > [snip various answers saying that various things shouldn't be 
> > registered in the registry but that each registered link type should 
> > have a corresponding specification that defines how the link type 
> > works in all the situations that might support it]
> > 
> in JS (e.g., something functionally similar to 
> <http://www.mnot.net/javascript/hinclude/>), I could register a relation 
> type for those links that included the fact that they're external 
> resources, so that browsers would automagically download them as well 
> when a user does "save as"?

Right.

> of trouble. Won't most such extensions actually require browser changes, 
> thus reducing the value of having this information machine-readable? Do 
> you intend for this machine-readable information to be used at compile 
> time, or runtime?

A tool like 'wget' could automatically support things like <link 
rel=stylesheet>, <link rel=icon>, and whatever other such extensions 
browser vendors come up with, without having to ship new releases, if it 
could update its behaviour based on the registry.

> understood and in a valid place?

An HTTP and HTML validator could automatically keep up to date with what 
keywords it should allow on <link>, <a>, <area>, and in Link: headers, if 
the registry included information about where such keywords were allowed.

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

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.

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

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.

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

> > > <http://www.w3.org/TR/html5/history.html#linkTypes> and found 
> > > "sidebar." Why use a link relation type here when the target 
> > > attribute is already available?
> > 
> > The target="" attribute would create a new window instead of 
> > gracefully falling back to using the current window like rel="".
> 

Apparently. A number of UAs tried using target="", and all gave up.

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

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

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.

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

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Sep 2009 11:52:02 +0200

> could update its behaviour based on the registry.

Again: how is this supposed to scale? How frequently do you expect 
clients to lookup the registry? Should they cache? Should they implement 
a negative cache?

> attribute, in one language, and to upgrade HTTP to support UTF-8 in 

These are orthogonal issues. You *could* define that there must be only 
one title. Also, HTTP can not easily be upgraded to change the header 
encoding; this has been discussed a lot over here in the last years, and 
my understanding is that we would need to change the major version number.

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Sep 2009 10:44:23 -0700

> Sent: Tuesday, September 22, 2009 4:36 PM
 
> the link type is being used correctly.

It only needs to care if the link types it *knows* are used correctly. This is like saying there is value for someone who doesn't speak Spanish to known whether someone speaking Spanish uses correct grammar. It is also impossible to keep the validation rules in sync with registries and implementations. And it is absurd to suggest that a monkey with a keyboard can add an entry to a wiki and the whole world will need to refresh their browser validation rules. If you are going to require UAs to do something with the registry wiki, you are going to need a process for approving entries.

> itself from the registry).

Is that it?? Is 'Save Page' the only use case for this? This idea that we should put all these rules and validation on relation types just so that a browser won't miss a linked document when it is saving a page is completely unjustifiable. The basic idea behind links expressed via a <Link> element is that they should be ignored if the client does not understand their semantics, whether they are registered, extension, or whatever.

> relationship is the processing rules it requires. What else could a
> link type mean?

But the processing rules are context-specific and the context goes far beyond just the media type it is used it. I can write a protocol that uses HTML5 or ATOM documents and define my own processing rules for handling certain relation types. The context also includes what the client is trying to do.

For example, a relation type 'replacement' can be registered with a simple semantic meaning "a document which replaces the current document and makes it obsolete". A client fetching a document with such a link can choose to handle it by ignoring the current document and loading the replacement, by displaying it or archiving it first and then looking at the replacement, or it can use the document because it needs that specific document. And I'm sure there are more ways to handle this in the context of a search engine, identity protocols built on top of common documents, etc.

> the goal of avoiding clashes.

But the problem is not with the registry but with HTML5. You are proposing far more complex requirements for new relation types in ways that will impact the stability and performance of every compliant browser and UA in the world, but *this* is too much? The new registry is only asking for a published spec and consensus. You are asking for world domination... :-)

HTML5 should mitigate these concerns by putting in language that will require new short-name relation types to be registered. You can't have it both ways. Either HTML5 use of relation types is extremely strict, in which case you need strict rules about new relation types, or it is perfectly fine to ignore unknown types and move on, in which case you don't need another registry.

EHL

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Sep 2009 10:22:55 +1000

> any of the attributes. One "hreflang", one "media", one "type", etc.

and I said "attribute." See subsequent proposals.

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

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

> onerous registration requirements).

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

>   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

> says how to handle (e.g. ignore) duplicates, then my concern is  

OK.

> attribute, in one language, and to upgrade HTTP to support UTF-8 in

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

Cheers,

---

From: Ian Hickson <[email-masked]>
Date: Wed, 30 Sep 2009 02:33:30 +0000 (UTC)

On Fri, 25 Sep 2009, Mark Nottingham wrote:
> > 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.

I do not consider this to be a satisfactory resolution to my feedback.

You are effectively introducing a new feature; how that feature works 
needs to be specified.

> > 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.
> > 
> > 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.
> 
> unrecognised (i.e., not in the registry, or not implemented by the app) 
> relation types have purely localised meaning; i.e., they may mean 

This means that the main goal of having a registry -- namely to avoid 
conflicts when "purely localised" relations become more widely used and 
two different unrelated communities end up having used the same term -- is 
not met by this proposal. I do not consider this satisfactory.

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

Fair enough. Is there a test suite I can look at or some implementations 
of this feature so I can see how it works in practice?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Sep 2009 11:58:19 +0200

> of this feature so I can see how it works in practice?

I have tests that check support for RFC2231-style encoding for the 
filename parameter in the Content-Disposition header, see 
<http://greenbytes.de/tech/tc2231/>.

As far as I can tell, the subset used in Mark's draft is supported (and 
has been for many years) by Firefox and Opera.

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 30 Sep 2009 10:55:52 +0000 (UTC)

On Wed, 30 Sep 2009, Julian Reschke wrote:
> > > > title* feature in practice. It seems better to me to just have one title
> > Fair enough. Is there a test suite I can look at or some implementations of
> > this feature so I can see how it works in practice?
> 
> I have tests that check support for RFC2231-style encoding for the filename
> parameter in the Content-Disposition header, see
> As far as I can tell, the subset used in Mark's draft is supported (and has
> been for many years) by Firefox and Opera.

It's not the encoding I'm concerned about; it's the UI.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Sep 2009 13:11:09 +0200

> It's not the encoding I'm concerned about; it's the UI.

What does the UI have to do with the character encoding used in HTTP?

BR, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 30 Sep 2009 11:22:44 +0000 (UTC)

On Wed, 30 Sep 2009, Julian Reschke wrote:
> > > > > > 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.
> > > > >
> > > > > direction things are going in (certainly for pre-existing 
> > > > > headers like Link).
> > > >
> > > > Fair enough. Is there a test suite I can look at or some 
> > > > implementations of this feature so I can see how it works in 
> > > > practice?
> > >
> > > As far as I can tell, the subset used in Mark's draft is supported 
> > > (and has been for many years) by Firefox and Opera.
> > 

Nothing. It's the multi-language aspect of the feature I'm concerned 
about.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Sep 2009 21:20:44 +1000

Ian,

I'm more than happy to respond to a substantive technical issue that  
you bring up, but expressing concern without conveying details isn't  
helping me do that.

Can you be more explicit? What problems do you foresee?

Thanks,