On 09.08.2010 10:43, Ian Hickson wrote:
> On Mon, 9 Aug 2010, Julian Reschke wrote:
>> On 09.08.2010 06:30, Ian Hickson wrote:
>>>
>>>       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
>>
>> 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?
>
> My apologies, I assumed that the answers to those questions were
> 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.

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

> 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

(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
> relation that creates one. Each keyword would have to be taken on a case-
> by-case basis.

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.

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

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