Re: [link-relations] NEW APP DATA

Ian Hickson <ian@hixie.ch> Mon, 09 August 2010 21:47 UTC

Return-Path: <ian@hixie.ch>
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 983503A68D9 for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 14:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level:
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599]
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 H-RYCr-9KJSt for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 14:46:55 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id A31593A6878 for <link-relations@ietf.org>; Mon, 9 Aug 2010 14:46:55 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id A1A155E0069; Mon, 9 Aug 2010 14:47:29 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=hixie.ch; h=date:from:to:cc :subject:in-reply-to:message-id:references:mime-version: content-type; q=dns; s=hixie.ch; b=dVtMvtih9ANOp+lajrV2wUrjw6JEh 0bzVZq3FaF3X35Wo1PerCR4HyX/ogTLtysTGwxFElOXpl0nCcS2KI7kjnD0Zk+iN gC0gxOgLE1b3AvdKl1wEuKNFj2cFzhTCbhcyEP79JULKLRqJmWZA0C2sdiceaVFj bD8B2Ke2fFDg5k=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=hixie.ch; h=date:from:to :cc:subject:in-reply-to:message-id:references:mime-version: content-type; s=hixie.ch; bh=5wlurwpKkmkE74BziV893w8be+o=; b=Nbm S3wfr2YLp3RSCHFL+1luUQndjSshbzYvPDS1tifDTInVgyzreJDUp4UcUflUeY/7 Vu/qn1HX7flj+xiQeG0XCSvYqz4LwX6uZjjy8+7mqMKrAOBWDFFlEyPLj9oMYx7P eeNiWxEfl/ndYjmVdx2FtpYz4cdKBIVGoHUt/awY=
Received: from ps20323.dreamhostps.com (ps20323.dreamhost.com [69.163.222.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: internal@index.hixie.ch) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 92EEB5E005F; Mon, 9 Aug 2010 14:47:29 -0700 (PDT)
Date: Mon, 9 Aug 2010 21:47:29 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <4C6059A1.3000802@gmx.de>
Message-ID: <Pine.LNX.4.64.1008092141120.13310@ps20323.dreamhostps.com>
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>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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 21:47:00 -0000

On Mon, 9 Aug 2010, Julian Reschke wrote:
> On 09.08.2010 21:10, Ian Hickson wrote:
> > >
> > > Maybe it's just me, but I don't think it was designed for that.
> > 
> > Well, the field registry exists so as to make it possible to use the 
> > registry for HTML, as I understand it. But maybe I'm mistaken, and 
> > we're not supposed to use the registry for HTML relations? I'm 
> > confused now.
> 
> 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.


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

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.


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


> ..also, in the HTML WG, we really need to discuss whether conformance 
> checkers ought to check link relations.

That seems out of scope for this particular thread.


> > > 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.
> > 
> > Well it would be a pretty useless registry if it didn't match reality. 
> > :-) I would presume that if someone implemented such a value, getting 
> > it registered would be near-automatic, since otherwise we're just 
> > going to end up with clashes because people won't be able to register 
> > the values they're using, no?
> 
> If someone tried to register that relation, I'd probably propose to use 
> an extension relation type instead, or to prefix the short name with 
> something that makes it clear it's very application-specific.

Ok well that seems somewhat off-topic for this registration so I guess we 
should leave this for another thread.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'