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

Marc Blanchet <marc.blanchet@viagenie.ca> Wed, 12 February 2014 13:58 UTC

Return-Path: <marc.blanchet@viagenie.ca>
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 7F3E71A0997 for <apps-discuss@ietfa.amsl.com>; Wed, 12 Feb 2014 05:58:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YWzOqog53qOt for <apps-discuss@ietfa.amsl.com>; Wed, 12 Feb 2014 05:58:00 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7DACF1A032E for <apps-discuss@ietf.org>; Wed, 12 Feb 2014 05:58:00 -0800 (PST)
Received: from [IPv6:2620::230:c000:d927:f33:246e:c68c] (unknown [IPv6:2620:0:230:c000:d927:f33:246e:c68c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 5D6314690F; Wed, 12 Feb 2014 08:57:59 -0500 (EST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <FE638099-6136-4264-845E-DA4AF6CDB1F6@mnot.net>
Date: Wed, 12 Feb 2014 08:57:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <47CBA1D2-E875-4DE3-81C3-ABDCE0A1C05C@viagenie.ca>
References: <40E62D1E-983E-465A-A169-2104BCFA587B@mnot.net> <0D6BE438-4886-44EC-963C-0F7EC20284A0@viagenie.ca> <FE638099-6136-4264-845E-DA4AF6CDB1F6@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1827)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
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: Wed, 12 Feb 2014 13:58:03 -0000

Le 2014-02-11 à 23:49, Mark Nottingham <mnot@mnot.net> a écrit :

> 
> On 12 Feb 2014, at 1:09 am, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
> 
>> yes. that is another way. it provides an additional level of indirection to remove the url component out from the spec. but it actually overload the registry with more data than typically necessary, and pretty repetitive. i.e. most likely every registry will have rel: domainlookup  href-template: http://exampleregistry1.com/lookup/{domain}, rel: domainlookup  href-template: http://exampleregistry2.com/lookup/{domain}, rel: domainlookup  href-template: http://exampleregistry3.com/lookup/{domain}.  Given the number of TLDs and that there are about 10 objects, we are multiplying the entries by 10, becomes pretty large registry operationally to parse.
> 
> Perhaps, but it may be possible to mitigate that, depending on the particulars of how it's going to be used and deployed.
> 
> E.g., have IANA run a lookup service themselves; e.g., http://iana.org/rdap/domain/foo.com
> 
> Or, define a document format that IANA points to in the registry, and *it* points to the various endpoints. 

I would suggest that you bring these discussion points to the weirds mailing list. The topic of bootstrap with various methods have been subject to many discussions so far. Not that we thought about everything, but some of your suggestions has been already debated.  There were no perfect solution, it has been a compromise between various. 

> 
> Also, if the data is that voluminous, it suggests that you may have a problem anyway; adding such repetitive information shouldn't affect the size of the response after gzip (which you'd want to use in any case) that much.

it is not the size of the response. it is the parsing. some of the use cases are clients that are doing a _lot_ of requests. Again, I think you should bring these discussion points to the weirds mailing list.  

> 
>>> 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.
>> 
>> btw, "them/they", "we":  we are the same IETF people. Why are we talking the "them" and "we" perspective?
> 
> Strangely, we *do* organise ourselves into groups and areas here.

right. but "we" are the same people. anyway. let's not continue that thread. 

Regards, Marc.

> Or are you proposing something more radical?
> 
> --
> Mark Nottingham   http://www.mnot.net/
>