Re: [link-relations] NEW APP DATA

Julian Reschke <julian.reschke@gmx.de> Mon, 09 August 2010 18:33 UTC

Return-Path: <julian.reschke@gmx.de>
X-Original-To: link-relations@core3.amsl.com
Delivered-To: link-relations@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 211FA3A6903 for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 11:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.383
X-Spam-Level:
X-Spam-Status: No, score=-103.383 tagged_above=-999 required=5 tests=[AWL=-0.784, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIKQg-1RHZ3K for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 11:33:08 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 20A5F3A67B3 for <link-relations@ietf.org>; Mon, 9 Aug 2010 11:33:07 -0700 (PDT)
Received: (qmail invoked by alias); 09 Aug 2010 18:33:40 -0000
Received: from p508FE3AB.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.227.171] by mail.gmx.net (mp056) with SMTP; 09 Aug 2010 20:33:40 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19noUlqs2xngYy3x7zctDoXLHcHfpp/s9EUs0112G QZzQNWb4i8tSDl
Message-ID: <4C604A01.8060604@gmx.de>
Date: Mon, 09 Aug 2010 20:33:37 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Ian Hickson <ian@hixie.ch>
References: <Pine.LNX.4.64.1008090401280.7470@ps20323.dreamhostps.com> <4C5FA78D.80108@gmx.de> <Pine.LNX.4.64.1008090838100.13471@ps20323.dreamhostps.com> <4C5FCC51.60108@gmx.de> <Pine.LNX.4.64.1008091738350.13471@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1008091738350.13471@ps20323.dreamhostps.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: link-relations@ietf.org
Subject: Re: [link-relations] NEW APP DATA
X-BeenThere: link-relations@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <link-relations.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/link-relations>
List-Post: <mailto:link-relations@ietf.org>
List-Help: <mailto:link-relations-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/link-relations>, <mailto:link-relations-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Aug 2010 18:33:14 -0000

On 09.08.2010 19:50, Ian Hickson wrote:
> On Mon, 9 Aug 2010, Julian Reschke wrote:
>>>
>>> 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, 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.

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

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

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

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

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.


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