Re: [link-relations] NEW APP DATA

Ian Hickson <ian@hixie.ch> Tue, 10 August 2010 07:53 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 068E73A6A0A for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 00:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.473
X-Spam-Level:
X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 ZCispmL1-MGc for <link-relations@core3.amsl.com>; Tue, 10 Aug 2010 00:53:11 -0700 (PDT)
Received: from homiemail-a57.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 9EAD03A6902 for <link-relations@ietf.org>; Tue, 10 Aug 2010 00:53:11 -0700 (PDT)
Received: from homiemail-a57.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a57.g.dreamhost.com (Postfix) with ESMTP id 6F08620806B; Tue, 10 Aug 2010 00:53:46 -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=4dn7m1j/ffeMCzUrAWn+AIvgnCW2b 8vFbm98RBAtQDtyCLq0UlGc9Vmfy78tY+MIpk0FHHU1WYcwyEB+8joh9Lxf8P9fH tNv0VvKEUMrlcj84stsM1LiAPUolwkPP6h1Wx5ynyuBwsuzA13PKI/SI3oSj+rlv Y31wXMKZPVKYW4=
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=4a7qDvKWpDdh89dde+l9iC6slsM=; b=xfB PnBSzD4gOH3LuVhJ4X09v4reqa+EXC3vJjlwhI1InTt8mIfjuRuFI6waFu8X484G V2cMLSfRdQoEi56TMwWoCAkqi+z8gpMJqGOuS6dQZ6nVjkkzVV2XGH6ULAOLEdl1 zNqK3DbLDc6z7YYNIRxyVu/XW4Jwx1CxK7+kUTq8=
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-a57.g.dreamhost.com (Postfix) with ESMTPSA id 6A8CF208063; Tue, 10 Aug 2010 00:53:46 -0700 (PDT)
Date: Tue, 10 Aug 2010 07:53:46 +0000
From: Ian Hickson <ian@hixie.ch>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <4C60F657.6020108@gmx.de>
Message-ID: <Pine.LNX.4.64.1008100747210.22575@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> <Pine.LNX.4.64.1008092141120.13310@ps20323.dreamhostps.com> <4C60F657.6020108@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: Tue, 10 Aug 2010 07:53:13 -0000

On Tue, 10 Aug 2010, Julian Reschke wrote:
> > >
> > > 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 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.


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


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.

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