Subject: Feedback on draft-nottingham-http-link-header-03, was: Fwd: New Version Notification for draft-nottingham-http-link-header-03

From: Julian Reschke <[email-masked]>
Date: Mon, 01 Dec 2008 16:54:59 +0100

Hi Mark,

here's some feedback on the latest draft...:

> 1.  Introduction
> 
>    This document defines typed link relations, independent of the
>    context they occur in.  It does so by clarifying the status of the
>    link relation registry established by Atom, and registering in it the
>    relations that are defined by HTML.

I think it does a bit more than "clarifying", as it establishes a new 
registry.
       >    Furthermore, an HTTP header-field for conveying typed links was
>    defined in [RFC2068], but removed from [RFC2616], due to a lack of
>    implementation experience.  Since then, several use cases for doing
>    so have surfaced.  However, because it was removed, the status of the
>    Link header is unclear, leading some to consider minting new
>    application-specific HTTP headers instead of reusing it.  This
>    document addresses this by re-specifying the Link header with updated
>    but backwards-compatible syntax.

Would it be useful to note that some UAs already support the Link header 
for linking to stylesheets (I think Opera and Firefox...)?

> 5.  The Link Header Field
> 
>        Link           = "Link" ":" #link-value
>        link-value     = "<" URI-Reference ">" *( ";" link-param ) )
>        link-param     = ( ( "rel" "=" relation-type )
>                       | ( "rev" "=" relation-type )
>                       | ( "type" "=" type-name )
>                       | ( "title" "=" quoted-string )
>                       | ( link-extension ) )
>        link-extension = token [ "=" ( token | quoted-string ) ]
>        relation-type  = URI-Reference |
>                       <"> URI-Reference *( SP URI-Reference) <"> 

I note that we lost the "anchor" parameter defined in RFC 2068, Section 
19.6.2.4, so we are not strictly speaking backwards-compatible... 

>    The title parameter MAY be used to label the destination of a link
>    such that it can be used as identification within a human-readable
>    menu.

-> s/MAY be/may be/ or /is/

> 6.2.  Link Relation Type Registry
> 
>    New relation types can be registered by IETF Review, as outlined in
>    [RFC5226].  Specifications of new values should use the following
>    template:

As far as I understand RFC5226, Section 4.1, this requires an RFC. Is 
that the intent?

> Appendix A.  Notes on Using the Link Header with HTML
> 
>    <html>
>      <head profile="http://example.com/profile1/">
>        <link rel="foo" href="/foo">
>      </head>
>      [...]
> 
> 
>    could be represented as a header like this;
> 
> 
>    Link: </foo>; rel="http://example.com/profile1/foo"

Maybe use "bar" instead of one of the "foo"s...

Also: is this the proposal how to embed full URIs into HTML4? Or should 
people just use the full URI in the rel value?

Other points:

- Comparison rules: I understand we only define link comparison for 
relations used in the HTTP Link header, and the rule is 
character-by-character, case-sensitive?

- We miss a "I18N Considerations" Section. It probably should mention 
IRIs in general, and how to I18Nize the title parameter (-> RFC 2231???)

- Do we need to talk about migration issues from the old base URI to the 
new base URI? Should both be treated the same when comparing relation 
values?

Best regards, Julian

---

From: Paul Denning <[email-masked]>
Date: Mon, 1 Dec 2008 13:55:38 -0500

[1] http://tinyurl.com/5vueqt
[1] 
http://www.opensearch.org/Specifications/OpenSearch/1.1#Autodiscovery_in_HTML.2FXHTML

OpenSearch defines a "search" relation name.  Should your document 
include an entry for "search" in section 6.2 for the initial contents of 
the Link Relation Type Registry?

- Relation Name:  search
- Description:  Refers to a search description document
- Reference: [2]

[2] "this document" i.e., 
http://tools.ietf.org/html/draft-nottingham-http-link-header-04

(assuming this idea makes it into rev 04).

Note that I did not say "OpenSearch" description document because I can 
envision other content types (besides 
application/opensearchdescription+xml) that may become applicable to the 
"search" relation name.

One reason for putting "search" in your internet-draft rather than wait 
to register it after the registry is established is to make it clear 
that "search" should not be limited to OpenSearch descriptions.

When the <link> element appears in HTML/XHTML in accordance with [1], it 
also provides a @type attribute.  Your document also supports "type" as 
a link-param.

So perhaps an additional appendix can be written to essentially say what 
I said above; the appendix can reference [1] as an example of a search 
description document, but make it clear that the "search" relation name 
should not be limited to OpenSearch.

This would also provide the benefit of pointing people to the OpenSearch 
spec, which may encourage people to consider using OpenSearch (a good 
thing, IMHO).

The name "search" is just too generic to limit it to OpenSearch even 
though I like OpenSearch and would like to see it used more.

I think opensearch v4 is looking at some other relation names also, like 
"suggestions" [3].

[3] http://tinyurl.com/6xnbuy

[3] 
http://groups.google.com/group/opensearch/browse_thread/thread/b92db46be8cdc52d/f00d21f3287b1a91

Perhaps opensearch v4 should say something about autodiscovery using the 
HTTP Link Header.

Paul

On 2008-11-30 20:11, Mark Nottingham wrote:
> This is a fairly substantial rewrite of the spec, based upon the  
> observation that the link header really isn't the central concept  
> here; it's link relations themselves.
> 
...

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2008 11:13:00 +1100

Yes, that's explicitly allowed.

Cheers,

On 01/12/2008, at 4:55 PM, Alan Ruttenberg wrote:

>
> OK.
> If in a link header, do you imagine that relative URI for the target
> would be acceptable?
> -Alan
>
> On Mon, Dec 1, 2008 at 12:31 AM, Mark Nottingham <[email-masked]>  
> wrote:
>> That's true, but it's an example, not a specification; furthermore,  
>> the head
>> section is shown complete (i.e., there is a close tag) without a base
>> element...
>>
>> It's important to differentiate between relative references in the  
>> relation
>> type (e..g, rel) and the target URI. The text about not using in- 
>> document
>> base URIs only applies to the relation type, not the target URI.
>>
>> Cheers,
>>
>>
>> On 01/12/2008, at 2:19 PM, Alan Ruttenberg wrote:
>>
>>>
>>> Hello Mark,
>>>
>>> One minor comment concerning the conversion the profile to link. In
>>> that example, a relative URI is used as the target of the link.
>>> Correct me if I am wrong, but couldn't the  html document in which  
>>> the
>>> original link was embedded have had an explicit <base> element?
>>> Elsewhere you point out that the document <base> elements can't be
>>> used to resolve relative URIs in Link headers. Therefore in some  
>>> cases
>>> the example, if copied literally, would lead to errors.
>>>
>>> -Alan
>>>
>>>
>>> On Sun, Nov 30, 2008 at 8:11 PM, Mark Nottingham <[email-masked]>  
>>> wrote:
>>>>
>>>> observation
>>>> that the link header really isn't the central concept here; it's  
>>>> link
>>>> relations themselves.
>>>>
>>>> Changelog:
>>>>
>>>> o  Inverted focus from Link headers to link relations.
>>>> o  Specified was a link relation type is.
>>>> o  Based on discussion, re-added 'rev'.
>>>> o  Changed IESG Approval to IETF Consensus for relation  
>>>> registrations
>>>> (i.e., require a document).
>>>> o  Updated RFC2434 reference to RFC5226.
>>>> o  Registered relations SHOULD conform to sgml-name.
>>>> o  Cautioned against confusing relation types with media types.
>>>>
>>>> I'm particularly interested in feedback regarding registration
>>>> requirements,
>>>> as I think that's the biggest remaining sticking point. Note that  
>>>> it was
>>>> previously "IESG Approval"; I've changed it to "IETF Review" (nee  
>>>> "IETF
>>>> Consensus") so that a document is required. Also, I believe this  
>>>> still
>>>> accommodates other standards orgs (like the W3C) using their  
>>>> processes to
>>>> publish documents that register entries, just as with media types.
>>>>
>>>> Assuming this is acceptable and no serious shortcomings are found  
>>>> in this
>>>> draft, I think this document is ready to progress; i.e., I believe
>>>> (speaking
>>>> as an individual) there is consensus within the Atom community to  
>>>> make
>>>> the
>>>> registry modifications, and the feedback I've heard from the HTML
>>>> community
>>>> is that it's not necessary to have a tight integration with HTML4  
>>>> or
>>>> HTML5.
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Begin forwarded message:
>>>>
>>>>> From: IETF I-D Submission Tool <[email-masked]>
>>>>> Date: 1 December 2008 12:03:54 PM
>>>>> To: [email-masked]
>>>>> Subject: New Version Notification for
>>>>> draft-nottingham-http-link-header-03
>>>>>
>>>>>
>>>>> A new version of I-D, draft-nottingham-http-link-header-03.txt  
>>>>> has been
>>>>> successfuly submitted by Mark Nottingham and posted to the IETF
>>>>> repository.
>>>>>
>>>>> Filename:        draft-nottingham-http-link-header
>>>>> Revision:        03
>>>>> Title:           Link Relations and HTTP Header Linking
>>>>> Creation_date:   2008-12-01
>>>>> WG ID:           Independent Submission
>>>>> Number_of_pages: 15
>>>>>
>>>>> Abstract:
>>>>> This document specifies relation types for Web links, and  
>>>>> defines a
>>>>> registry for them.  It also defines how to send such links in HTTP
>>>>> headers with the Link header-field.
>>>>>
>>>>>
>>>>>
>>>>> The IETF Secretariat.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Mark Nottingham     http://www.mnot.net/
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>
>>
>

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

---

From: "Teo Hui Ming" <[email-masked]>
Date: Tue, 2 Dec 2008 10:40:01 +0800

Hi Mark,

In Section 5 "The Link Header Field",
"The context of links conveyed in the Link header field is the
 representation that the header is part of."

"the representation that the header is part of" means entity-body in a
HTTP response?

-- 
Teo Hui Ming

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2008 08:26:21 +0100

> "the representation that the header is part of" means entity-body in a

Almost:

"entity

     The information transferred as the payload of a request or 
response. An entity consists of metainformation in the form of 
entity-header fields and content in the form of an entity-body, as 
described in Section 7." -- 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.1.3>

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 13:28:04 +1100

How about:

		<t>New relation types MUST correspond to a formal publication by a
		   recognized standards body. In the case of registration for the IETF
		   itself, the registration proposal MUST be published as an  
Standards-track RFC.</t>

Note that unlike media types, this does NOT require IESG approval for  
relation types from outside the IETF; rather, just a 'formal  
publication', which AIUI corresponds to the REC track in the W3C (but  
not Notes), OASIS standard, etc.

Feedback appreciated.

On 02/12/2008, at 7:10 AM, Dan Connolly wrote:

>
> On Mon, 2008-12-01 at 12:11 +1100, Mark Nottingham wrote:
> [...]
>> requirements, as I think that's the biggest remaining sticking point.
>> Note that it was previously "IESG Approval"; I've changed it to "IETF
>> Review" (nee "IETF Consensus") so that a document is required.  
>> Also, I
>> believe this still accommodates other standards orgs (like the W3C)
>> using their processes to publish documents that register entries,  
>> just
>> as with media types.
>
> That would surprise me; while there is a significant overlap in the
> communities, the IETF does not, in general, accept consensus
> in the W3C community in place of consensus in its own community.
>
> The media type registration spec phrases it this way:
>
>
> 3.1.  Standards Tree
>
>   The standards tree is intended for types of general interest to the
>   Internet community.  Registrations in the standards tree MUST be
>   approved by the IESG and MUST correspond to a formal publication  
> by a
>   recognized standards body.  In the case of registration for the IETF
>   itself ...
>
>
>  -- http://tools.ietf.org/rfcmarkup?doc=4288#page-4
>
>
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>

---

From: Julian Reschke <[email-masked]>
Date: Wed, 10 Dec 2008 10:50:05 +0100

> not Notes), OASIS standard, etc.

Looking at <http://tools.ietf.org/html/rfc5226#section-4.1>, this looks 
like a mix between "Specification Required" and "RFC Required". The 
difference to "Specification Required" being that only standards-track 
RFCs are allowed, and that for non-IETF documents we required "formal 
publication by a recognized standards body".

Is our case sufficiently different from "Specification Required" to 
justify defining a new rule? (I'm not sure, but I think we should make 
sure we considered it...)

BR, Julian

---

From: Phil Archer <[email-masked]>
Date: Wed, 10 Dec 2008 09:55:55 +0000

> not Notes), OASIS standard, etc.

I see what you're trying to do here, and, as someone with a rel type 
registration request pending with IANA, I can only sympathise. However, 
I see two problems:

1. Your proposed text entails the definition of a 'recognised standards 
body' - that alone could cause controversy. Any list of such bodies 
written today could well be out of date by this time next year.

2. I understand that the Web works by keeping things distributed rather 
than centralised, but in this case, there would still be a need for some 
sort of central 'list of registered relationship types' to avoid two 
working groups in different standards bodies coming up with new 
definitions for existing rel types. Now, to go back to an older idea, 
/that/ could be a wiki - a simple table giving the rel type, the 
description and the relevant formal publication. But for this to work, 
the wiki would probably need to be cited in the I-D/RFC and we're back 
to who is going to host that?

Phil.

>>> Review" (nee "IETF Consensus") so that a document is required. Also, I
>>> using their processes to publish documents that register entries, just
>>> as with media types.
>>
>>   approved by the IESG and MUST correspond to a formal publication by a

-- 
Phil Archer
w. http://philarcher.org/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 20:55:15 +1100

Yes. If we went pure "Specification Required", any RFC or NOTE (for  
example) could be used as the basis of registration, as long as it  
passed muster with a Designated Expert.

Either process would be fine by me; I'm mostly interested in what the  
Atom and HTML folks think about these options.

On 10/12/2008, at 8:50 PM, Julian Reschke wrote:

>> Note that unlike media types, this does NOT require IESG approval  
>> for relation types from outside the IETF; rather, just a 'formal  
>> publication', which AIUI corresponds to the REC track in the W3C  
>> (but not Notes), OASIS standard, etc.
>> Feedback appreciated.
>> ...
>
> Looking at <http://tools.ietf.org/html/rfc5226#section-4.1>, this  
> looks like a mix between "Specification Required" and "RFC  
> Required". The difference to "Specification Required" being that  
> only standards-track RFCs are allowed, and that for non-IETF  
> documents we required "formal publication by a recognized standards  
> body".
>
> justify defining a new rule? (I'm not sure, but I think we should  
> make sure we considered it...)
>
> BR, Julian
>
>
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 10 Dec 2008 11:04:48 +0100

> Atom and HTML folks think about these options.

I like the wiki approach a lot more personally. Registries are a pain to  
deal with. Then again, it seems the HTTP Link you define is not very much  
in line with HTML5 <link>, <a>, <area> anyway.

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 21:28:26 +1100

On 10/12/2008, at 8:55 PM, Phil Archer wrote:
> registration request pending with IANA, I can only sympathise.  
> However, I see two problems:
>
> 1. Your proposed text entails the definition of a 'recognised  
> standards body' - that alone could cause controversy. Any list of  
> such bodies written today could well be out of date by this time  
> next year.

AIUI it's up to the IESG at time time of request; there doesn't need  
to be a list as such.

That said, it's starting to seem like the Specification Required  
approach mentioned by Julian might be a better fit.

> 2. I understand that the Web works by keeping things distributed  
> rather than centralised, but in this case, there would still be a  
> need for some sort of central 'list of registered relationship  
> types' to avoid two working groups in different standards bodies  
> coming up with new definitions for existing rel types. Now, to go  
> back to an older idea, /that/ could be a wiki - a simple table  
> giving the rel type, the description and the relevant formal  
> publication. But for this to work, the wiki would probably need to  
> be cited in the I-D/RFC and we're back to who is going to host that?

That would entail all sorts of process problems from the IETF, which  
already has a well-recognised body to handle this, IANA. It's a real  
challenge to get a URI into an IETF spec, much less a Wiki page. How  
will you prevent people from changing or deleting existing entries?  
Who will monitor it for abuse?

Beyond that, a wiki is in effect a first-come, first-served mechanism  
to avoid conflicts, and allowing URIs already serves that function;  
i.e., they already assure that two WGs won't define the same relation.  
The point of a central registry is to converge upon well-understood,  
well-defined and agreed upon link types that are of common value and  
can be reused.

The free-for-all that a wiki entails will result in (insert evil  
company here) grabbing a "common" name first and defining it in their  
interest, without consultation with the rest of the community;  
interoperability problems as people don't document their relation  
types well, or think about how they'll be used; and so on. Having a  
registry with some bar for entry is designed to encourage good design,  
interoperability, and grow the commons; it's not just there to avoid  
conflicts and be a pain in the posterior to impatient developers.

Despite how it seems sometimes.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 21:29:02 +1100

On 10/12/2008, at 9:04 PM, Anne van Kesteren wrote:

> Then again, it seems the HTTP Link you define is not very much in  
> line with HTML5 <link>, <a>, <area> anyway.

Can you give a little more detail?

---

From: Phil Archer <[email-masked]>
Date: Wed, 10 Dec 2008 10:46:09 +0000

Mark Nottingham wrote:
>> standards body' - that alone could cause controversy. Any list of such 
>> bodies written today could well be out of date by this time next year.
> 
> AIUI it's up to the IESG at time time of request; there doesn't need to 
> be a list as such.
> 

Yes, I agree that the RFC 5226 'Specification Required' idea fits here. 
I just have a slight niggle, I forget the name now but there was a new 
body set up a few months back that had the appearance of trying to do at 
least some of the W3C work but without the overhead that the Consortium 
is perceived to require, and there's the case of the WAP forum that 
became OMA - would that have always been a recognised body or did that 
become such after it became OMA and so on. It's a bit grey that's all.

>> rather than centralised, but in this case, there would still be a need 
>> for some sort of central 'list of registered relationship types' to 
>> avoid two working groups in different standards bodies coming up with 
>> new definitions for existing rel types. Now, to go back to an older 
>> idea, /that/ could be a wiki - a simple table giving the rel type, the 

You misunderstand me. I'm the last person to propose a wiki as the 
authoritative central registry (for all the reasons you give). And I 
think I misunderstood you too. You're saying that rel types would be 
added to the IANA registry /automatically/ iff they met the 
Specification Required rule? Then I agree completely.

What I was concerned about was that the different documents with change 
control under different organisations would *be* the registry, in which 
case one would need a handy guide to where those documents were - and a 
wiki could do that. But the IANA registry is the best way and if that's 
to happen then I'll shut up.

> will you prevent people from changing or deleting existing entries? Who 
> will monitor it for abuse?
> 
> Beyond that, a wiki is in effect a first-come, first-served mechanism to 
> avoid conflicts, and allowing URIs already serves that function; i.e., 
> they already assure that two WGs won't define the same relation. The 
> point of a central registry is to converge upon well-understood, 
> well-defined and agreed upon link types that are of common value and can 
> be reused.
> 
> The free-for-all that a wiki entails will result in (insert evil company 
> here) grabbing a "common" name first and defining it in their interest, 
> without consultation with the rest of the community; interoperability 
> problems as people don't document their relation types well, or think 
> about how they'll be used; and so on. Having a registry with some bar 
> for entry is designed to encourage good design, interoperability, and 
> grow the commons; it's not just there to avoid conflicts and be a pain 
> in the posterior to impatient developers.
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 10 Dec 2008 11:52:59 +0100

On Wed, 10 Dec 2008 11:29:02 +0100, Mark Nottingham <[email-masked]> wrote:
>> Then again, it seems the HTTP Link you define is not very much in line  
>> with HTML5 <link>, <a>, <area> anyway.
>

Skimming through the drafts for a few minutes I find at least these:

In HTML5 the tokens are not URIs and are not really URI-references either  
because they have to be case-insensitively matched (the HTML5  
specification is currently wrong on this).  
(http://www.iana.org/assignments/relation/stylesheet and stylesheet are  
therefore not equal either.)

In HTML5 people can simply provisionally register a new token by putting  
it on a wiki page. The token does not have to be a URI. (Though it could  
be a string that is also a URI.)

In HTML5 there is no rev "link-param" because (non-academic) studies have  
shown that people do not really know how to use it.

In HTML5 media, hreflang, and sizes (just for <link>) also influence the  
relationship. Your draft does not have these "link-param"s.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 21:59:33 +1100

On 10/12/2008, at 9:52 PM, Anne van Kesteren wrote:

> In HTML5 the tokens are not URIs and are not really URI-references  
> either because they have to be case-insensitively matched (the HTML5  
> specification is currently wrong on this). (http://www.iana.org/assignments/relation/stylesheet 
>  and stylesheet are therefore not equal either.)

The registered tokens are effectively tokens, and can be considered  
case-insensitive (see the notes on use in HTML4).

> In HTML5 people can simply provisionally register a new token by  
> putting it on a wiki page. The token does not have to be a URI.  
> (Though it could be a string that is also a URI.)

See the discussion with Phil.

> In HTML5 there is no rev "link-param" because (non-academic) studies  
> have shown that people do not really know how to use it.

See current discussion about deprecating it.

> In HTML5 media, hreflang, and sizes (just for <link>) also influence  
> the relationship. Your draft does not have these "link-param"s.

Other extensions are allowed; again, see the appendix about use in HTML.

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 10 Dec 2008 12:11:56 +0100

> case-insensitive (see the notes on use in HTML4).

If you have

   http://example.com/foo
   http://example.com/FOO

they would be the same in HTML, but would not be for the Link HTTP  
header... (It's also not really clear to me why relationship values are  
have to be resolved and why we not just use the same rules as we do for  
namespaces.)

Also, I definitely do not want to start having to implement support for  
http://www.iana.org/assignments/relation/stylesheet besides just  
stylesheet. (Not for the Link HTTP header or for the HTML elements.)  
That's just additional complexity for no gain and will only lead to bugs  
and differences among browsers.

>> putting it on a wiki page. The token does not have to be a URI. (Though  
>> it could be a string that is also a URI.)
>

That's sort of the reason why I started replying...

> See current discussion about deprecating it.

What does deprecating mean here for the various parties (e.g. implementors  
and authors)?

> Other extensions are allowed; again, see the appendix about use in HTML.

It says they are believed to be defunct... media is pretty damn important  
for style sheets at least.

---

From: Phil Archer <[email-masked]>
Date: Wed, 10 Dec 2008 11:50:09 +0000

Anne van Kesteren wrote:
>>> (http://www.iana.org/assignments/relation/stylesheet and stylesheet 
>>> are therefore not equal either.)
>>

Case sensitivity is an issue. Hmmm... can 04 say that tokens given as 
rel types SHOULD be lower case and that UAs SHOULD treat such tokens as 
case insensitive? Would that put too much of a strain on saying that 
tokens are treated as relative URIs? (I know that paths are case sensitive).

> and differences among browsers.

There shouldn't be any need for UAs to resolve tokens given as values 
for @rel as absolute URIs and no one's suggesting that UAs should 
actually make an HTTP request of any kind to iana.org every time there's 
a link to a stylesheet. It's the person minting the new relationship 
type that needs to check. What it means is that if you create a link 
(HTML or HTTP) and use a @rel type 'foo' that gives a 404 from 
http://www.iana.org/assignments/relation/foo then you really shouldn't 
expect UAs to do anything sensible with it.

Whether a UA chooses to actually implement support for a registered @rel 
type remains very much up to the UA developer of course.

> That's sort of the reason why I started replying...

Always a pleasure to stir things up a little!

> What does deprecating mean here for the various parties (e.g. 
> implementors and authors)?
> 
> 
> It says they are believed to be defunct... media is pretty damn 
> important for style sheets at least.
> 
>

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 10 Dec 2008 13:09:20 +0100

On Wed, 10 Dec 2008 12:50:09 +0100, Phil Archer <[email-masked]>  
wrote:
> Anne van Kesteren wrote:
>>  Also, I definitely do not want to start having to implement support  
>> for http://www.iana.org/assignments/relation/stylesheet besides just  
>> That's just additional complexity for no gain and will only lead to  
>> bugs and differences among browsers.
>

The concern is that besides supporting stylesheet (and it's case variants)  
we'd also have to support  
http://www.iana.org/assignments/relation/stylesheet meaning the same  
thing. And thus also http://www.iana.org/assignments/relation/alternate  
and the special behavior you get when both (stylesheet and alternate) are  
specified. We can map http://www.iana.org/assignments/relation/stylesheet  
to stylesheet and such first, but I don't think adding another layer of  
complexity is justified.

(I'm not at all concerned about UAs having to fetch such URIs, as any such  
proposal would be stillborn.)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 10 Dec 2008 23:56:47 +1100

On 10/12/2008, at 10:11 PM, Anne van Kesteren wrote:
> header...

Correct.

Ignoring case when comparing the short-form, registered values makes  
sense, and should be covered by

>    HTML defines link relation values as case-insensitive, while the  
> Link
>    header's syntax does not.  Therefore, it is important to case-
>    normalise relation values in HTML before comparing or converting  
> them
>    to Link headers.

although that could use some tweaking.

However, ignoring case when comparing entire URIs (i.e., non-registry  
values) seems like a pathological case. I would posit that people are  
much more aware of case issues in full URIs, because they have to be  
on the Web today anyway, no matter how many corrections their browser  
makes for them.

> (It's also not really clear to me why relationship values are have  
> to be resolved and why we not just use the same rules as we do for  
> namespaces.)

They don't; I think the clarification that Roy requested earlier will  
help here.

> bugs and differences among browsers.

Not if it's specified sensibly, clearly and unambiguously. The worst  
possible thing to put in here would be advice -- but not a requirement  
-- to use the short form when available.

The other approach is to require the short form to be used when  
registered. However, that seems more of a special case that's likely  
to cause problems; software producing links that wishes to mix  
registered and non-registered relations will have to remember and test  
for the difference, and serialise accordingly. That has the potential  
for bugs and resulting differences among implementations (not just  
browsers).

The other, other approach is to dispense with the notion that a  
registered value is a URI, while still allowing URIs (and only  
absolute URIs, ever) for non-registered URIs. This would necessitate  
that the registered values MUST conform to sgml-name or similar, to  
allow them to be distinguished from URIs, and would preclude some  
future application from using relative URIs as relations (e.g., if you  
had an XML format and used a lot of locally-defined relations, you  
couldn't use XML base to shorten them, because they'd be potentialy  
ambiguous), but otherwise this might be workable.

This latter approach would also make defining case insensitivity for  
registered values easier.

Thoughts (everyone, not just Anne)?

>>> In HTML5 there is no rev "link-param" because (non-academic)  
>>> studies have shown that people do not really know how to use it.
>>

It depends on where the discussion goes, but right now it looks like  
it means that authors are cautioned not to use it, as it's confusing,  
and implementers may or may not support it at their peril/pleasure.  
The only requirement is that they not blow up when they see a rev (but  
that goes for any unrecognised extension).

>>> In HTML5 media, hreflang, and sizes (just for <link>) also  
>>> influence the relationship. Your draft does not have these "link- 
>>> param"s.
>>

I'll remove the "defunct" language in the next draft.

I'm hesitant to define media in this draft without a format-neutral  
description of its semantics and possible values, but again it is  
accommodated already.

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 10 Dec 2008 10:11:52 -0800

> Thoughts (everyone, not just Anne)?

I suggest what I suggested at the HTML WG f2f at TPAC this year:

  1) Rel keywords are are strings that are one or more Unicode  
characters in length and don't contain HTML5 space characters and  
don't start with the string "http://www.iana.org/assignments/relation/".
     - It follows that both "foo" and "http://example.com/ns/2008/12/ 
bar" are possible keywords.
  2) If a keyword contains a colon, the keyword must (for document  
conformance) be a valid IRI.
  3) Keywords are compared ASCII-case-insensitively, that is, a-z  
equals A-Z and otherwise code-point-for-code-point.
  4) The Link HTTP header can use those rel keywords that are ASCII- 
only (since HTTP header values aren't robust with arbitrary Unicode).
  5) Consumers who want to see the world as IRIs (not browsers but  
e.g. GRDDL extractors) run the following algorithm to convert a rel  
keyword to an IRI:
     a) Replace A-Z with a-z.
     b) If the result does not contain a colon, prepend "http://www.iana.org/assignments/relation/ 
"
  6) Keywords that don't contain a colon must be registered on the  
WHATWG wiki (or a W3C wiki if the W3C decides to host the registry).
  7) The registry wiki is licensed under a GPL-compatible but not in  
itself reciprocal Free Software license (e.g. MIT or New BSD).

(Notes about points #6 and #7: I consider the IANA registration  
procedure too cumbersome compared to editing a wiki, and I think it is  
a bug that IANA registries are not under a Free Software license,  
since not being under a Free Software license is a problem for  
inclusion in Free Software.)

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 10 Dec 2008 10:56:17 -0800

On Dec 10, 2008, at 10:21, Philip TAYLOR (Ret'd) wrote:

> I cannot reconcile (2) and (5a) :
>
> Henri Sivonen wrote:
>
> http://www.w3.org/2002/Talks/0715-duerst-iri/slide2-0.html indicates
> that http://www.w3.org/People/Dürst is valid IRI (which could
> hence be a keyword), yet after (5a)
>
> this becomes http://www.w3.org/people/dürst, which is not
> the same IRI at all ...

Correct. So it follows that it's a really bad idea to mint IRI-looking  
rel keywords that contain letters A-Z.

This is a bit inelegant but the legacy is constraining us here.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Dec 2008 12:04:09 +1100

I think we're roughly on the same track regarding 1-5; I'll work on  
straw-man spec text in this direction.

Regarding the registry itself -- see previous discussion about  
relative merits and difficulty.

Regarding the licensing of the registry -- I can't help feel that this  
is a red herring, given that IANA also manages the DNS root zone, IP  
address and AS number allocation, and just about every protocol  
registry associated with the Internet, including media types, Ethernet  
numbers, HTTP status codes, IMAP capabilities, IPv4 and IPv6  
parameters, language tags, port numbers, protocol numbers, PGP  
attributes, SSH parameters, TLS parameters, SNMP number spaces, syslog  
parameters, URNs, URI schemes, etc. See: <http://www.iana.org/ 
protocols/> for the full list.

In short, pretty much any "free software" that connects to the  
Internet is riddled with dependencies upon IANA registries. On any  
Unix-like system, take a look at /etc/services and /etc/protocols, for  
starters. If this is a real issue, it affects much more than the  
registration of link relation types, and you should take it up with  
IANA, the IESG and the IAB immediately, or change your concept of  
what's necessary for "free software".

Cheers,

On 11/12/2008, at 5:11 AM, Henri Sivonen wrote:

> procedure too cumbersome compared to editing a wiki, and I think it  
> is a bug that IANA registries are not under a Free Software license,