Subject: [link-relations] NEW APP DATA

From: Ian Hickson <[email-masked]>
Date: Mon, 9 Aug 2010 04:30:39 +0000 (UTC)

o Application Name: HTML
    o Description: Effect on a and area elements
    o Default Value: Not allowed
    o Notes: The following values should have "Hyperlink" for this
        field: alternate, appendix, bookmark, chapter, contents,
        copyright, first, glossary, help, index, first, last, license,
        next, prev, previous, section, start, subsection, up.
    o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry

    o Application Name: HTML
    o Description: Effect on link elements
    o Default Value: Not allowed
    o Notes: The following values should have "Hyperlink" for this
        field: alternate, appendix, chapter, contents, copyright,
        first, glossary, help, index, first, last, license, next,
        prev, previous, section, start, subsection, up. The following
        values should have "External Resource Link" for this field:
        stylesheet.
    o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Aug 2010 09:00:29 +0200

>      o Specification: http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry

Ian,

could you please have a look at my feedback from July 15:

<http://www.ietf.org/mail-archive/web/link-relations/current/msg00002.html>

and try to address it?

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 9 Aug 2010 08:43:25 +0000 (UTC)

On Mon, 9 Aug 2010, Julian Reschke wrote:
> >      o Specification:
> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry
> > 
> >      o Application Name: HTML
> >      o Specification:
> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#iana-registry
> 

My apologies, I assumed that the answers to those questions were 
self-evident in the edits made to the spec recently.

The purpose of those flags is to define conformance for HTML.

Relations can be updated to define how they work with HTML by using the 
process described in the Web Linking spec.

An example of a relation that we would not want to allow is rel=stylesheet 
on <area>, which we would want to disallow because it has no effect and 
is therefore likely an authoring mistake. Similarly, we wouldn't want 
rel=noreferrer to be allowed on <link> because it's not a link relation, 
it's a link annotation, and <link> doesn't create hyperlinks without a 
relation that creates one. Each keyword would have to be taken on a case- 
by-case basis.

Regarding the final parenthetical, I believe the templates fit what is 
described in the Web Linking spec.

HTH,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Aug 2010 11:37:21 +0200

> self-evident in the edits made to the spec recently.

No, they aren't.

> The purpose of those flags is to define conformance for HTML.

Yes. I'm not convinced that it's a good idea to move this into the IANA 
registry, nor am I convinced that the individual flags and their 
defaults make sense.

> process described in the Web Linking spec.

Do you think it's necessary to do so? Be default, I'd expect any link 
relation that we have to be usable with <link> by default. It would be 
very useful to understand why this wouldn't be the case.

> on<area>, which we would want to disallow because it has no effect and

(Side note: when did <area> acquire @rel???)

Are you confident that <a> and <area> always have the same requirements?

> rel=noreferrer to be allowed on<link>  because it's not a link relation,
> it's a link annotation, and<link>  doesn't create hyperlinks without a

I can see that noreferrer being the only link relation on a <link> is 
meaningless, but that doesn't mean it needs to be disallowed; there 
could be other rel values present, after all.

> described in the Web Linking spec.

It does, this is an oversight in the spec. So we'd have to figure out 
unique names upon registration.

Going back to the original issue (hopefully providing context for those 
who weren't there): we discussed application-specific data when we met 
in Santa Clara last November. The use case that was provided was a flag 
that would allow user agents to decide what kind of links need to be 
followed when going offline or archiving a resource. That makes a lot of 
sense, and I'd support that kind of flag, hopefully described in a way 
that isn't totally specific to HTML.

What you are proposing is much more; it augments the link type registry 
with validation hints. I'm totally unconvinced that this is a good idea; 
in particular given the fact that it's an open question in the HTML WG 
how far validation should go with respect to these values.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 9 Aug 2010 17:50:50 +0000 (UTC)

On Mon, 9 Aug 2010, Julian Reschke wrote:
> registry

Nor am I, but that is what the registry was designed to do.

> nor am I convinced that the individual flags and their defaults make 
> sense.

Ok... Do I have to convince you for the fields to be registered?

> > Relations can be updated to define how they work with HTML by using 
> > the process described in the Web Linking spec.
> 

It's certainly not the case that any link relation is relevant anywhere. 
Suppose someone designed a link relation whose purpose was to identify a 
resource that should be notified any time an API call was made on an 
HTMLDocument object. That presumably wouldn't make any sense in an Atom 
feed. Similarly, consider "edit" or "edit-media". While they may be 
well-defined in the context of Atom, they certainly are not defined to a 
level that is clear enough for it to make sense to use them in an HTML 
document, so we wouldn't want to have an author accidentally use them 
(especially if they were just using them because they thought they could 
make up new relations and just accidentally clashed with the Atom ones).

> > An example of a relation that we would not want to allow is 
> > rel=stylesheet on<area>, which we would want to disallow because it 
> > has no effect and is therefore likely an authoring mistake. Similarly, 
> > we wouldn't want
> 

As part of the WHATWG's rationalisation of HTML features a few years ago 
we made all elements that could create hyperlinks be consistently defined 
(as much as we can given legacy, anyway).

> Are you confident that <a> and <area> always have the same requirements?

They currently do. If that changes, we'll update the registries. Who knows 
what the future holds.

> > rel=noreferrer to be allowed on <link> because it's not a link 
> > relation, it's a link annotation, and <link> doesn't create hyperlinks 
> > without a relation that creates one. Each keyword would have to be 
> > taken on a case- by-case basis.
> 

If something is meaningless, the author benefits from being informed of 
this, since it is unlikely to be his intent. That's what conformance 
checkers, and thus conformance definitions, are for.

> unique names upon registration.

I'm just trying to do what the spec says here.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Aug 2010 20:33:37 +0200

> Nor am I, but that is what the registry was designed to do.

Maybe it's just me, but I don't think it was designed for that.

> Ok... Do I have to convince you for the fields to be registered?

There are three designated experts, and I assume you need to convince at 
least one of them. I'm one of those.

>> relation that we have to be usable with<link>  by default. It would be

My understanding is that we want *future* registered link relations to 
be broadly usable. So for the example you just mentioned I don't see how 
a registration would suceed.

> ...
>> Are you confident that<a>  and<area>  always have the same requirements?
>

And add yet another column to the generic registry? Hm.

>>> rel=noreferrer to be allowed on<link>  because it's not a link
>>> relation, it's a link annotation, and<link>  doesn't create hyperlinks
>> I can see that noreferrer being the only link relation on a<link>  is

The point being it's only meaningless (in HTML) when it's the *only* 
link relation on the link. Thus, it doesn't make sense to forbid

   <link rel="noreferrer stylesheet" ...

just because

   <link rel="noreferrer" ...

might be an authoring mistake.

> I'm just trying to do what the spec says here.

In the meantime, what's your take on the part of my email you skipped?

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 9 Aug 2010 19:10:20 +0000 (UTC)

On Mon, 9 Aug 2010, Julian Reschke wrote:
> > > Yes. I'm not convinced that it's a good idea to move this into the 
> > > IANA registry
> > 

Well, the field registry exists so as to make it possible to use the 
registry for HTML, as I understand it. But maybe I'm mistaken, and we're 
not supposed to use the registry for HTML relations? I'm confused now.

> least one of them. I'm one of those.

I see.

How can I convince you?

> > > > Relations can be updated to define how they work with HTML by 
> > > > using the process described in the Web Linking spec.
> > > 
> > > Do you think it's necessary to do so? Be default, I'd expect any 
> > > link relation that we have to be usable with<link> by default. It 
> > > would be very useful to understand why this wouldn't be the case.
> > 
> > It's certainly not the case that any link relation is relevant 
> > anywhere. Suppose someone designed a link relation whose purpose was 
> > to identify a resource that should be notified any time an API call 
> > was made on an HTMLDocument object. That presumably wouldn't make any 
> > sense in an Atom feed. Similarly, consider "edit" or "edit-media". 
> > While they may be well-defined in the context of Atom, they certainly 
> > are not defined to a level that is clear enough for it to make sense 
> > to use them in an HTML document, so we wouldn't want to have an author 
> > accidentally use them (especially if they were just using them because 
> > they thought they could make up new relations and just accidentally 
> > clashed with the Atom ones).
> 

Well it would be a pretty useless registry if it didn't match reality. :-) 
I would presume that if someone implemented such a value, getting it 
registered would be near-automatic, since otherwise we're just going to 
end up with clashes because people won't be able to register the values 
they're using, no?

> > They currently do. If that changes, we'll update the registries. Who 
> > knows what the future holds.
> 
> And add yet another column to the generic registry?

Are columns expensive?

> > > > relation, it's a link annotation, and<link> doesn't create 
> > > > hyperlinks without a relation that creates one. Each keyword would 
> > > > have to be taken on a case- by-case basis.
> > > 
> > If something is meaningless, the author benefits from being informed 
> > of this, since it is unlikely to be his intent. That's what 
> > conformance checkers, and thus conformance definitions, are for.
> 

That's possible, but that's an issue for HTML, not for the registry, no?

> > > > Regarding the final parenthetical, I believe the templates fit 
> > > > what is described in the Web Linking spec.
> > > 
> > > It does, this is an oversight in the spec. So we'd have to figure 
> > > out unique names upon registration.
> > 

> Going back to the original issue (hopefully providing context for
> those who weren't there): we discussed application-specific data
> when we met in Santa Clara last November. The use case that was
> provided was a flag that would allow user agents to decide what kind
> of links need to be followed when going offline or archiving a
> resource. That makes a lot of sense, and I'd support that kind of
> flag, hopefully described in a way that isn't totally specific to
> HTML.

I have no opinion on this.

> What you are proposing is much more; it augments the link type
> registry with validation hints. I'm totally unconvinced that this is
> a good idea; in particular given the fact that it's an open question
> in the HTML WG how far validation should go with respect to these
> values.

I see. Not sure what to do about that.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Aug 2010 21:40:17 +0200

> not supposed to use the registry for HTML relations? I'm confused now.

Yes, we want a registry that can be shared among HTML, Atom, HTTP, and 
other users of link relations.

But that doesn't necessarily imply that a specific application needs to 
off-load everything it wants into that registry.

>> least one of them. I'm one of those.

1) You could re-consider the default ("not valid").

2) You could rephrase the application flags in a more generic way (as 
discussed last November).

..also, in the HTML WG, we really need to discuss whether conformance 
checkers ought to check link relations.

> end up with clashes because people won't be able to register the values

If someone tried to register that relation, I'd probably propose to use 
an extension relation type instead, or to prefix the short name with 
something that makes it clear it's very application-specific.

So, no, there is no automatism.

>> And add yet another column to the generic registry?

Yes, because it makes all future registrations more complicated. I'd 
expect new columns to be an exception.

Mark?

> That's possible, but that's an issue for HTML, not for the registry, no?

Yes, the registry should just allow "noreferrer". That's my point.

> I have no opinion on this.

Well, it's the use case you brought up (as far as I recall), and why the 
application data registry was added.

I think it's a good use case, and I expected that this would be the 
application data you're going to register.

> I see. Not sure what to do about that.

One approach would be to simplify the application data as described 
above, and consider the remainder (if needed at all) something local to 
HTML.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Mon, 9 Aug 2010 21:47:29 +0000 (UTC)

On Mon, 9 Aug 2010, Julian Reschke wrote:
> > registry for HTML, as I understand it. But maybe I'm mistaken, and 
> > we're not supposed to use the registry for HTML relations? I'm 
> > confused now.
> 

It's unclear to me how I am supposed to use the registry then.

> > > There are three designated experts, and I assume you need to 
> > > convince at least one of them. I'm one of those.
> > 
> > How can I convince you?
> 

The default only applies to the existing relations, right? I didn't really 
want to pick a default at all, I just wanted to list the values for the 
keywords I was familiar with, and wanted to let the people who'd 
registered the other values determine the values if they wanted their 
keywords usable with HTML.

I'm happy to change the "default" to something else and just list the 
values differently, but that just seems like busywork, it wouldn't 
actually change anything in the registry.

> discussed last November).

It's unclear what this would mean. I don't think making things "generic" 
makes sense here. We're trying to solve a very specific problem for this 
application (HTML), for which we need specific data... how would we make 
this generic?

> checkers ought to check link relations.

That seems out of scope for this particular thread.

> > > My understanding is that we want *future* registered link relations 
> > > to be broadly usable. So for the example you just mentioned I don't 
> > > see how a registration would suceed.
> > 
> > Well it would be a pretty useless registry if it didn't match reality. 
> > :-) I would presume that if someone implemented such a value, getting 
> > it registered would be near-automatic, since otherwise we're just 
> > going to end up with clashes because people won't be able to register 
> > the values they're using, no?
> 

Ok well that seems somewhat off-topic for this registration so I guess we 
should leave this for another thread.

> Yes, the registry should just allow "noreferrer". That's my point.

Surely we don't want to update HTML each time there's a change to the 
registry? Or is that what you're saying we should do? I don't understand.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Aug 2010 08:48:55 +0200

> It's unclear to me how I am supposed to use the registry then.

Just mentioning the options: one approach would be to have a second 
place for the additional information, another one would be to reconsider 
whether the additional information actually makes sense.

> keywords usable with HTML.

Yes, and again: I do not see why any of those would not be allowed in 
HTML, so I really think you have chosen the wrong default value.

> actually change anything in the registry.

It would change the value the existing registrations get.

> application (HTML), for which we need specific data... how would we make

I explained that already. Define behavior for user agents (as discussed 
last year), not HTML-specific validity constraints.

> registry? Or is that what you're saying we should do? I don't understand.

What I'm saying is that "noreferrer" should be allowed on <a>/<area> and 
<link>; as far as I can tell, your proposal disallows it for <link> 
(consistent with HTML5, so this is a bug in HTML5), and also disallows 
it for <a>/<area> (which seems to be a bug in your registration).

(There may be more problems, I just checked this one).

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Tue, 10 Aug 2010 07:53:46 +0000 (UTC)

On Tue, 10 Aug 2010, Julian Reschke wrote:
> > >
> > > 2) You could rephrase the application flags in a more generic way 
> > > (as discussed last November).
> > 
> > It's unclear what this would mean. I don't think making things 
> > "generic" makes sense here. We're trying to solve a very specific 
> > problem for this application (HTML), for which we need specific 
> > data... how would we make this generic?
> 

The proposal does both. Are you saying I should file separate 
registrations for whether something is a hyperlink or an external resource 
link, and whether something is allowed on <link> or <a>/<area>? I suppose 
we could do that but that would just make the interface with the HTML spec 
a bit more complicated, and I don't understand how that would help anyone. 
Are other languages also interested in the distinction between hyperlinks 
and external resource links? I assumed this was just an HTML issue.

> it for <a>/<area> (which seems to be a bug in your registration).

I don't understand how it affects noreferrer. That keyword isn't listed in 
the registry and isn't in the proposal as far as I can tell.

At this point I'm unsure how to proceed. Is the registration request 
denied? Should I just send the request again but listing the keywords that 
are not allowed rather than the keywords that are hyperlinks, and with the 
default switched around? I don't really understand this process.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Aug 2010 10:16:34 +0200

On 10.08.2010 09:53, Ian Hickson wrote:
> link, and whether something is allowed on<link>  or<a>/<area>? I suppose

Actually, I'd prefer a single flag for link/external resource (and yes, 
this may affect other languages as well), and keep the conformance 
related flags out of the IANA registry (but again, this is just the 
opinion of one of the D.E.s).

>> What I'm saying is that "noreferrer" should be allowed on<a>/<area>  and
>> <link>; as far as I can tell, your proposal disallows it for<link>
>> it for<a>/<area>  (which seems to be a bug in your registration).
>

You are right. Sorry.

So, taking another example where the flags are different for <link> and 
<a>/<area>: why is "bookmark" disallowed on link?

> default switched around? I don't really understand this process.

Apparently, we (you and I) are still discussing the registration.

Let me summarize again my concerns:

- Unconvinced that <a> and <link> require different treatment.

- Unconvinced that the IANA registry needs to carry metadata for HTML 
validation.

- Unconvinced that the default of "no" for <link> is right. If somebody 
defines a link relation, and it doesn't make sense on <link>, then it 
appears that something is very wrong with the proposed semantics of the 
link relation.

-> Proposal: just define a flag that reflects the "hyperlink"/"external 
resource" distinction.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Aug 2010 21:31:27 +1000

Gentlemen,

My (possibly and perhaps mercifully uninformed) view is that the issues you're discussing are specific to HTML5, and should be decided in the appropriate venue before bringing this forward for registration; the link relations registry is relatively neutral about how and for what the appdata fields are used for. 

There's another aspect of this that I have concerns about process-wise, which I'll raise in a separate e-mail.

I will say that appdata fields are expensive in the sense that once they're added, they persist. So, we need to make sure that this is how they'll actually be specified before they're added to the registry. This is why adding new appdata fields is Specification Required, which implies permanence. 

Regards,

P.S. Ian - when you do register something, convention dictates that the template (which you've pasted below) actually go in the document itself.

On 10/08/2010, at 6:16 PM, Julian Reschke wrote:

> Actually, I'd prefer a single flag for link/external resource (and yes, this may affect other languages as well), and keep the conformance related flags out of the IANA registry (but again, this is just the opinion of one of the D.E.s).
> 
> So, taking another example where the flags are different for <link> and <a>/<area>: why is "bookmark" disallowed on link?
> 
> - Unconvinced that the IANA registry needs to carry metadata for HTML validation.
> 
> - Unconvinced that the default of "no" for <link> is right. If somebody defines a link relation, and it doesn't make sense on <link>, then it appears that something is very wrong with the proposed semantics of the link relation.
> 
> -> Proposal: just define a flag that reflects the "hyperlink"/"external resource" distinction.
> 
> Best regards, Julian
> 
> _______________________________________________
> link-relations mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/link-relations

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 10 Aug 2010 21:31:38 +1000

Hi Ian,

This registration is a bit unusual, in that you're registering using whatwg.org URIs, when the W3C -- an organisation that the IETF recognises as producing Open Standards --- as per RFC2026 -- is producing a specification that is substantially the same.

While whatwg.org isn't necessarily precluded from meeting the prerequisites of Specification Required (and therefore making registrations), we want to make sure that this isn't conflicting with ongoing W3C work.

As such I've CC:ed the W3C's liaisons to the IETF for their comment. 

Philippe and Thomas: this is a registration request for new app data fields in the link relation registry, established by <https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/>. In particular, I'm looking for a statement of whether this conflicts with current W3C work, represents W3C consensus, etc. 

Regards,

---

From: Philippe Le Hegaret <[email-masked]>
Date: Tue, 10 Aug 2010 12:55:15 -0400

> Philippe and Thomas: this is a registration request for new app data fields in the link relation registry, established by <https://datatracker.ietf.org/doc/draft-nottingham-http-link-header/>. In p…

I see no reason here why the registration cannot point to the W3C
specification. The W3C HTML Working Group is producing the specification
for HTML, and pointing to somewhere would undermine the current process
and effort happening within W3C.

Ian, is there a reason why it isn't the case?

Philippe

---

From: Ian Hickson <[email-masked]>
Date: Tue, 10 Aug 2010 18:01:50 +0000 (UTC)

On Tue, 10 Aug 2010, Julian Reschke wrote:
> > > I explained that already. Define behavior for user agents (as 
> > > discussed last year), not HTML-specific validity constraints.
> > 
> > registrations for whether something is a hyperlink or an external 
> > resource link, and whether something is allowed on<link> or<a>/<area>? 
> > I suppose we could do that but that would just make the interface with 
> > the HTML spec a bit more complicated, and I don't understand how that 
> > would help anyone. Are other languages also interested in the 
> > distinction between hyperlinks and external resource links? I assumed 
> > this was just an HTML issue.
> 

I see.

> <a>/<area>: why is "bookmark" disallowed on link?

Because it wouldn't make any sense on <link> as defined. This is why 
conformance is an inherent part of the keywords. In fact, I am surprised 
other uses of these keywords don't have the same problem. For example, if 
we added "bookmark" (replacing the current registration which doesn't 
match real world usage of the keyword) to the registry, then a user agent 
would be unable to properly process it in an Atom environment or when used 
with a Link: header.

> - Unconvinced that <a> and <link> require different treatment.

The simplest example of this is rel=stylesheet.

> - Unconvinced that the IANA registry needs to carry metadata for HTML

It certainly would be inconvenient if the HTML spec had to use two 
registries.

> defines a link relation, and it doesn't make sense on <link>, then it appears
> that something is very wrong with the proposed semantics of the link relation.

There are very few where this is the case, but I don't see why that would 
mean a relation where this is the case is wrong.

> -> Proposal: just define a flag that reflects the "hyperlink"/"external

I'll have to think about this. It's unclear to me that this would be the 
most convenient mechanism.

On Tue, 10 Aug 2010, Mark Nottingham wrote:
>
> My (possibly and perhaps mercifully uninformed) view is that the issues 
> you're discussing are specific to HTML5, and should be decided in the 
> appropriate venue before bringing this forward for registration; the 
> link relations registry is relatively neutral about how and for what the 
> appdata fields are used for.

The issues had in fact been decided in an appropriate venue; I was 
surprised to find any resistance in the registration.

> I will say that appdata fields are expensive in the sense that once 
> they're added, they persist. So, we need to make sure that this is how 
> they'll actually be specified before they're added to the registry. This 
> is why adding new appdata fields is Specification Required, which 
> implies permanence.

Sure.

> P.S. Ian - when you do register something, convention dictates that the 
> template (which you've pasted below) actually go in the document itself.

Ah, ok. This is unclear in the registry's specification, which says to 
mail the template to the list.

On Tue, 10 Aug 2010, Mark Nottingham wrote:
> 
> This registration is a bit unusual, in that you're registering using 
> whatwg.org URIs, when the W3C -- an organisation that the IETF 
> recognises as producing Open Standards --- as per RFC2026 -- is 
> producing a specification that is substantially the same.
> 
> While whatwg.org isn't necessarily precluded from meeting the 
> prerequisites of Specification Required (and therefore making 
> registrations), we want to make sure that this isn't conflicting with 
> ongoing W3C work.

> Ian, is there a reason why it isn't the case?

The WHATWG is also producing the specification for HTML, so by that line 
of argument, pointing to somewhere other than the WHATWG would also 
undermine the current process and effort happening within the WHATWG.

But that's clearly nonsense. It doesn't make the slightest difference to 
ongoing work what the URLs are. :-)

I used the WHATWG URLs because the W3C doesn't publish a version of the 
"complete.html" file that I used in the registration, and because the 
WHATWG documents are generally more convenient to work with than the W3C 
ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG 
URLs are more stable than the W3C ones at this point (the W3C keeps taking 
things out, splitting the specs into other specs, etc), and I didn't want 
to have to keep updating the registration.

---

From: Ian Hickson <[email-masked]>
Date: Tue, 10 Aug 2010 18:51:06 +0000 (UTC)

On Tue, 10 Aug 2010, Ian Hickson wrote:
> 
> [...] ones (e.g. it has bug filing tools, nicer styling, etc). [...]

(And possibly most important of all, a more liberal copyright license, 
which is especially important here since the whole point of this 
registration is to allow people to use these definitions, which might 
include copying them into other specs, documentation, or software.)

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Aug 2010 21:04:21 +0200

> include copying them into other specs, documentation, or software.)

What's wrong with the BSD license used in 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-10#appendix-A.2>?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Aug 2010 21:27:48 +0200

On 10.08.2010 20:01, Ian Hickson wrote:
> ...
>> So, taking another example where the flags are different for<link>  and
> Because it wouldn't make any sense on<link>  as defined. This is why

So maybe the "new" definition is simply incorrect. Why did you change it?

>> - Unconvinced that<a>  and<link>  require different treatment.
>

That seems rather arbitrary, of course semantics for a/@rel=stylesheet 
*could* be defined (scoped CSS comes to mind).

> It certainly would be inconvenient if the HTML spec had to use two

As Mark noted, we probably should discuss whether use of relation types 
should affect document validity over in the HTML WG.

>> - Unconvinced that the default of "no" for<link>  is right. If somebody
>> defines a link relation, and it doesn't make sense on<link>, then it appears

If there are few, then this implies the default should not be "no".

That being said, I don't see anything in the definition of <link> which 
makes it different from what the HTTP Link header, for instance, 
defines. Maybe you could elaborate?

> surprised to find any resistance in the registration.

There was no conscious decision. As a matter of fact, there's a related 
bug (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=10172>), which 
hasn't been processed yet.

> "complete.html" file that I used in the registration, and because the

...but another one, which is "less complete", but happens to reflect the 
W3C's view of what HTML5 is... (you know that, I know that, but maybe 
some people looking at this thread do not)

> ones (e.g. it has bug filing tools, nicer styling, etc). Also, the WHATWG

But they are a pain to use in certain browsers due to their sheer size, 
and the scripts that are running upon load. (I'm even going to say that 
sending out these URIs almost is a DOS attack on some people's browsers).

> to have to keep updating the registration.

That's why we'd want the links to point at a published draft, not at 
work-in-progress.

Best regards, Julian

---

From: Philippe Le Hegaret <[email-masked]>
Date: Tue, 10 Aug 2010 15:13:03 -0400

On Tue, 10 Aug 2010, Ian Hickson wrote:
> Also, the WHATWG URLs are more stable than the W3C ones at this
> point (the W3C keeps taking things out, splitting the specs into
> other specs, etc), and I didn't want to have to keep updating the
> registration.

Correct, the consensus process of the W3C gives a chance to
organizations and individuals that are part of the Web community to
weight in on the content of the HTML specification.

In addition, I would note that it seems that this registration request
is premature and unstable, given the ongoing discussion within the HTML
Working Group, as pointed out by Julian Reschtke.

Regards,

Philippe

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 10 Aug 2010 22:44:14 +0200

>On Tue, 10 Aug 2010, Philippe Le Hegaret wrote:

(As an aside, please be aware that folding many messages into one makes
it harder to follow parts of a thread that one is interested in, harder
to ignore parts one is not interested in, harder to restore the context
of what is being discussed, easier for participants to reiterate points
that have already been made without the appearance of flooding the list
and in your case violates RFC 5322 which discourages forming References
headers from multiple parents which your mail client does. Please count
me among those who'd prefer you'd follow established conventions.)

>ones (e.g. it has bug filing tools, nicer styling, etc).

It is my understanding that this document is meant to be a stress test,
not an accessible specification. I believe you are well aware that this
version of your proposals locks up in many people's browser and I do not
see how a document, that is deliberately and unnecessarily made hard to
access, would be a suitable reference for the registry, if there are al-
ternatives available. It certainly locks up my browser of choice on any
computer I've ever used that was meant to support regular web browsing.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ian Hickson <[email-masked]>
Date: Tue, 10 Aug 2010 20:51:47 +0000 (UTC)

On Tue, 10 Aug 2010, Julian Reschke wrote:
> > conformance is an inherent part of the keywords. In fact, I am 
> > surprised other uses of these keywords don't have the same problem. 
> > For example, if we added "bookmark" (replacing the current 
> > registration which doesn't match real world usage of the keyword) to 
> > the registry, then a user agent would be unable to properly process it 
> > in an Atom environment or when used with a Link: header.
> 

To match real world usage.

> That seems rather arbitrary, of course semantics for a/@rel=stylesheet *could*
> be defined (scoped CSS comes to mind).

Well that's as may be, but currently reality isn't so. I presume you would 
agree that the registry should match reality.

> > > - Unconvinced that the default of "no" for<link> is right. If 
> > > somebody defines a link relation, and it doesn't make sense 
> > > on<link>, then it appears that something is very wrong with the 
> > > proposed semantics of the link relation.
> > 
> > There are very few where this is the case, but I don't see why that 
> > would mean a relation where this is the case is wrong.
> 

The "default" is merely a shorthand for not having to list every current 
relation and its new value; if you would rather I just list every relation 
I would be happy to do that.

> defines. Maybe you could elaborate?

Elaborate on what? I didn't mention Link: headers here? I would not want 
to presuppose how Link: headers should work; I've already sent feedback on 
the Link: header work which has been rejected (e.g. the HTTP Link: header 
doesn't define how rel=stylesheet should work with the CSSOM, but that is 
apparently out of scope of the Link: header), so clearly my understanding 
of that issue is not complete. As such, I would certainly not want to 
presume to apply conformance requirements on usage of that header.

> hasn't been processed yet.

That's a different venue. The registration template links to a WHATWG 
specification, where this issue was considered and decided appropriately.

> That's why we'd want the links to point at a published draft, not at 

The WHATWG spec is a published draft standard.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Aug 2010 11:04:47 +0200

> To match real world usage.

So by doing this you broke a use case which may not be widely in use, 
but is legitimate.

> agree that the registry should match reality.

The purpose of the registry is to tell people what the semantics of a 
link relation are. It really doesn't matter whether that's already 
implemented or not.

a/@rel=stylesheet indeed is not implemented (nor precisely defined), 
thus I have no problem with HTML validators pointing out that this is 
likely an authoring mistake. I just don't see why the type registry 
needs to contain this information.

If we augment it with flags for each and every context links are used 
in, it will become hard to maintain.

> I would be happy to do that.

Incorrect; it's also the default for new values.

>> That being said, I don't see anything in the definition of<link>  which

OK. So I'll just state: if a link relation doesn't have the same meaning 
in <link> and in Link: (the header field), there's a problem with the 
link relation, and we shouldn't register it.

> specification, where this issue was considered and decided appropriately.

So ignoring bug reports in W3C Bugzilla (which you yourself use as issue 
tracker for the WHATWG spec) means "was considered and decided 
appropriately"?

> The WHATWG spec is a published draft standard.

Obviously we disagree on this.

Best regards, Julian

---

From: Ian Hickson <[email-masked]>
Date: Wed, 11 Aug 2010 09:24:22 +0000 (UTC)

This thread is going off the topic of the field registrations, so I've 
only replied to the relevant parts here.

> needs to contain this information.

Understood.

> > > > There are very few where this is the case, but I don't see why 
> > > > that would mean a relation where this is the case is wrong.
> > > 
> > The "default" is merely a shorthand for not having to list every 
> > current relation and its new value; if you would rather I just list 
> > every relation I would be happy to do that.
> 

Surely for new values we would want the people submitting registrations to 
consider how their relations will work with existing applications and thus 
they will explicitly say what the values should be?

I would not at all feel comfortable defaulting all future values to either 
"hyperlink", "external resource link", or "annotation link". Which one 
applies should be carefully considered in each case. If no consideration 
is made, the only safe answer IMHO is "not allowed". This argues strongly, 
again IMHO, that we absolutely must have the latter as one of the possible 
options, if we are to have this field at all.

At this point my assumption is that the field registration is being 
rejected and we will have to deal with it outside the registry.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Aug 2010 12:10:35 +0200

> only replied to the relevant parts here.

Indeed.

> ..

Yes, but the thing we do not agree on is the level of detail required.

The application data registry was created to deal with the use case of 
distinguishing between links and external resources, for instance, so a 
client knows what to archive or to download for offline access.

I think this is a good use case, and it covers *most* of what you're 
looking for.

> options, if we are to have this field at all.

See above: by defining the flag in general terms instead of 
HTML-specific terms, the question simply goes away.

> rejected and we will have to deal with it outside the registry.

Again, please consider simplifying the application data, as originally 
discussed.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 Aug 2010 13:07:39 +1000

Ian,

As per the discussion on-list, we're rejecting these requests, and advising you to work with the W3C re: the references.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 Aug 2010 11:55:43 +1000

One bit of clarification: as far as I'm concerned, the semantics of these relations, their definition, etc. are up to the HTML WG; if there's a decision there to add these, we'll accept the registrations, as long as their status is unambiguous and the requirements for registration (stable reference or a reasonable expectation of one, etc.) are met.

Cheers,