Subject: Link Header draft

From: Mark Nottingham <[email-masked]>
Date: Sun, 28 Jan 2007 19:25:13 +1100

The draft reviving the Link header <https://datatracker.ietf.org/ 
public/idindex.cgi?command=id_detail&id=14833> expired a few weeks  
ago, and I've received questions from a number of different folks  
about its status, because they want to use it.

The -00 draft <http://www.mnot.net/drafts/draft-nottingham-http-link- 
header-00.txt> was pretty much a cut-and-paste of the text from  
2068's appendix, so that there wouldn't be any conflicts with  
existing users of the header. One request I received was to align the  
header with current usage of the Link element in HTML <http:// 
www.w3.org/TR/html4/struct/links.html#edef-LINK>, e.g.:
* Remove the "rev" attribute (apparently, this is happening in HTML5).
* Remove the "anchor" attribute, or specify requirements for UAs more  
closely.
* Add a "media" attribute, to allow stylesheets to be used.

My concern is that significantly changing the existing syntax or  
semantics may make getting it out the door a problem, and my  
inclination is to leave it as is, because extension parameters can  
always be defined, and most of the uses I've seen for this aren't for  
UAs, but rather for building new protocols (e.g., OpenID).

Do people have any thoughts? Is the -00 draft good enough?

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 28 Jan 2007 16:24:55 +0100

Mark Nottingham schrieb:
> ...

1) I would recommend not to remove or add things based on what HTML5 may 
say right now. This is a moving target.

2) Not sure whether there is a problem with "anchor". Maybe it would 
benefit from an example, though.

3) "media" sounds like an interesting use case -- if we have more than 
one UA implementing this, it may be worth documenting.

Another than that, draft 00 also defines "Profile" and "Link-Template". 
Maybe it would make sense to split those into a separate document, to 
clearly distinguish between what's-been-there-all-the-time and new stuff?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 29 Jan 2007 10:39:30 +1100

On 2007/01/29, at 2:24 AM, Julian Reschke wrote:

> 1) I would recommend not to remove or add things based on what  
> HTML5 may say right now. This is a moving target.

Agreed.

> 2) Not sure whether there is a problem with "anchor". Maybe it  
> would benefit from an example, though.
>
> 3) "media" sounds like an interesting use case -- if we have more  
> than one UA implementing this, it may be worth documenting.
>
> Another than that, draft 00 also defines "Profile" and "Link- 
> Template". Maybe it would make sense to split those into a separate  
> document, to clearly distinguish between what's-been-there-all-the- 
> time and new stuff?

My biggest concern at this point is navigating through the process  
(considering that this is effectively replacing/re-specifying  
something in the "old stuff" Appendix of a Standards-Track RFC). If  
splitting helps do that, yes.

On a different note -

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

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.

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

Overall, I'd like to reuse Link if at all possible, to avoid the  
possibility of a fork. Thoughts?

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sun, 28 Jan 2007 20:11:21 -0800

On Jan 28, 2007, at 3:39 PM, Mark Nottingham wrote:
> different formats (because <link> in Atom and HTML, for example,  
> are slightly different things).

Umm, what makes them slightly different?

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

> 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).
>
> #2 feels OK, *except* that somebody using an Atom link relation,  
> for example, would have to do something like

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.

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.

....Roy