Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?

Erik Wilde <dret@berkeley.edu> Tue, 11 February 2014 13:39 UTC

Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6201A0302 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Feb 2014 05:39:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxi0G0qE8Ylu for <apps-discuss@ietfa.amsl.com>; Tue, 11 Feb 2014 05:39:15 -0800 (PST)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id CDCA21A01F5 for <apps-discuss@ietf.org>; Tue, 11 Feb 2014 05:39:15 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1WDDYQ-00062E-8G; Tue, 11 Feb 2014 05:39:15 -0800
Message-ID: <52FA27FE.1070400@berkeley.edu>
Date: Tue, 11 Feb 2014 14:39:10 +0100
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net>
In-Reply-To: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] draft-ietf-weirds-bootstrap-00 and our lawn -- feedback?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2014 13:39:18 -0000

hello mark.

On 2014-02-11, 8:03 , Mark Nottingham wrote:
> If I were doing this protocol and I still wanted to use a registry (questionable IMHO), I'd allow each entry to contain a set of URL templates, identified by link relations, that allows a one-step lookup without baking in any URLs.
>
> E.g.,
>
> domain: example.com
>      rel: domainlookup    href-template: http://example.com/lookup/{domain}
>
> I'm very curious to hear what other APPS folks think about this -- especially those of a Web bent. We're trying to line up some conversations about this in London, and I'd like to inform them with the WG's perspective, rather than just my own.

i certainly like the idea of URI templates; they usually help to 
decrease coupling and make things clearer. but i think there still is 
some hesitation to use that particular spec. i think in part that's 
because it's not very easy to absorb when you just want to do simple 
things such as the one you're proposing. in part i think it's because 
there's an adoption problem: everybody is waiting for somebody else to 
be early adopters.

i am wondering how/where the variable {domain} would end up being 
"declared". your link hints draft and my link descriptions draft try to 
establish some way how this could be done, but afaict, currently that 
would be informal and maybe in the definition of the link relation?

[[ side note for a possible revision of RFC5988: currently, URI template 
is not even mentioned in "Web Linking", which makes sense, because it 
predates URI template. maybe a revision should change that. ]]

i only brief skimmed the draft-ietf-weirds-bootstrap draft, but it 
seemed to me that the spec really needing URI template help is 
http://tools.ietf.org/html/draft-ietf-weirds-rdap-query; section 3 has 
quite a bit of baked URI structure. so maybe getting the URI segments 
out of that draft would be the thing to look at?

------- feel free to skip, just a side note after skimming the draft:

on an unrelated angle, i am wondering about this part of the draft (the 
one you linked to):

"IANA should make sure that the service of those registries is able to 
cope with a larger demand and should take appropriate measures such as 
caching and load balancing."

afaict, most IANA registries are not really intended for runtime access. 
as is well-known (such as with W3C's HTML DTD URIs), even when a spec 
says that clients shouldn't blindly re-fetch every single time, there 
may be enough doing it anyway to have serious consequences. anyway, 
that's not the question you were asking, but was a rather curious part 
of that particular draft.

cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |