Re: [link-relations] NEW APP DATA

Julian Reschke <julian.reschke@gmx.de> Tue, 10 August 2010 06:48 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 651ED3A6A2E for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 23:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.338
X-Spam-Level:
X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=-0.739, 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 DQznCghw3134 for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 23:48:30 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id D81BA3A690F for <link-relations@ietf.org>; Mon, 9 Aug 2010 23:48:29 -0700 (PDT)
Received: (qmail invoked by alias); 10 Aug 2010 06:49:01 -0000
Received: from p508FE025.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.224.37] by mail.gmx.net (mp001) with SMTP; 10 Aug 2010 08:49:01 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/nv3IUoKPnp7H2XdPrDm5HaIVi/GQVynr2sxtgAP HsqkUVhFJ1pEks
Message-ID: <4C60F657.6020108@gmx.de>
Date: Tue, 10 Aug 2010 08:48:55 +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>
In-Reply-To: <Pine.LNX.4.64.1008092141120.13310@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 06:48:32 -0000

On 09.08.2010 23:47, Ian Hickson wrote:
> ...
>> 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.
>
> 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.


>>>>> 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.
>>>
>>> How can I convince you?
>>
>> 1) You could re-consider the default ("not valid").
>
> 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.

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.

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

It would change the value the existing registrations get.

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

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

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

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

Best regards, Julian