Re: [link-relations] NEW APP DATA

Julian Reschke <> Mon, 09 August 2010 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 211FA3A6903 for <>; Mon, 9 Aug 2010 11:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.383
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cIKQg-1RHZ3K for <>; Mon, 9 Aug 2010 11:33:08 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 20A5F3A67B3 for <>; Mon, 9 Aug 2010 11:33:07 -0700 (PDT)
Received: (qmail invoked by alias); 09 Aug 2010 18:33:40 -0000
Received: from (EHLO []) [] by (mp056) with SMTP; 09 Aug 2010 20:33:40 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19noUlqs2xngYy3x7zctDoXLHcHfpp/s9EUs0112G QZzQNWb4i8tSDl
Message-ID: <>
Date: Mon, 09 Aug 2010 20:33:37 +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: 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