Re: [link-relations] NEW APP DATA

Julian Reschke <julian.reschke@gmx.de> Tue, 10 August 2010 08:16 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 E03493A6A7D for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 01:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.317
X-Spam-Level:
X-Spam-Status: No, score=-103.317 tagged_above=-999 required=5 tests=[AWL=-0.718, 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 R4vyKZC4UQ+g for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 01:16:07 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 8C98A3A6A26 for <link-relations@ietf.org>; Tue, 10 Aug 2010 01:16:06 -0700 (PDT)
Received: (qmail invoked by alias); 10 Aug 2010 08:16:38 -0000
Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp063) with SMTP; 10 Aug 2010 10:16:38 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/vDXcofcTvPRoyibmkCVkfjgkokR2CKjB7Vx0ny4 3QDZA0Achubx5B
Message-ID: <4C610AE2.5090306@gmx.de>
Date: Tue, 10 Aug 2010 10:16:34 +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> <4C604A01.8060604@gmx.de> <Pine.LNX.4.64.1008091859440.13471@ps20323.dreamhostps.com> <4C6059A1.3000802@gmx.de> <Pine.LNX.4.64.1008092141120.13310@ps20323.dreamhostps.com> <4C60F657.6020108@gmx.de> <Pine.LNX.4.64.1008100747210.22575@ps20323.dreamhostps.com>
In-Reply-To: <Pine.LNX.4.64.1008100747210.22575@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: Tue, 10 Aug 2010 08:16:08 -0000

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