Re: [link-relations] NEW APP DATA

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:

> On 10.08.2010 09:53, Ian Hickson wrote:
>>> I explained that already. Define behavior for user agents (as discussed
>>> last year), not HTML-specific validity constraints.
>> 
>> 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.
> 
> 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).
> 
>>>> 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.
>>> 
>>> 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).
>> 
>> 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.
> 
> You are right. Sorry.
> 
> So, taking another example where the flags are different for <link> and <a>/<area>: why is "bookmark" disallowed on link?
> 
>> 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.
> 
> 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
> 
> _______________________________________________
> link-relations mailing list
> link-relations@ietf.org
> https://www.ietf.org/mailman/listinfo/link-relations

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