Subject: Re: Link Header draft

From: Mark Nottingham <[email-masked]>
Date: Sun, 11 Feb 2007 10:34:29 +1100

On 2007/01/29, at 3:11 PM, Roy T. Fielding wrote:
> On Jan 28, 2007, at 3:39 PM, Mark Nottingham wrote:
>> The use cases I've heard of so far are with things like OpenID,  
>> GRDDL, etc.; there may also be use cases with Atom. I do have some  
>> concern about collisions between link relations identifiers in  
>> different formats (because <link> in Atom and HTML, for example,  
>> are slightly different things).
>
> Umm, what makes them slightly different?

1) The syntax of HTML relations are sgml-names (e.g., foo.bar-baz);  
Atom allows an IRI's isegment-nz-nc (in the spec; in the schema it's  
an NCName) *or* an IRI.

2) Atom defaults to "alternate"; HTML has no default.

3) Both Atom and HTML define "alternate", but HTML has additional  
semantics when "lang" or "media" are present.

4) HTML defines "rev", "media" and "charset" parameters for links,  
while Atom does not.

5) Atom defines "title" and "length" parameters for links, while HTML  
does not.

>> While Profile acts as a name space for the link relations, I'm not  
>> certain it'll be respected. Other approaches that come to mind  
>> include;
>>
>> 1) Specifying that the name space of the link relations is media  
>> type-specific, and have a registry for each.
>
> But, they aren't media type specific -- they are just relations.

In a perfect world, I'd agree. In practice, people sometimes want to  
trigger very precise behaviour from a link, and that often is tied to  
a particular representation of the data at the other end.

>> 2) Specifying a whole new header *instead* of Link that allows a  
>> URI for the link relation; establish a registry that the relation  
>> URI is relative to, independent of media type (still allowing them  
>> to use absolute URIs if they like).
>>
>> #1 seems workable, but it does require people to register their  
>> relations.
>>
>> #2 feels OK, *except* that somebody using an Atom link relation,  
>> for example, would have to do something like
>>    New-Link: <http://example.org/>; rel="atom/self"
>> rather than
>>    Link: <http://example.org/>; rel="self"
>> even though in both cases their content would contain
>>   <atom:link href="http://example.org/" rel="self"/>
>
> How about #0:  Specifying the name space as flat, first-come first- 
> served,
> and standards-track.  I would still deprecate the rev attribute, but I
> don't see any real demand for extensible relationship identifiers.

Works for me, as long as the divergence noted above can be papered  
over. I also think there needs to be some room for experimentation, a  
la Atom's use of IRIs.

> I honestly don't care if two technologies choose the same link  
> relation
> name for two different purposes -- that is far less harmful in  
> practice
> than two technologies using different names for the same purpose.
> Groups that want to ensure some degree of uniqueness can always add
> a prefix, like "dc.subject".
>
> Link relations are more like method names than identifiers. We really
> don't want people to think that having unique relations is a good  
> thing.

Generally agreed, although I think there'll be more relations than  
methods pretty quickly. Maybe more like media types *should* be...

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

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 12 Feb 2007 19:58:35 +1100

Oh - and there's also already an Atom link relations IANA registry,  
so it would require a certain amount of coordination.

What do others think? Should there be a single, flat link relation  
registry?

On 2007/02/11, at 10:34 AM, Mark Nottingham wrote:

>>> GRDDL, etc.; there may also be use cases with Atom. I do have  
>>> some concern about collisions between link relations identifiers  
>>> in different formats (because <link> in Atom and HTML, for  
>>> example, are slightly different things).
>>
> Atom allows an IRI's isegment-nz-nc (in the spec; in the schema  
> it's an NCName) *or* an IRI.
>
> 5) Atom defines "title" and "length" parameters for links, while  
> HTML does not.
>
>
>>> While Profile acts as a name space for the link relations, I'm  
>>> not certain it'll be respected. Other approaches that come to  
>>> mind include;
>>>
> In a perfect world, I'd agree. In practice, people sometimes want  
> to trigger very precise behaviour from a link, and that often is  
> tied to a particular representation of the data at the other end.
>
>
>>> URI is relative to, independent of media type (still allowing  
>>> them to use absolute URIs if they like).
>>>
> over. I also think there needs to be some room for experimentation,  
> a la Atom's use of IRIs.
>
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 12 Feb 2007 11:54:22 +0100

On Mon, 12 Feb 2007 09:58:35 +0100, Mark Nottingham <[email-masked]> wrote:
> Oh - and there's also already an Atom link relations IANA registry, so  
> it would require a certain amount of coordination.
>

http://wiki.whatwg.org/wiki/RelExtensions

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

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 12 Feb 2007 13:56:31 +0100

Am 12.02.2007 um 11:54 schrieb Anne van Kesteren:

>> Oh - and there's also already an Atom link relations IANA  
>> registry, so it would require a certain amount of coordination.
>>

It makes sense to keep a list at a known, stable location, which then  
references the defining documents/standards.

Making a FCFS IANA as in http://www.iana.org/assignments/http- 
parameters would work, although it looks a bit twentycentury.

Cheers,

Stefan

---

From: "Anne van Kesteren" <[email-masked]>
Date: Mon, 12 Feb 2007 16:57:03 +0100

> references the defining documents/standards.

Isn't that exactly what the link above does? (It's not entirely clear to  
me, as you don't elaborate much on "known", "stable location" etc.)

> Making a FCFS IANA as in http://www.iana.org/assignments/http-parameters  
> would work, although it looks a bit twentycentury.

One idea Ian Hickson had would be to set up a web service somewhere on  
whatwg.org which people could use to add new values, which validators  
could use to update their list, etc.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Feb 2007 17:10:10 +0100

Anne van Kesteren schrieb:
> ...

I would be extremely surprised if the IESG would let us define a 
registry which is not maintained by IANA. We may get away with no 
registry at all, or a registry for short names, and allowing URIs in 
addition, though.

Best regards, Julian

---

From: Stefan Eissing <[email-masked]>
Date: Mon, 12 Feb 2007 18:44:29 +0100

Am 12.02.2007 um 16:57 schrieb Anne van Kesteren:

>>>> What do others think? Should there be a single, flat link  
>>>> relation registry?
>>>
>> It makes sense to keep a list at a known, stable location, which  
>> then references the defining documents/standards.
>
> Isn't that exactly what the link above does? (It's not entirely  
> clear to me, as you don't elaborate much on "known", "stable  
> location" etc.)

I personally, would open a wikipedia article on the topic and keep  
all information and references there. Nothing against whatwg, but I  
think wikipedia is more stable (whatever I mean with that).

But it is not my decision. Given the choice, I would prefer a FCFS  
IANA page to no register at all.

> One idea Ian Hickson had would be to set up a web service somewhere  
> on whatwg.org which people could use to add new values, which  
> validators could use to update their list, etc.

I think this is good. This could serve as a write-cache and enhanced  
service/linking etc.

However I assume that the IESG would like to have a registry  
somewhere after whatwg has done its excellent work and that  
whatwg.org server dissolves into a pink cloud of happiness.

Cheers,

Stefan

---

From: Ian Hickson <[email-masked]>
Date: Tue, 13 Feb 2007 20:27:47 +0000 (UTC)

> What do others think? Should there be a single, flat link relation 

The previous spec just deferred to HTML4 for its definitions, do we want 
to not do that here? It seems like it would be dangerous to invent a third 
namespace (especially one that overlaps with existing ones), especially 
for a feature used as rarely as this one.

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Feb 2007 21:57:50 +1100

There are at least two ways to read your preference;

a) the Link header should be specific to HTML, and applicable to no  
other format
b) the Link header's rel registry should be HTML's, and other formats  
have to follow that

I don't know that either of these is workable, given that HTML and  
Atom both use link relations.

Establishing a registry isn't inventing a 3rd namespace, as long as  
its initial contents are aligned with current uses.

The biggest technical concern that I currently have is that having a  
combined registry leaves the door open for relations to be registered  
that won't be syntactically valid in HTML4, if the Atom rules are  
followed. If the HTML4 rules are followed, it would mean that the  
Atom folks would have to agree to an amendment of what a registerable  
link relation is -- but then again, they're going to have to agree to  
pointing to the combined registry anyway, so it's not that much more  
to ask, perhaps.

On 2007/02/14, at 7:27 AM, Ian Hickson wrote:

>> registry, so

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Feb 2007 12:19:03 +0100

Mark Nottingham schrieb:
> ...
> 1) The syntax of HTML relations are sgml-names (e.g., foo.bar-baz); Atom 
> allows an IRI's isegment-nz-nc (in the spec; in the schema it's an 
> NCName) *or* an IRI.
> ...

Does HTML4 actually define the syntax somewhere? I was just looking at 
the spec and couldn't find it...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 16 Feb 2007 22:25:43 +1100

Ah, interesting; I may have spoken too soon. While the Link *header*  
defined rel in RFC2068 as an sgml-name;

           relationship   = sgml-name
                          | ( <"> sgml-name *( SP sgml-name) <"> )

(section 19.6.2.4)

HTML4 itself defines it thus;

<!ENTITY % LinkTypes "CDATA"
     -- space-separated list of link types
     -->

<http://www.w3.org/TR/html4/sgml/dtd.html#LinkTypes>

On 2007/02/16, at 10:19 PM, Julian Reschke wrote:

> Mark Nottingham schrieb:
>> ...
>> 1) The syntax of HTML relations are sgml-names (e.g., foo.bar- 
>> baz); Atom allows an IRI's isegment-nz-nc (in the spec; in the  
>> schema it's an NCName) *or* an IRI.
>> ...
>
> Does HTML4 actually define the syntax somewhere? I was just looking  
> at the spec and couldn't find it...
>
> Best regards, Julian

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 16 Feb 2007 12:26:03 +0100

On Fri, 16 Feb 2007 12:19:03 +0100, Julian Reschke <[email-masked]>  
wrote:
>> Atom allows an IRI's isegment-nz-nc (in the spec; in the schema it's an  
>> NCName) *or* an IRI.
>> ...
>

http://www.w3.org/TR/html401/types.html#type-links

Basically, any string minus space-characters. Which prolly are newline,  
space and tab.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Feb 2007 12:29:20 +0100

Anne van Kesteren schrieb:
> 
> On Fri, 16 Feb 2007 12:19:03 +0100, Julian Reschke 
> <[email-masked]> wrote:

In which case IRI segments would be fine. We just need to define the 
representation of non-ASCII (non-ISO?) characters when it appears in an 
HTTP header (I'd be tempted to require UTF-8 encoding, then %-escaping).

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Fri, 16 Feb 2007 18:49:39 +0000 (UTC)

On Fri, 16 Feb 2007, Mark Nottingham wrote:
> 
> I don't know that either of these is workable, given that HTML and Atom 
> both use link relations.

Atom has a document-level hyperlinking element with link types? I thought 
the linking in Atom was from individual feeds, not from the whole 
document.

If the linking in Atom is indeed from the whole document, such that it 
makes sense to have it apply at the HTTP level, and if those relationships 
aren't compatible with HTML's, then we have a problem -- you can easily 
imagine a CDF situation with mixed Atom and HTML with Link: headers, and I 
can't see that either registry would "win" over the other. This would 
imply that HTTP would need yet another third registry for disambiguation.

---

From: "Joe Gregorio" <[email-masked]>
Date: Fri, 16 Feb 2007 13:59:47 -0500

> the linking in Atom was from individual feeds, not from the whole

Link elements may appear as children of the <feed> element or
as children of <entry> elements, so it supports both.

   -joe

-- 
Joe Gregorio        http://bitworking.org

---

From: "Mike Schinkel" <[email-masked]>
Date: Fri, 16 Feb 2007 22:08:56 -0500

Sorry, it appears that I have joined this conversation rather late, but it
also seems that you are discussing something of significant relevence to a
project I am involved in launching.  

Can someone kindly bring me up to speed? (I apologize in advance for the
request). I have found the draft [1]; is it the latest? It appears to he
about HTTP yet these discussions are about HTML and Atom; has it been
extended to include?  And what about a "rel" registry? Maybe just a summary
of the current state of the discussion would be most helpful.

Again, thanks in advance and sorry I haven't been monitoring from the
beginning.

-- 
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
"It never ceases to amaze how many people will proactively debate away
attempts to improve the web..."

[1] http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt

---

From: "Anne van Kesteren" <[email-masked]>
Date: Sat, 17 Feb 2007 08:41:02 +0100

> Again, thanks in advance and sorry I haven't been monitoring from the

http://lists.w3.org/Archives/Public/ietf-http-wg/2007JanMar/thread.html#msg129

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Feb 2007 09:51:56 +1100

...assuming we want a registry. Doing so would be a fairly large  
change from the model of HTML -- where the profile attribute allows  
extensibility, and that of Atom, where URIs provide extensibility.

---

From: "Mike Schinkel" <[email-masked]>
Date: Sat, 24 Feb 2007 08:23:39 -0500

Mark Nottingham wrote:
> ...assuming we want a registry. Doing so would be a fairly 
> large change from the model of HTML -- where the profile 
> attribute allows extensibility, and that of Atom, where URIs 
> provide extensibility.

If the rel values beyond those in the HTML spec are ever going to be used
for anything besides a nice little informational note for the 'view source'
reader, we need a registry of some sort to define what each value means.
For example, I could envision a rel="sitemap" pointing to a sitemap of a
specific XML media type.  But if there is no registry, some web developers
might decide it would be cool to start pointing it to human readable HTML
pages, thereby fragmenting the web.  

There might be another way to address my concern, but I think it needs to be
addressed somehow.