Re: [link-relations] NEW APP DATA

Julian Reschke <> Tue, 10 August 2010 06:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 651ED3A6A2E for <>; Mon, 9 Aug 2010 23:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.338
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DQznCghw3134 for <>; Mon, 9 Aug 2010 23:48:30 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D81BA3A690F for <>; Mon, 9 Aug 2010 23:48:29 -0700 (PDT)
Received: (qmail invoked by alias); 10 Aug 2010 06:49:01 -0000
Received: from (EHLO []) [] by (mp001) with SMTP; 10 Aug 2010 08:49:01 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/nv3IUoKPnp7H2XdPrDm5HaIVi/GQVynr2sxtgAP HsqkUVhFJ1pEks
Message-ID: <>
Date: Tue, 10 Aug 2010 08:48:55 +0200
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: Ian Hickson <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: Re: [link-relations] NEW APP DATA
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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