Re: [link-relations] NEW APP DATA

Ian Hickson <ian@hixie.ch> Mon, 09 August 2010 19:09 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 31D853A693B for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 12:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.469
X-Spam-Level:
X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 u4lwvW79aKAx for <link-relations@core3.amsl.com>; Mon, 9 Aug 2010 12:09:46 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id B858A3A67F2 for <link-relations@ietf.org>; Mon, 9 Aug 2010 12:09:46 -0700 (PDT)
Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 0605B2C006B; Mon, 9 Aug 2010 12:10:21 -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=DhSnEGv5dMsSQ/heoNAaJhreNFYV3 0piejXMSknuNvhN6PZPp3wxKj3wICy9aVOQpJ14OkRvqDyCHdhB8DAoGpCtywtL0 ShvrZ1NgThjw/TAfYUUDLStm+A0PJul4lbVNtJRnuQo/HQxNSvYLoQ18Re6b/lC6 OhU9JHCzyvpx7I=
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=EaCB98xLO/qmMikxztz2Z4BTves=; b=Lu6 HtLFr4woD419jy0Rf9ahsFBzzhYvcNNA3MPjMIlJAuEgxBoO/DuAofFBurrAggCm ooQj/fpNj41p9GGj7wGjowjOp44LptNmLc/TEBSAePyDfjGH7/z+KS22nK/Drjxw j5sXXf3iAZIMbtVuWN0H9k3WpAOIj+UuvUCQW3/U=
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-a55.g.dreamhost.com (Postfix) with ESMTPSA id 015B82C006A; Mon, 9 Aug 2010 12:10:20 -0700 (PDT)
Date: Mon, 9 Aug 2010 19:10:20 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: Julian Reschke <julian.reschke@gmx.de>
In-Reply-To: <4C604A01.8060604@gmx.de>
Message-ID: <Pine.LNX.4.64.1008091859440.13471@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>
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 19:09:48 -0000

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

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.


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

I see.

How can I convince you?


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

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?


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

Are columns expensive?


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

That's possible, but that's an issue for HTML, not for the registry, no?


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

> Going back to the original issue (hopefully providing context for
> those who weren't there): we discussed application-specific data
> when we met in Santa Clara last November. The use case that was
> provided was a flag that would allow user agents to decide what kind
> of links need to be followed when going offline or archiving a
> resource. That makes a lot of sense, and I'd support that kind of
> flag, hopefully described in a way that isn't totally specific to
> HTML.

I have no opinion on this.


> What you are proposing is much more; it augments the link type
> registry with validation hints. I'm totally unconvinced that this is
> a good idea; in particular given the fact that it's an open question
> in the HTML WG how far validation should go with respect to these
> values.

I see. Not sure what to do about that.

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