From nobody Sun Mar 2 02:46:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C891A0CB8 for ; Sun, 2 Mar 2014 02:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.547, 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 2vm4f9NEJZWz for ; Sun, 2 Mar 2014 02:46:24 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFCC1A0CE2 for ; Sun, 2 Mar 2014 02:46:24 -0800 (PST) Received: from [IPv6:2620:0:230:2001::1001] (unknown [IPv6:2620:0:230:2001::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 17989403AC for ; Sun, 2 Mar 2014 05:46:20 -0500 (EST) From: Marc Blanchet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> Date: Sun, 2 Mar 2014 10:46:19 +0000 To: "" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/A7wGJyJKFuWpFPB85DT1V6ujgqs Subject: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 10:46:28 -0000 Hi, while doing the interop session this morning, I saw search results = where the servers were sending a "lot" of data, with all the json = formatting verbosity. However, one of the use cases for rdap queries is = _just_ to know if the record exists (domain name or else), for all the = clients that can't do this with EPP. The Whois "protocol" did not have = an explicit provision for this, since there was "no" protocol. I've been = told that people were having separate servers (using a different = hostnames) that provide just this use case: "whois -h special_server = domainname" and it _only_ returns a binary value: the record exists or = does not exist, no registration data sent. Therefore, the use case = already exists. And it would be much better to implement it in the = protocol than having separate hostnames. So I'm proposing to add an optional parameter to the query format that = would tell the server just return a binary value of existence of this = record. This would help all the clients that only want to know if that = record exists or not. This will help servers and infrastructure saving = processing and bandwidth.=20 While the probably main use cases is for domain names, it is actually = useful for all objects. For search queries, it could return either "no records match" or the = "short" list of matches, but without the registration data. Given the = last case (short list of matches), the response should then be formatted = as JSON, whatever there is no match or a list, for consistency. If people agree with that idea, I can compose some text to be added to = the query draft and the json response draft. Marc.= From nobody Sun Mar 2 03:28:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACB71A0D64 for ; Sun, 2 Mar 2014 03:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BdBOhoZGJbUf for ; Sun, 2 Mar 2014 03:28:44 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id 187681A0D58 for ; Sun, 2 Mar 2014 03:28:43 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUxMV6DsbIsLnnLxhxuUOULY5hKN18mLr@postini.com; Sun, 02 Mar 2014 03:28:42 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s22BSdbx020125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Mar 2014 06:28:39 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Sun, 2 Mar 2014 06:28:40 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet , "" Thread-Topic: [weirds] query optional parameter for existence of record Thread-Index: AQHPNgSw8o51PpYV/kyVfTqjMHPfJ5rNp9+A Date: Sun, 2 Mar 2014 11:28:38 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4936887D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> In-Reply-To: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PIbmC5yueaYFeKL9lEkobb_njdw Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 11:28:46 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Marc > Blanchet > Sent: Sunday, March 02, 2014 5:46 AM > To: > Subject: [weirds] query optional parameter for existence of record >=20 > Hi, > while doing the interop session this morning, I saw search results > where the servers were sending a "lot" of data, with all the json > formatting verbosity. However, one of the use cases for rdap queries is > _just_ to know if the record exists (domain name or else), for all the > clients that can't do this with EPP. The Whois "protocol" did not have > an explicit provision for this, since there was "no" protocol. I've > been told that people were having separate servers (using a different > hostnames) that provide just this use case: "whois -h special_server > domainname" and it _only_ returns a binary value: the record exists or > does not exist, no registration data sent. Therefore, the use case > already exists. And it would be much better to implement it in the > protocol than having separate hostnames. >=20 > So I'm proposing to add an optional parameter to the query format that > would tell the server just return a binary value of existence of this > record. This would help all the clients that only want to know if that > record exists or not. This will help servers and infrastructure saving > processing and bandwidth. > While the probably main use cases is for domain names, it is actually > useful for all objects. >=20 > For search queries, it could return either "no records match" or the > "short" list of matches, but without the registration data. Given the > last case (short list of matches), the response should then be > formatted as JSON, whatever there is no match or a list, for > consistency. >=20 > If people agree with that idea, I can compose some text to be added to > the query draft and the json response draft. Given that there are WHOIS servers that provide this functionality and it c= ould be used to provide more focused results I think this is a good idea. Scott From nobody Sun Mar 2 03:52:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DE11A0D73 for ; Sun, 2 Mar 2014 03:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no 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 YdhmqsrF08bq for ; Sun, 2 Mar 2014 03:52:44 -0800 (PST) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB3A81A0D71 for ; Sun, 2 Mar 2014 03:52:43 -0800 (PST) Received: from [IPv6:2001:67c:370:184:c24:84ee:6126:bd21] (unknown [IPv6:2001:67c:370:184:c24:84ee:6126:bd21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id D736D51CBBF; Sun, 2 Mar 2014 12:52:39 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1712D106-930E-4E29-8D93-022ADA05C2B7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: =?iso-8859-1?Q?Patrik_Wallstr=F6m?= In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4936887D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Sun, 2 Mar 2014 12:52:38 +0100 Message-Id: <73770BB2-36A1-4D99-AD5A-77CEEE35EAB7@blipp.com> References: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F4936887D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/cyaEpdVWYq5AGTjNP6tHUsy6ms8 Cc: "" Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 11:52:45 -0000 --Apple-Mail=_1712D106-930E-4E29-8D93-022ADA05C2B7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 02 Mar 2014, at 12:28, Hollenbeck, Scott = wrote: >=20 > Given that there are WHOIS servers that provide this functionality and = it could be used to provide more focused results I think this is a good = idea. +1 I think it=92s very common among the ccTLD community to have such a = service. The only component that was actually deployed from the IRIS = work was the DCHK (domain check availability). --Apple-Mail=_1712D106-930E-4E29-8D93-022ADA05C2B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJTExuGAAoJENv/4te3Yknyk2oP/2qARD5XJfPfmZAxvinwIbLt n0S//J7EJUKgmMhGxqHv11s7F33Ct8P+ygBnXqCZ5p+qPhlA5zxzmxEplQCbWrYa y4c21SJvHb93/Oq3rouH4Ceva3pCJeFC9+R885Po26ENBveZjvxZWgmb33FGfqfX a7euCt4vhpS5NZyaSsPQoUQNHtS7Z8z1Uyav+d6BRAWiAp/hYuEkk/AM3vMlGuP6 qYNajOV7ZGWtCejDZ7+cnOfAiwkhoYM8qGdFTkLUtOmELQ0q/42QooR0QitsuYHr 1O1mnHe5zC45wpI8yLA7ocCAND9U71I+TyJJJdQGOZnOC7naropw4oLPlztzBiP5 H4HQ8RiwhiUCY5wubbFsrQ6xUwRpZcrPMkVjAwqfO1t51CG/NR9KIDiy60AqR/sp VnREWa1MzKU3dyzZEROF0ItJaCzFXiOv4LyEG0tBjsupU7Qx1Z7Mpu5IssZEg+JX GHnBAX/2AAzAbfBFHlNP3cybH9T7XiW0WNRHPbpIXRc1dxJLHdYnFClCzjzYHoJh u4RnNd3zSbjP1TdZq230xkXCX3eviZ6JmvdjoC4ixP9UyLxK0/dwJuPf7p4i8B6s viQ0S7IfgKNYS8NzSx2QKopeWp2r5evkML+/n3yZf5DRqSxqMxBqxMmZX8YiCYeD pvj+Asz8yJ8qYEy+L38m =mu2K -----END PGP SIGNATURE----- --Apple-Mail=_1712D106-930E-4E29-8D93-022ADA05C2B7-- From nobody Sun Mar 2 04:01:53 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44D1A0CBC for ; Sun, 2 Mar 2014 04:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.501 X-Spam-Level: * X-Spam-Status: No, score=1.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 i3vtIbs-mEff for ; Sun, 2 Mar 2014 04:01:50 -0800 (PST) Received: from clone.registro.br (clone.registro.br [IPv6:2001:12ff:0:2::4]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7B1A0C2F for ; Sun, 2 Mar 2014 04:01:50 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id 9538424BE19; Sun, 2 Mar 2014 09:01:47 -0300 (BRT) Date: Sun, 2 Mar 2014 09:01:47 -0300 From: Frederico A C Neves To: Patrik =?iso-8859-1?Q?Wallstr=F6m?= Message-ID: <20140302120147.GB10457@registro.br> References: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F4936887D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <73770BB2-36A1-4D99-AD5A-77CEEE35EAB7@blipp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <73770BB2-36A1-4D99-AD5A-77CEEE35EAB7@blipp.com> Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VPb8N2n71Biz85D2HB-PVD07KoA Cc: "" Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 12:01:51 -0000 On Sun, Mar 02, 2014 at 12:52:38PM +0100, Patrik Wallström wrote: > > On 02 Mar 2014, at 12:28, Hollenbeck, Scott wrote: > > > > Given that there are WHOIS servers that provide this functionality and it could be used to provide more focused results I think this is a good idea. > > +1 > > I think it’s very common among the ccTLD community to have such a service. The only component that was actually deployed from the IRIS work was the DCHK (domain check availability). > I agree this is useful but afaik those services are run using completely different mechanisms from tcp/43, and it's normaly not a search service. Fred From nobody Sun Mar 2 07:27:04 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1C91A07C6 for ; Sun, 2 Mar 2014 07:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 Hq8itMhy4FqQ for ; Sun, 2 Mar 2014 07:27: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 728B41A07BA for ; Sun, 2 Mar 2014 07:27:00 -0800 (PST) Received: from porto.nomis80.org (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 2956340373 for ; Sun, 2 Mar 2014 10:26:56 -0500 (EST) Message-ID: <53134DBF.8040605@viagenie.ca> Date: Sun, 02 Mar 2014 15:26:55 +0000 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: weirds@ietf.org References: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> In-Reply-To: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/nbMUFzcXKi3nEhDXrMqyaT8dJNI Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 15:27:02 -0000 Le 2014-03-02 10:46, Marc Blanchet a crit : > So I'm proposing to add an optional parameter to the query format that would tell the server just return a binary value of existence of this record. I agree, and I propose to use the HEAD method for that. The client will get to see the response code (e.g. 200 or 404) and there will be no body. That's a thing that building on top of HTTP gives us for free. Anyone that has implemented a server using HTTP frameworks such as Tomcat/Jetty/etc. will have no extra code to write, just test and ensure it already works as it is supposed to, maybe add extra "shortut" optimization. Tthe only thing left to do would be to document it in the rdap-query draft as a good use case of the HEAD method. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Sun Mar 2 08:15:00 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D071A093A for ; Sun, 2 Mar 2014 08:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UwMpVo-IvfJE for ; Sun, 2 Mar 2014 08:14:54 -0800 (PST) Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by ietfa.amsl.com (Postfix) with ESMTP id 625CA1A0938 for ; Sun, 2 Mar 2014 08:14:54 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKUxNY+/uqNOnoV5Nr4lP1n3zrdO4k2U8x@postini.com; Sun, 02 Mar 2014 08:14:52 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s22GEp6G013110 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sun, 2 Mar 2014 11:14:51 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Sun, 2 Mar 2014 11:14:50 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format Thread-Index: Ac82MolDsRitnFyCSReCrfzGZShExQ== Date: Sun, 2 Mar 2014 16:14:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49368A9C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/E6ZUc5QIktfr6qxM4x31Uk3I0MI Subject: Re: [weirds] [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 16:14:57 -0000 > -----Original Message----- > From: rfc-dist-bounces@rfc-editor.org [mailto:rfc-dist-bounces@rfc- > editor.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: Sunday, March 02, 2014 11:10 AM > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org; json@ietf.org; rfc-editor@rfc- > editor.org > Subject: [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) > Data Interchange Format >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7158 >=20 > Title: The JavaScript Object Notation (JSON) > Data Interchange Format > Author: T. Bray, Ed. > Status: Standards Track > Stream: IETF > Date: March 2014 > Mailbox: tbray@textuality.com > Pages: 16 > Characters: 27451 > Obsoletes: RFC 4627 >=20 > I-D Tag: draft-ietf-json-rfc4627bis-10.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7158.txt >=20 > JavaScript Object Notation (JSON) is a lightweight, text-based, > language-independent data interchange format. It was derived from > the ECMAScript Programming Language Standard. JSON defines a small > set of formatting rules for the portable representation of structured > data. >=20 > This document removes inconsistencies with other specifications of > JSON, repairs specification errors, and offers experience-based > interoperability guidance. >=20 > This document is a product of the JavaScript Object Notation Working > Group of the IETF. >=20 > This is now a Proposed Standard. We might need to update some references... Scott From nobody Mon Mar 3 00:01:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE581A0A0D for ; Mon, 3 Mar 2014 00:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 o4m2_ss9SWdB for ; Mon, 3 Mar 2014 00:01:22 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 3C5211A0964 for ; Mon, 3 Mar 2014 00:01:17 -0800 (PST) X-EYOUMAIL-SMTPAUTH: zhoulinlin@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo95e6383c) (127.0.0.1) by 127.0.0.1 with SMTP; Mon, 03 Mar 2014 16:01:11 +0800 From: "Linlin Zhou" To: "'Simon Perreault'" , References: <9E0F1888-36B9-4B13-959C-F40B4A7E520F@viagenie.ca> <53134DBF.8040605@viagenie.ca> In-Reply-To: <53134DBF.8040605@viagenie.ca> Date: Mon, 3 Mar 2014 16:01:11 +0800 Message-ID: <00c201cf36b6$be3006c0$3a901440$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac82K904IKdN/qq4S6GU8yIk6o4tTAAioPNQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GKvbUhOt7sboa5ozl6rxPc0kELI Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:01:28 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Simon = Perreault > Sent: Sunday, March 02, 2014 11:27 PM > To: weirds@ietf.org > Subject: Re: [weirds] query optional parameter for existence of record >=20 > Le 2014-03-02 10:46, Marc Blanchet a =E9crit : > > So I'm proposing to add an optional parameter to the query format = that > would tell the server just return a binary value of existence of this record. >=20 > I agree, and I propose to use the HEAD method for that. The client = will get to > see the response code (e.g. 200 or 404) and there will be no body. >=20 +1 I agree this is a simple solution. > That's a thing that building on top of HTTP gives us for free. Anyone = that has > implemented a server using HTTP frameworks such as Tomcat/Jetty/etc. = will > have no extra code to write, just test and ensure it already works as = it is > supposed to, maybe add extra "shortut" > optimization. >=20 > Tthe only thing left to do would be to document it in the rdap-query = draft as a > good use case of the HEAD method. >=20 > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Mon Mar 3 01:45:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698101A0DA4 for ; Mon, 3 Mar 2014 01:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no 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 JfZB6l9y6yQQ for ; Mon, 3 Mar 2014 01:45:16 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1F16D1A0770 for ; Mon, 3 Mar 2014 01:45:13 -0800 (PST) Received: (qmail 81185 invoked from network); 3 Mar 2014 09:45:11 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 3 Mar 2014 09:45:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53144f27.xn--9vv.k1403; i=johnl@user.iecc.com; bh=oL4BBZxx3u+lruzDuWGJFIZpDLUSEohbkfuknijRyZc=; b=vJGKU859O2I/WJMgG+PvjescuC3x2NTxkfgaolkpzAcoJv5RpH3RK6gIXcxOwn8NThEFeLkoGygUrnu7DNvXwtqVM90NeVcqfapageF5UfPO+Qa4Xd8OGFybspLMytA8e7f9I60CtTV3BqT57I9067JQqGOKtui+o60CLWqCpMJS6OHJ6Dbrcg7aaNCyMXpTI10S5iG6ZnWC3cjN01PlTafghg6pfyKyp9Pek3GrsJ/szcq5ww2qZmoV+mRF1jxJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53144f27.xn--9vv.k1403; bh=oL4BBZxx3u+lruzDuWGJFIZpDLUSEohbkfuknijRyZc=; b=lA1LeBUjNwzQi1rxHNAHOuWK+Smi6Ux09ONgJ1Y8ElLfrKYcxKzbzeoqgR5DUCE58TEbnD6susR1vb5utgk3vXnPVbtilYqBC8TMdSPscMzCu7yEGYhmD+T29VRBo93D6uOVvEOcqEALCntYZJmBf2UL3WiguEJBSMNCQrN1XC+v4fwMQBIltE2mptPkpqY0cua1C6CcVoJvf1WOUPUjDV0tMMZJn1iUwLxaft/d84zQhK61IrCqZi2zi/zuQGL0 Date: 3 Mar 2014 09:44:48 -0000 Message-ID: <20140303094448.2646.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <53134DBF.8040605@viagenie.ca> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rPhnj35WbkLB8wOnE8wEa8LNLCU Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:45:22 -0000 >I agree, and I propose to use the HEAD method for that. The client will >get to see the response code (e.g. 200 or 404) and there will be no body. If the response code does indeed reliably tell whether it exists, I agree, this is way easier than anything else we're going to invent. R's, John From nobody Mon Mar 3 03:18:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7981A0F35 for ; Mon, 3 Mar 2014 03:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 oUT-6KfvfJL0 for ; Mon, 3 Mar 2014 03:18:23 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 56EC21A0F25 for ; Mon, 3 Mar 2014 03:18:23 -0800 (PST) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 718CC4036A for ; Mon, 3 Mar 2014 06:18:13 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Marc Blanchet In-Reply-To: <20140303094448.2646.qmail@joyce.lan> Date: Mon, 3 Mar 2014 11:18:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3CBAD799-14DF-47D1-BB37-8F58A82DC212@viagenie.ca> References: <20140303094448.2646.qmail@joyce.lan> To: "" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/g_DY-XCjVshTseV9LbV50eg9CEg Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:18:25 -0000 There are two use cases: a) ask for a single object. b) a search for potentially multiple objects match. b.1 just want to know if there is any match for the search string I = sent. b.2 want to get the list of matches but without the registration data. a) fits well with HEAD. We don't have to invent anything, just put some = text in the document. b) could use HEAD. In this context, a positive response would only say = there is a match, but would not return the actual matches. This is still = useful information for the requestor. (use case b.1) But, if the = requestor is only looking for the list of matches (case b.2), then he = has to redo another query, normal this time, doing the normal query will = return the "large" amount of data, that the requestor might not be = interested, but just the object matches (i.e. domain names, not the = registrant data). Therefore, HEAD is not sufficient for case b.2. since I see good support of the overall idea, I'll suggest some text = soon. Marc. Le 2014-03-03 =E0 09:44, John Levine a =E9crit : >> I agree, and I propose to use the HEAD method for that. The client = will >> get to see the response code (e.g. 200 or 404) and there will be no = body. >=20 > If the response code does indeed reliably tell whether it exists, I > agree, this is way easier than anything else we're going to invent. >=20 > R's, > John >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Mon Mar 3 03:32:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1121A000E for ; Mon, 3 Mar 2014 03:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.736 X-Spam-Level: X-Spam-Status: No, score=-0.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3] autolearn=no 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 U5YTZd0g6YFJ for ; Mon, 3 Mar 2014 03:32:02 -0800 (PST) Received: from vic20.blipp.com (cl-682.sto-01.se.sixxs.net [IPv6:2001:16d8:ff00:2a9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6940A1A003A for ; Mon, 3 Mar 2014 03:31:57 -0800 (PST) Received: from eduroam-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:152:90c4:c80f:db5c:47e2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by vic20.blipp.com (Postfix) with ESMTPSA id 45EC5381D4; Mon, 3 Mar 2014 12:31:53 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_F997423D-68F3-4CA9-BA24-C5D222BBA331"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: =?iso-8859-1?Q?Patrik_Wallstr=F6m?= In-Reply-To: <3CBAD799-14DF-47D1-BB37-8F58A82DC212@viagenie.ca> Date: Mon, 3 Mar 2014 12:31:50 +0100 Message-Id: <9AC44EC9-FDFA-4204-A636-386AB3E2D6F8@blipp.com> References: <20140303094448.2646.qmail@joyce.lan> <3CBAD799-14DF-47D1-BB37-8F58A82DC212@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lGi4_2F58BclR7N2PGiEDpTyyGc Cc: "" Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:32:04 -0000 --Apple-Mail=_F997423D-68F3-4CA9-BA24-C5D222BBA331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 03 Mar 2014, at 12:18, Marc Blanchet = wrote: > There are two use cases: > a) ask for a single object. > b) a search for potentially multiple objects match. > b.1 just want to know if there is any match for the search string I = sent. > b.2 want to get the list of matches but without the registration data. >=20 > a) fits well with HEAD. We don't have to invent anything, just put = some text in the document. > b) could use HEAD. In this context, a positive response would only say = there is a match, but would not return the actual matches. This is still = useful information for the requestor. (use case b.1) But, if the = requestor is only looking for the list of matches (case b.2), then he = has to redo another query, normal this time, doing the normal query will = return the "large" amount of data, that the requestor might not be = interested, but just the object matches (i.e. domain names, not the = registrant data). Therefore, HEAD is not sufficient for case b.2. >=20 > since I see good support of the overall idea, I'll suggest some text = soon. There is actually one more use case, which I have implemented for .SE. = If a user (through a registrar or whatever) lookups a domain for = availability, the user also wants to know if the name is allowed for = registration (policy issue, or whatever the reason may be). So there is = another potential message going back to the user, =93not valid=94. --Apple-Mail=_F997423D-68F3-4CA9-BA24-C5D222BBA331 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJTFGgmAAoJENv/4te3YknyPHUQAIy9PpDcBZb3foXAGMlybZ1q rAqbS6BUcNvmesfj/2dmyco1KGbps/ngSyW/zEbmtHGtCINa6Kw10X1HL8VLbDW4 cio0q2Ciz+ej++aJKviUwemgBt+QejFqyXlOgTxYdvnOyoJQdFdhqjCZSI3CPtwG VE1HXrJ2RI3khBDSkcMvKNRhkqwGJT1Ne475+Y/IEuKeV+cXvKaXIKg1exIrtETj R9ncW1L3Z/IgS2k01dBh4IYsUoueUXkH+eUg9PVX9WC1cSWknz0R4T7pjZv3qjO/ hOc5ie9++DJyTqcYrsF3yWNG08esroiw8Wnu5VoMhV3gKdP+WYoNmJfiGihvLK/i svBlogLlQjJRLg7PvsR7WF30Y6vEfgQnl7urBExBgH2u9Cum0cA6G7X7kP3POaC7 DaEeFhqwdZDMEZILs4GQBGpk4tTOscuzutmviHiLlE2FYDs5M+APhNt5XZOGMYXo PXwo5dnE1MB5Ba+iSKjXeZo1enDlBhSq5P9XAEtyao7sMiC52Mt+85/kGlmU79zp myqmqHTz2wIexneSyGmZqQbCW70rBPmNaOaHXK+mA4z/XKmT3L8rS8vjexFIMnd5 H+Ds6rD9HYvXrZPOqP54uqegYZhKHzBz+mg1d54Hj7emhd4uHvZ3evJ5FXwp0A+J LbpIO6X6qfsrjAS/rD7x =svFN -----END PGP SIGNATURE----- --Apple-Mail=_F997423D-68F3-4CA9-BA24-C5D222BBA331-- From nobody Mon Mar 3 03:36:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3CFD1A0048 for ; Mon, 3 Mar 2014 03:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_BR=0.955, HOST_EQ_BR=1.295, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, 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 H8ETX9EyZshB for ; Mon, 3 Mar 2014 03:36:46 -0800 (PST) Received: from clone.registro.br (clone.registro.br [200.160.2.4]) by ietfa.amsl.com (Postfix) with ESMTP id 459891A0045 for ; Mon, 3 Mar 2014 03:36:46 -0800 (PST) Received: by clone.registro.br (Postfix, from userid 1000) id F16A424BDD1; Mon, 3 Mar 2014 08:36:42 -0300 (BRT) Date: Mon, 3 Mar 2014 08:36:42 -0300 From: Frederico A C Neves To: Marc Blanchet Message-ID: <20140303113642.GD60404@registro.br> References: <20140303094448.2646.qmail@joyce.lan> <3CBAD799-14DF-47D1-BB37-8F58A82DC212@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CBAD799-14DF-47D1-BB37-8F58A82DC212@viagenie.ca> Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/IkOnkut_9hI3z7UDxjBtrBpuiFU Cc: "" Subject: Re: [weirds] query optional parameter for existence of record X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:36:47 -0000 On Mon, Mar 03, 2014 at 11:18:03AM +0000, Marc Blanchet wrote: > There are two use cases: > a) ask for a single object. > b) a search for potentially multiple objects match. > b.1 just want to know if there is any match for the search string I sent. > b.2 want to get the list of matches but without the registration data. The use case that I mentioned earlier in this thread is a variation of your a use case. It's the availabity service that some TLDs have developed to remove load from whois providing a better service. Ask for a single object, if not present at the repository (available for registration), if present available alternatives could be listed. Fred From nobody Mon Mar 3 03:59:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AEB1A003D for ; Mon, 3 Mar 2014 03:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 hzJv_MGFcguA for ; Mon, 3 Mar 2014 03:59:35 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 84FA31A0007 for ; Mon, 3 Mar 2014 03:59:35 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id hz1so3683734pad.8 for ; Mon, 03 Mar 2014 03:59:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dpxtmGlwjsm0NS0u9BR+bC4nmsEZB+a8YJBBDgDpII4=; b=MK0jdcicCsHoIj3YpW4jXe9W9LdvTYGvbpfpPaIM+L6wb9+IhjcrHtbLhpj5Rn7Z/l 1cBMY8yDt26hTP3qSg1P25GR8lpgWP2Y3UzQf4qHkTdus07EzqkO2YELPYg1ScNx4tJP WuIn1iGXxaG1+og+ToyST1qzxUGbVTvQDNqh5bDmg6QH9GzDCkP+MRpT43wP9lHL3dzj rl3Os2Yh47LrZrwVNPjMT3ay0mGOK2Z4tB+oWv6zGXhdHdMBPjzuYtgk3eZmr7hzSCxx csQGBhYopZnDaR7m0vc1w8Ybh5fU/ZdHD47WeVlQTL1dBFXpy13rxw4TPq7fte7ymxei FcPw== MIME-Version: 1.0 X-Received: by 10.68.170.228 with SMTP id ap4mr3043697pbc.149.1393847971834; Mon, 03 Mar 2014 03:59:31 -0800 (PST) Received: by 10.66.220.102 with HTTP; Mon, 3 Mar 2014 03:59:31 -0800 (PST) Date: Mon, 3 Mar 2014 11:59:31 +0000 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b672dfa3b6f1304f3b28549 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fpnEsL-NPmwmTAN-2GOucs5mUoc Subject: [weirds] WEIRDS URI Design team meeting X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:59:36 -0000 --047d7b672dfa3b6f1304f3b28549 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, We've commissioned a small design team to meet tomorrow (Tuesday) at lunch in London to discuss a path forward on the WEIRDS URI issue. The usual suspects from WEIRDS will meet with Mark Nottingham who is author of the URI document that's about to go to IETF Last Call from within APPSAWG. The design team will return a recommendation to the working group meeting Tuesday afternoon, assuming it reaches such a conclusion. Note that this message does not comprise an endorsement of what the design team will recommend; the working group as a whole still needs to discuss and accept the recommendation. -MSK, WEIRDS co-chair --047d7b672dfa3b6f1304f3b28549 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

We've commissioned = a small design team to meet tomorrow (Tuesday) at lunch in London to discus= s a path forward on the WEIRDS URI issue.=A0 The usual suspects from WEIRDS= will meet with Mark Nottingham who is author of the URI document that'= s about to go to IETF Last Call from within APPSAWG.=A0 The design team wil= l return a recommendation to the working group meeting Tuesday afternoon, a= ssuming it reaches such a conclusion.

Note that this message does not comprise an endorsement of what the des= ign team will recommend; the working group as a whole still needs to discus= s and accept the recommendation.

-MSK, WEIRDS co-chair

--047d7b672dfa3b6f1304f3b28549-- From nobody Mon Mar 3 05:39:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 439AB1A0128 for ; Mon, 3 Mar 2014 05:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 p3oqhwHVXFq7 for ; Mon, 3 Mar 2014 05:39:48 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id E42251A00FE for ; Mon, 3 Mar 2014 05:39:47 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUxSGIbFcEIxz0wC2k0yMvQSz2jbV9Bng@postini.com; Mon, 03 Mar 2014 05:39:45 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s23Ddibl015671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 08:39:44 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 08:39:44 -0500 From: "Summers, Dow" To: "weirds@ietf.org" Thread-Topic: Search pattern formats and base url's Thread-Index: AQHPNuYJ1zzIKzRdSkatau5R02H8ag== Date: Mon, 3 Mar 2014 13:39:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="utf-8" Content-ID: <5E801E37AFB98742ABFE5CC7CC88F9CB@verisign.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/cC5pMyG8BE2tQr5LMSAJGtm1O0M Subject: [weirds] Search pattern formats and base url's X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:39:50 -0000 DQogICBBZnRlciB0aGUgaW50ZXIgb3B0IG9uIFN1bmRheSBJIGZvdW5kIHR3byBwb2ludHMgaW4g dGhlIHF1ZXJ5IGRyYWZ0DQp0aGF0IEkgd291bGQgbGlrZSB0byBnZXQgY2xhcmlmaWVkLiAgIFRo ZSBmaXJzdCBpcyBhbiBhc3N1bXB0aW9uIGluIHRoZQ0KZm9ybWF0IG9mIHRoZSBzZWFyY2ggcGF0 dGVybnMuICBUaGUgZG9jdW1lbnQgZ2l2ZXMgdGhlIGV4YW1wbGUgb2YgYSBzZWFyY2gNCnBhdHRl cm4gb2Yg4oCcZXhhbXBsZSouY29t4oCdLiAgSSB3b3VsZCBsaWtlIHRvIGhhdmUgY29uc2lzdGVu Y3kgaW4gb3VyIHNlYXJjaA0KZXhwcmVzc2lvbnMuICAgIEkgaW1wbGVtZW50ZWQgdGhpcyBmZWF0 dXJlIHVzaW5nIHRoZSBQT1NJWCByZWdleCBwYXR0ZXJuDQrigJxleGFtcGxlLipcLmNvbeKAnS4g IFRoaXMgd291bGQgbWF0Y2gg4oCcbnMxLmV4YW1wbGUuY29t4oCdIGFuZA0K4oCcbnMxLWV4YW1w bGUtZG9tYWluLmNvbeKAnS4gICBBZnRlciB0YWxraW5nIHdpdGggb3RoZXJzIEkgd291bGQgcHJv cG9zZSB0aGUNCndlIGFkZCB0ZXh0IHRvIHN0YXRlIHRoZXJlIGlzIGFuIGltcGxpZWQgYmVnaW5u aW5nIGFuZCBlbmQgb2Ygc3RyaW5nDQptYXJrZXJzLCBhbmQgdGhlIOKAnGV4YW1wbGUqLmNvbeKA nSBzZWFyY2ggd291bGQgYmUgdHJhbnNsYXRlZCBpbnRvIHJlZ2V4IGFzDQrigJxeZXhhbXBsZS4q XC5jb20k4oCdLiAgSSBkb27igJl0IHdhbnQgdG8gaW1wbHkgSSB3YW50IHJlZ2V4LiAgSSBhbSBq dXN0IHVzaW5nDQpQT1NJWCBzdGFuZGFyZCBhcyBhIHdheSB0byBkZXNjcmliZSBmZWF0dXJlcyBp biBhIGRlZmluZWQgZm9ybWF0Lg0KDQogIFRoZSBzZWNvbmQgaXMgdGhlIHVzZSBvZiB0aGUg4oCc Ly53ZWxsLWtvd24vcmRhcOKAnSByb290LiAgICBUaGUgdGV4dCBiZWxvdw0KaXMgd2hhdCBpcyBj dXJyZW50bHkgaW4gcmV2IDEwIG9mIHRoZSBxdWVyeSBkb2N1bWVudC4NCg0KICAgTm90ZSB0aGF0 IHBhdGggYW5kIHF1ZXJ5IGluZm9ybWF0aW9uIGluIHRoZSBiYXNlIFVSTCBhcmUgbm90IHVzZWQs DQogICBiZWNhdXNlIHRoZSB3ZWxsLWtub3duIFVSTCBpcyByb290ZWQgYXQgIi8ud2VsbC1rbm93 bi9yZGFwIjsgZm9yDQogICBleGFtcGxlLCBpZiBhIHJlZ2lzdHJ5IHByb3ZpZGVzICJodHRwOi8v ZXhhbXBsZS5jb20vb3RoZXIvcGF0aCIgYXMgYQ0KICAgYmFzZSBVUkwsIFJEQVAgcXVlcnkgVVJM cyB3aWxsIHN0aWxsIGJlZ2luIHdpdGggImh0dHA6Ly9leGFtcGxlLmNvbS8NCiAgIC53ZWxsLWtu b3duL3JkYXDigJ0uDQoNCiBJIGRvbuKAmXQgaGF2ZSBhIHByb2JsZW0gdXNpbmcg4oCcLy53ZWxs LWtvd24vcmRhcOKAnS4gIEkgd291bGQgcmVjb21tZW5kDQpkcm9wcGluZyB0aGlzIHBhcmFncmFw aC4gVGhlIHByb2NlZWRpbmcgcGFyYWdyYXBocyBkZWZpbmUgc3RydWN0dXJlIG9mIHRoZQ0KcGF0 aC4gIFRoaXMgcGFyYWdyYXBoIGRlc2NyaWJlcyBhIGNvbnZlcnNpb24gZnJvbSBhIHByZXZpb3Vz IGRyYWZ0Lg0KDQogIFdlIGhhdmUgbXVsdGlwbGUgZG9tYWlu4oCZcyBzZXJ2ZWQgb3V0IG9mIGEg c2luZ2xlIGRhdGFiYXNlKCAuQ09NLCAuTkVULA0K4oCmKS4gIEkgaGFkIG9yaWdpbmFsbHkgdXNl ZCB0aGUgYmFzZSB1cmwgdG8gZGV0ZXJtaW5lIHRoZSBuYW1lIG9mIHRoZQ0KZG9tYWluIGJlaW5n IHNlYXJjaGVkKA0KaHR0cDovL3RsYWIudmVyaXNpZ24uY29tL0NPTS9uYW1lc2VydmVyL25zMS5l eGFtcGxlLm5ldCkuICBNeSBjdXJyZW50DQpzdHJhdGlneSB3aWxsIGJlIHRvIGVuY29kZSB0aGUg bmFtZSBvZiB0aGUgZG9tYWluIGludG8gdGhlIGhvc3RuYW1lIG9mIFVSTA0KKCBodHRwOi8vQ09N LnRsYWIudmVyaXNpZ24uY29tLy53ZWxsLWtub3duL3JkYXAvbmFtZXNlcnZlcg0KPGh0dHA6Ly9D T00udGxhYi52ZXJpc2lnbi5jb20vLndlbGwta25vd24vcmRhcC9uYW1lc2VydmVyLz4vbnMxLmV4 YW1wbGUubmV0DQopLiAgRG9lcyBhbnlvbmUgaGF2ZSBhIGJldHRlciBpZGVhIG9uIGhvdyB0byBw YXNzIHRoZSBzY29wZSBvZiBhIHF1ZXJ5Pw0KDQrigJQNCkRvdyBTdW1tZXJzDQoNCuKAnFRoaXMg bWVzc2FnZSAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVz c2VkLCBhbmQgbWF5IGNvbnRhaW4gaW5mb3JtYXRpb24gdGhhdCBpcyBub24tcHVibGljLCBwcm9w cmlldGFyeSwgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsIGFuZCBleGVtcHQgZnJvbSBkaXNjbG9z dXJlIHVuZGVyIGFwcGxpY2FibGUgbGF3IG9yIG1heSBiZSBjb25zdGl0dXRlZCBhcyBhdHRvcm5l eSB3b3JrIHByb2R1Y3QuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlv dSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIG5vdGlm eSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgaW1tZWRpYXRlbHku 4oCdDQo= From nobody Mon Mar 3 07:58:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424C91A022E for ; Mon, 3 Mar 2014 07:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vhQUvCFcZtyu for ; Mon, 3 Mar 2014 07:58:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5831E1A023A for ; Mon, 3 Mar 2014 07:58:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303155830.1083.42131.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 07:58:30 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/iA9codUlIQOWbzA57GBDEw2ki9U Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 15:58:33 -0000 Changed milestone "Draft describing bootstrapping protocol to the IESG", added draft-ietf-weirds-bootstrap to milestone. URL: http://datatracker.ietf.org/wg/weirds/charter/ From nobody Wed Mar 5 04:58:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843131A00A9 for ; Wed, 5 Mar 2014 04:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.703 X-Spam-Level: X-Spam-Status: No, score=0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 EAXxsQEJ6SZO for ; Wed, 5 Mar 2014 04:58:02 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [120.29.249.162]) by ietfa.amsl.com (Postfix) with ESMTP id C369C1A00A2 for ; Wed, 5 Mar 2014 04:58:01 -0800 (PST) Received: from unknown (HELO ausregistry.com.au) ([10.30.220.61]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 05 Mar 2014 23:56:17 +1100 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.91]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 23:58:01 +1100 From: James Mitchell To: "weirds@ietf.org" Thread-Topic: Response for variant domain names Thread-Index: AQHPOHKJH2ZUMxJask6jy+hlpJADOw== Date: Wed, 5 Mar 2014 12:58:00 +0000 Message-ID: Accept-Language: en-NZ, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [31.133.166.191] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CF3CC51625D13jamesmitchellausregistrycomau_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/pB72of_ASJfHWqnbGbS8tOM-JkI Subject: [weirds] Response for variant domain names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 12:58:04 -0000 --_000_CF3CC51625D13jamesmitchellausregistrycomau_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, I mentioned changing the response for variants at the meeting yesterday. Th= is is what I have in mind: query: /domain/blocked-variant.tld Response: { "ldhName" : "blocked-variant.tld" "status" : =93unregistered" "links" : [ { "value" : "http://example.com/domain/blocked-variant.tld", "rel" : "primary-domain=94, //??? "href" : "http://example.com/domain/primary-domain.tld", "type" : "application/rdap+json" } ] // optionally include the primary domain response here } I prefer this approach because the response is for the name present in the = query, not for another name. The response clearly relates the queried name = to the primary name via the status =96 not all registries compute or store = all variants, and listing all (blocked) variants in a response is out of th= e question (exponential explosion). Further, a redirect does not quite work= , as (active) variants have information beyond a status, for example the da= te time the variant became activated, and some may even contain separate de= legation information (some registries accept DS per variant instead of a DN= SKEY for all variant names AFAIK). Further, the variant relation values and definitions should be updated. * =93unregistered=94 is the logical opposite of =93registered=94 and th= e description should say exactly that. I disagree with the existing descrip= tion as the name is =93in" the registry, but not with full domain data. IMO= a weirds server can stop at the registered and unregistered statuses. * Unregistered names can be subdivided into two buckets describing weth= er the name is available for registration, =93blocked=94 or =93withheld=94.= IMO the distinction is relevant only in the provisioning protocol, however= some weirds servers may choose to make the distinction. Unfortunately neit= her status is currently available (withheld is effectively available by cho= osing either registration restricted or open registration - the latter brin= g the variant relation into question IMO). I=92d prefer removing =93registr= ation restricted=94 and =93open registration=94 in favour of adding both = =93blocked=94 and =93withheld=94. Further, it should be responsibility of the client to infer =93unregistered= =94 from =93blocked=94 or =93withheld=94 instead of the server returning tw= o statuses. Regards, James Mitchell ARI Registry Services --_000_CF3CC51625D13jamesmitchellausregistrycomau_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1F2608E2EDC1E24BB3FB6AA880990F38@ausregistry.com.au> Content-Transfer-Encoding: quoted-printable
All,

I mentioned changing the response for variants at the meeting yesterday. Th= is is what I have in mind:

query: /domain/blocked-variant.tld
Response:
{
"ldhNa= me" : "blocked-variant.tld"
"statu= s" : =93unregistered"
"links" :
[
{
"value" : "http://example.com/do= main/blocked-variant.tld",
"rel" : "primary-domain=94, //??= ?
"href" : "http://example.com/dom= ain/primary-domain.tld",
"type" : "application/rdap+j= son"
}
]
// optional= ly include the primary domain response here
}

I prefer this approach because the response is for the name present in the = query, not for another name. The response clearly relates the queried name = to the primary name via the status =96 not all registries compute or store = all variants, and listing all (blocked) variants in a response is out of the question (exponential explosion). Fur= ther, a redirect does not quite work, as (active) variants have information= beyond a status, for example the date time the variant became activated, a= nd some may even contain separate delegation information (some registries accept DS per variant instead of a= DNSKEY for all variant names AFAIK).

Further, the variant relation values and definitions should be updated.
  • =93unregistered=94 is the logical opposite of =93registered=94 and the = description should say exactly that. I disagree with the existing descripti= on as the name is =93in" the registry, but not with full domain data. = IMO a weirds server can stop at the registered and unregistered statuses.
  • Unregistered names can be subdivided in= to two buckets describing wether the name is available for registration, = =93blocked=94 or =93withheld=94. IMO the distinction is relevant only in th= e provisioning protocol, however some weirds servers may choose to make the distinction. Unfortunately neither status is currently available (withheld= is effectively available by choosing either registration restricted or ope= n registration - the latter bring the variant relation into question IMO). = I=92d prefer removing =93registration restricted=94 and =93open registration=94 in favour of adding both =93bloc= ked=94 and =93withheld=94.
Further, it should be responsibility of the client to infer =93unregis= tered=94 from =93blocked=94 or =93withheld=94 instead of the server returni= ng two statuses.

Regards,
James Mitchell
ARI Registry Services
--_000_CF3CC51625D13jamesmitchellausregistrycomau_-- From nobody Wed Mar 5 05:58:23 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900411A0136 for ; Wed, 5 Mar 2014 05:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RkH1XIxuk2nK for ; Wed, 5 Mar 2014 05:58:19 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 06A051A0109 for ; Wed, 5 Mar 2014 05:58:18 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id r10so1070113pdi.16 for ; Wed, 05 Mar 2014 05:58:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=D+Xk9+6l9WSRCn+oStpXCsggTCH0Mz8KqWm4JZJIM/w=; b=FA2ICAiw5mA5fzhR58e7aVJU0pbix4uw/DDHUpXHZF5RgslDkmt7xj4UrkwSv90grD eR3nuJgAxhVTJSZ2fQXAxnQuCa7Zmu0/9MYQJEusoDf6s6Uu4qObixKsnXkQIqtekorw nKJhusSwNaJIpZozsumuDKXfhs1PTe58mKn7+drfN4nZu6ClpGuf/IyhVQC4XuzUwnap OcOOuRF3xmFxFzQXFdj4FFdFrGImKVeZ6NU7W5nvZjQMRigRPie5KFM6pcGSPmCxTC35 rbYJOFqyb/ea+HZybz9APUHEYa344cOCkD4RmjHFw9SCY3N+h8skB5Rd1gjI6c5gWgnB FCpg== MIME-Version: 1.0 X-Received: by 10.68.202.8 with SMTP id ke8mr7148204pbc.86.1394027895513; Wed, 05 Mar 2014 05:58:15 -0800 (PST) Received: by 10.66.220.102 with HTTP; Wed, 5 Mar 2014 05:58:15 -0800 (PST) Date: Wed, 5 Mar 2014 13:58:15 +0000 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b15a69384e61f04f3dc695a Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5jYbMKTSFeyXFEnE6OR8QvMifJE Subject: [weirds] Open issues X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 13:58:21 -0000 --047d7b15a69384e61f04f3dc695a Content-Type: text/plain; charset=ISO-8859-1 Colleagues, What we believe to be the complete list of open issues remaining for the WG to consider before we're ready to send our documents to Pete can be found here: http://trac.tools.ietf.org/wg/weirds/trac/report/1 If you have feedback (agreement, disagreement, suggested text, etc.) on one of the tracker items, please start a separate thread for it. If you think there's something missing that needs its own tracker item to ensure it's addressed, please reply to this thread with a description of the issue that can be used to create a new tracker item. Let's go! -MSK, WEIRDS co-chair --047d7b15a69384e61f04f3dc695a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

What we believe to be the com= plete list of open issues remaining for the WG to consider before we're= ready to send our documents to Pete can be found here:

http://trac.tools.ietf.o= rg/wg/weirds/trac/report/1

If you have feedback (agreement, disagreement, suggested text, et= c.) on one of the tracker items, please start a separate thread for it.=A0 = If you think there's something missing that needs its own tracker item = to ensure it's addressed, please reply to this thread with a descriptio= n of the issue that can be used to create a new tracker item.

Let's go!

-MSK, WEIRDS co-chair

--047d7b15a69384e61f04f3dc695a-- From nobody Wed Mar 5 06:17:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45F01A00BC for ; Wed, 5 Mar 2014 06:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pbjUT6pBIj-x for ; Wed, 5 Mar 2014 06:17:19 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A601A00E9 for ; Wed, 5 Mar 2014 06:17:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: weirds@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140305141717.14382.42670.idtracker@ietfa.amsl.com> Date: Wed, 05 Mar 2014 06:17:17 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gGre-3JgiYliAem_lZ0QwVHAg90 Subject: [weirds] Milestones changed for weirds WG X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 14:17:20 -0000 Changed milestone "draft-ietf-weirds-rdap-query to the IESG", set due date to April 2014 from January 2014. Changed milestone "draft-ietf-weirds-json-response to the IESG", set due date to April 2014 from January 2014. Changed milestone "draft-ietf-weirds-redirects to the IESG", set due date to April 2014 from January 2014. Changed milestone "draft-ietf-weirds-object-inventory to the IESG", set due date to April 2014 from January 2014. Changed milestone "Draft describing bootstrapping protocol to the IESG", set due date to April 2014 from February 2014. URL: http://datatracker.ietf.org/wg/weirds/charter/ From nobody Wed Mar 5 23:43:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5AB1A0123 for ; Wed, 5 Mar 2014 23:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 ZjvDLG4h8M1T for ; Wed, 5 Mar 2014 23:43:12 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id F00241A0103 for ; Wed, 5 Mar 2014 23:43:11 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id jt11so2228394pbb.8 for ; Wed, 05 Mar 2014 23:43:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:content-transfer-encoding; bh=cfX1PeMCe3X5S3Ier/uj0crDW0zuiVy/ta6aWAZGqO4=; b=Ws8XxXv0S2DoaxVjPJ4qIKtsku/CaKzYk9X3dMsszE+fXomKprszJ7xVHpJZSzT1q4 JdbUTDkSYQR33cT6WAnToDN7rklNQDhtsuveedu2sAfyIe69EpiEIC0ECxymEorri24h giTlFFnfSvf+YTZa+6gMwHgB0y/Cwif8mSZjTWu6QN3KrZ8q8/S56I36bnIWlSI5+BrL GK8qNO94RPYop7SJ8pzjalOfLCTSfzc6yFm+gO9W1MpLWeTeDkXshC+/lng0vBP0fDTG 1jyDyl6Y4ZPBJ/gGX8XMgXHbpb1j0t/E9+RMbH01+M41XzUNc9Pfd6o+izeEKQJK+jDk mhwg== X-Gm-Message-State: ALoCoQnU3uXSFSo/IkBSey5mMFp70VLrPVihkGJGMZEwla4aPNObPzT2WJXT0Epwzx5u6k08liJ9 MIME-Version: 1.0 X-Received: by 10.66.164.165 with SMTP id yr5mr12371308pab.63.1394091788179; Wed, 05 Mar 2014 23:43:08 -0800 (PST) Received: by 10.68.143.4 with HTTP; Wed, 5 Mar 2014 23:43:08 -0800 (PST) X-Originating-IP: [31.133.164.94] In-Reply-To: <5316B4AC.4000701@it.aoyama.ac.jp> References: <5316B4AC.4000701@it.aoyama.ac.jp> Date: Thu, 6 Mar 2014 07:43:08 +0000 Message-ID: From: Andrew Newton To: "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/N02As4kAH72OXvoIFvhuzhvaRjc Subject: [weirds] Fwd: [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 07:43:14 -0000 Forwarding just in case people are not subscribed to apps-discuss, but even the W3C is not convinced of our need to use URI templates and that path prefixes are good enough. -andy ---------- Forwarded message ---------- From: "Martin J. D=FCrst" Date: Wed, Mar 5, 2014 at 5:22 AM Subject: Re: [apps-discuss] WEIRDS WG report To: "Murray S. Kucherawy" , IETF Apps Discuss On 2014/03/05 06:41, Murray S. Kucherawy wrote: > > WEIRDS met today and discussed what we believe are its remaining issues. > > The group discussed the outcome of a design team meeting that tried to > address two issues at once: the issue an imposed URI structure > (draft-nottingham-uri-get-off-my-lawn) and the methodology by which to fi= nd > an authoritative registry that can further delegate. Both issues are bei= ng > addressed by allowing a key-value table that supports longest-match looku= ps > resulting in URI templates that are then used to construct a query that > will either return an answer or a redirection. The WG will continue this > discussion on its mailing list and select a path forward. Participants > were asked to open tracker items for any remaining issues on the open > documents (query, redirection, bootstrapping) so they can be driven to > resolution. Regarding this point, Mark sent a mail to the W3C TAG (Technical Architecture Group) a while ago, at http://lists.w3.org/Archives/Public/www-tag/2014Feb/0068.html, and I replied at http://lists.w3.org/Archives/Public/www-tag/2014Feb/0079.html, switching to defend the (former?) WEIRDS position. There was only one reply, agreeing with me (http://lists.w3.org/Archives/Public/www-tag/2014Feb/0080.html) but probably better worded. Looking at the above "key-value table that supports longest-match lookups resulting in URI templates that are then used to construct a query that will either return an answer or a redirection", this to me smells like over-engineering even just when reading it (not to speak of having to implement it). Of course, if the WEIRDS WG is happy with that, I won't complain any further, but I just wanted to mention this because I earlier supported Mark and Tim on this list (and would still continue to do that if there were no indirection at all in WEIRDS, i.e. if e.g. WEIRDS was requiring top-level directories with fixed names). Regards, Martin. > The discussion of the publication of the table (IANA being the logical > point) ventured into the complications that come with the IETF creating > domain registries and imposing policies potentially outside of its > purview. This issue has not been completely resolved but we believe ther= e > are ways forward through careful crafting of the language and keeping the > IANA section to an absolute minimum. > > Finally, a report was given of interoperability tests performed prior to > the IETF meeting. No specification issues were discovered and a fair > number of server as well as client implementations interoperate. A coupl= e > of issues were identified and we are at or close to consensus on resoluti= on. > > The chairs believe that the work of the group may conclude between now an= d > Toronto, so this may have been our final meeting. > > -MSK and Olaf, co-chairs, WEIRDS > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Wed Mar 5 23:58:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D049D1A0130 for ; Wed, 5 Mar 2014 23:58:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 mREDasMVSWJx for ; Wed, 5 Mar 2014 23:58:48 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6201A0121 for ; Wed, 5 Mar 2014 23:58:48 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id lf10so2329023pab.27 for ; Wed, 05 Mar 2014 23:58:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nGI2JItaA8AJ5z6V88JzkbrgmBrt0mbVn80700yozmc=; b=F/OhjeoYnAbXp4TXjx8n5z4sXFJOQ6zJNNZsOqRIeNA+Dty9OlXLcKyyDcibLgjCB0 tj7yHswJj17rDA6ZoQ1GrYdMWwfovyK81lsr5+rkB/N6RidRi/+sBzehId1XRuBOd1sG RAAll30dif+8UvJKLX5rbW+U7K+EGkILKOxg3Z4NFYNOTKS692fA/v2h38eRSbbJYvdt M3jdq6flh0BCOYkGcb3ohy3elLuiPEsrH+jGpNHuJr2j/m4oQSoTEsE2pFhmr5tU5xPZ +fqH300O8hot29quTTnmCIoZJKuBBdznv80YPe4QIMTINiUp3FGSl++hAUN4oOhCPc/D xKzA== X-Gm-Message-State: ALoCoQn7N108yhZOXr5b951/bnPdWjKPz9KUq5qkFR1jVNXKNbrTAlIYsHAC1tg+akjS3/EZi9nh MIME-Version: 1.0 X-Received: by 10.66.232.68 with SMTP id tm4mr12533284pac.114.1394092724624; Wed, 05 Mar 2014 23:58:44 -0800 (PST) Received: by 10.68.143.4 with HTTP; Wed, 5 Mar 2014 23:58:44 -0800 (PST) X-Originating-IP: [2001:67c:370:160:c59b:d633:fb87:4fcf] In-Reply-To: <20140305150713.4611.qmail@joyce.lan> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> Date: Thu, 6 Mar 2014 07:58:44 +0000 Message-ID: From: Andrew Newton To: John Levine , "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/0dJW7m7Oa0Wh3EEEojrpKMxVnXs Cc: "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 07:58:50 -0000 My major objection to URI templates was the extra retrieval of the template, but that is solved with their inclusion in the bootstrap. However, looking at a real world extension to one of the existing RDAP queries I am beginning to wonder if URI templates are more of a liability. Currently /domain/example.com returns the relevant domain registration, info about DNSSEC, nameservers, contacts, etc... For /domain/136.192.in-addr.arpa there may sometimes be a need to add in related network registration information (actually, RIPE and ARIN do this today with their custom REST interfaces). To signal this a client could optionally add the query parameter ?needNets=true. If the first URI template is http://service/domain/{domain} and the RIRs modify their templates to http://service/domain/{domain}?needNets={needNets}, clients unaware of the extension will not know to substitute anything for "needNets". Simple substitution, as proposed at the meeting, does not work here. Should we move beyond the simple URI templates form, I believe John is absolutely right about the complexity. It will be too much. -andy On Wed, Mar 5, 2014 at 3:07 PM, John Levine wrote: >>Looking at the above "key-value table that supports longest-match >>lookups resulting in URI templates that are then used to construct a >>query that will either return an answer or a redirection", this to me >>smells like over-engineering even just when reading it (not to speak of >>having to implement it). >> >>Of course, if the WEIRDS WG is happy with that, ... > > Not particularly, but our preferred solution, a fixed URL suffix > syntax that we append to a per-thing (domain, IP range, etc.) prefix > is apparently forbidden to us. > > The redirects have been there all along to provide a less broken > version of what thin WHOIS does now. > > R's, > John > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Mar 6 00:53:30 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD47D1A0164; Thu, 6 Mar 2014 00:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 zM6ulRCnICs0; Thu, 6 Mar 2014 00:53:26 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 36D031A0160; Thu, 6 Mar 2014 00:53:26 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id r10so2270849pdi.30 for ; Thu, 06 Mar 2014 00:53:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PBdIN0CLjQT7TsRHvh0rxwEGkFzmIIIW1ISgBMYlrVo=; b=LaoE23XXZ5rcX+SkcXPe3Ztao+D1n4mDAG4Xo17we8IWsVh1+e0cB7ks1N/Hn/zrcp dObsMENWo1o0hmd7P0tOirIr0930CRIeeIZKwUsdwkC7pEL/P8I1QWG8i1bshaIzgNev d8s/wsUNjA2zmR714PGuplRw/0ZOT5ck1OM6/6FktVKKjtPwi3iKDK0cc4SFq2ZU4lyY Zhjdes8Mru/8O0iFTvIQnuM3bpzSnacnmExYq7/4M1x5TmDJ9/akQZRIQGznCCU0CfW4 +vBxoMJCv4LRj/FB2auSr75LSVE9JpL/tCxZ2Uv0f5wl4hV6j4f0sw1gjxFiHHklG31Q QKiA== MIME-Version: 1.0 X-Received: by 10.68.231.35 with SMTP id td3mr12565731pbc.137.1394096002524; Thu, 06 Mar 2014 00:53:22 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 00:53:22 -0800 (PST) In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> Date: Thu, 6 Mar 2014 08:53:22 +0000 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=047d7b33d592036a8704f3ec45aa Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/aRMV7Ex3dupTY2jLQ1zpontDGvc Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 08:53:27 -0000 --047d7b33d592036a8704f3ec45aa Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton wrote: > If the first URI template is http://service/domain/{domain} and the > RIRs modify their templates to > http://service/domain/{domain}?needNets={needNets}, clients unaware of > the extension will not know to substitute anything for "needNets". > Simple substitution, as proposed at the meeting, does not work here. > > If constrained to prefix URIs only and thus limited to search-and-replace, how would a client tell an RIR that it wants to set the needNets flag? -MSK --047d7b33d592036a8704f3ec45aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton <andy@hxr.us&= gt; wrote:
=
If the first URI template is http://service/domain/{domain} and the
RIRs modify their templates to
http://service/domain/{domain}?needNets=3D{needNets}, clients u= naware of
the extension will not know to substitute anything for "needNets"= .
Simple substitution, as proposed at the meeting, does not work here.


If constrained to prefix URIs only and= thus limited to search-and-replace, how would a client tell an RIR that it= wants to set the needNets flag?

-MSK
--047d7b33d592036a8704f3ec45aa-- From nobody Thu Mar 6 01:07:50 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F21AA1A0166; Thu, 6 Mar 2014 01:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 kdzOCk7ZUwGY; Thu, 6 Mar 2014 01:07:46 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 916F51A0178; Thu, 6 Mar 2014 01:07:44 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so2276988pdj.31 for ; Thu, 06 Mar 2014 01:07:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1rWewr2BeLkGp1Ddt+Rd8Ms8f9+xipUBlBdSp4KgEFE=; b=QjAUfFvD8YXHEyX18DXRR0yBlHkVXg8ZH3/QUWclPcD4v/OqUC2c0Mou0WqsyNiZNq tjgjhiB58GC7liYhl2eItdTJM4IdjF4t9RVjAVtCio3vNgfDKdj6DE4IRN4Pz3itMTy+ QY5CttPu2HzPIVS+xQOn+FnLKoOnG9018hiNrEjZcHwAdu7uzF4lGeQnWrrYs4WTE9lk /poz4rkLTuwPDLGCVS1+gDj9nxKB3E7fDxTU9GXIG7bpZh11VAOQJs0qOKvkEftr/p1n Eo8nNtyX1vyEhVVkjfSgg0pK3l5yMav0x3Ji4ZvK88VBxB9Yum2SvrNlz2dygzU6wrTJ IM1Q== MIME-Version: 1.0 X-Received: by 10.66.118.71 with SMTP id kk7mr13073413pab.14.1394096860878; Thu, 06 Mar 2014 01:07:40 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 01:07:40 -0800 (PST) In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> Date: Thu, 6 Mar 2014 09:07:40 +0000 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=e89a8ffbad052cdd7e04f3ec7873 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/5ivJenXaF3iXXdPeHifemWSXIr8 Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:07:48 -0000 --e89a8ffbad052cdd7e04f3ec7873 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton wrote: > If the first URI template is http://service/domain/{domain} and the > RIRs modify their templates to > http://service/domain/{domain}?needNets={needNets}, clients unaware of > the extension will not know to substitute anything for "needNets". > Simple substitution, as proposed at the meeting, does not work here. > > If constrained to prefix URIs only and thus limited to search-and-replace, how would a client tell an RIR that it wants to set the needNets flag? -MSK --e89a8ffbad052cdd7e04f3ec7873 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton <andy@hxr.us&= gt; wrote:
=
If the first URI template is http://service/domain/{domain} and the
RIRs modify their templates to
http://service/domain/{domain}?needNets=3D{needNets}, clients u= naware of
the extension will not know to substitute anything for "needNets"= .
Simple substitution, as proposed at the meeting, does not work here.


If constrained to prefix URIs only and= thus limited to search-and-replace, how would a client tell an RIR that it= wants to set the needNets flag?

-MSK
--e89a8ffbad052cdd7e04f3ec7873-- From nobody Thu Mar 6 01:25:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7F1A0189; Thu, 6 Mar 2014 01:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 K8qYvriaNhDR; Thu, 6 Mar 2014 01:25:03 -0800 (PST) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id 8635D1A0178; Thu, 6 Mar 2014 01:24:47 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUxg+262MGg2+N/nXV8mlDSRemngNt6Yn@postini.com; Thu, 06 Mar 2014 01:24:59 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s269OgmS030712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 04:24:42 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 04:24:42 -0500 From: "Hollenbeck, Scott" To: Andrew Newton , John Levine , "weirds@ietf.org" Thread-Topic: [weirds] [apps-discuss] WEIRDS WG report Thread-Index: AQHPORHpkhr1irWdvUu7RzdktlhnD5rTyUHg Date: Thu, 6 Mar 2014 09:24:41 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lvsiChaSB_ZbBnBSCBbHElmrnng Cc: "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:25:05 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > Newton > Sent: Thursday, March 06, 2014 2:59 AM > To: John Levine; weirds@ietf.org > Cc: apps-discuss@ietf.org > Subject: Re: [weirds] [apps-discuss] WEIRDS WG report [SAH] > Should we move beyond the simple URI templates form, I believe John is > absolutely right about the complexity. It will be too much. Are you suggesting a move back to what we had in the document prior to the = change to .well-known, and no template(s)? Scott From nobody Thu Mar 6 02:31:09 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7894C1A0230; Thu, 6 Mar 2014 02:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.197 X-Spam-Level: X-Spam-Status: No, score=-1.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, SPF_PASS=-0.001] autolearn=no 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 teFG91iO0n0P; Thu, 6 Mar 2014 02:31:06 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [120.29.249.162]) by ietfa.amsl.com (Postfix) with ESMTP id 74B251A0229; Thu, 6 Mar 2014 02:31:05 -0800 (PST) Received: from unknown (HELO ausregistry.com.au) ([10.30.220.61]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2014 21:29:20 +1100 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.91]) with mapi id 14.03.0174.001; Thu, 6 Mar 2014 21:31:04 +1100 From: James Mitchell To: "Hollenbeck, Scott" , Andrew Newton , John Levine , "weirds@ietf.org" Thread-Topic: [weirds] [apps-discuss] WEIRDS WG report Thread-Index: AQHPORHte1IJoASib0+GjIruIS1/eJrTEUOAgADK6QA= Date: Thu, 6 Mar 2014 10:31:00 +0000 Message-ID: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Accept-Language: en-NZ, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.30.255.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/UuQhska2qP-HGUwDA6tRpw785dE Cc: "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:31:07 -0000 What if the registry contains a base URL for the composition of RDAP paths? e.g. { =B3com=B2 : =B3rdap.verisign.com=B2, =B3au=B2 : =B3rdap.ausregistry.net.au/CONTEXT/ROOT=B2 } A client would append =B3/domain/<>=B2, e.g. rdap.verisign.com/domain/example.com and rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au. Allows servers to place a registry-selector in the path name while keeping the whole thing pretty simple. Thanks, James On 6/03/2014 9:24 am, "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew >> Newton >> Sent: Thursday, March 06, 2014 2:59 AM >> To: John Levine; weirds@ietf.org >> Cc: apps-discuss@ietf.org >> Subject: Re: [weirds] [apps-discuss] WEIRDS WG report > >[SAH] > >> Should we move beyond the simple URI templates form, I believe John is >> absolutely right about the complexity. It will be too much. > >Are you suggesting a move back to what we had in the document prior to >the change to .well-known, and no template(s)? > >Scott > >_______________________________________________ >weirds mailing list >weirds@ietf.org >https://www.ietf.org/mailman/listinfo/weirds From nobody Thu Mar 6 02:36:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446071A0252; Thu, 6 Mar 2014 02:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 ucyKgwxzqzpd; Thu, 6 Mar 2014 02:36:16 -0800 (PST) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 21AA91A023E; Thu, 6 Mar 2014 02:36:16 -0800 (PST) Received: by mail-pd0-f180.google.com with SMTP id v10so2385205pde.11 for ; Thu, 06 Mar 2014 02:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YgczRJKc6D9MyTPGuq+X9q+fHHPZ9uGjkNl4w45rPCM=; b=i1lFwxZfIxsVi1Q5/wa4uW0caDQf47lyAGFiWhiN1/5AlFjnJnpkhT0m+4rJ2pIKgs yM3Q/pRXJ9vqWN9O1h5iAKB1hEeOaZP92TCXh4rc2frd1CTg/xB+srqR1SYpkIjFF3Yl rQ/5cn0WS17C+YyDqfoBrsX6orSXc2/+Fm8xeu1bJDhiYerXV6iFZKZJgXIpKjXBiMCq 4NGYdGzX3LZSNWZexYztlO67Xn9dvOX7LbsdFZ1vCtNchzRgXiSgufMg4sRaokCagXew uevFIpmqKWEDrqSJu9wMDXdVyeS/Swp5Lzz0C5k76H4e5BALvcirDFL3O0HstQuoUw7T zO2g== MIME-Version: 1.0 X-Received: by 10.66.250.202 with SMTP id ze10mr13452745pac.153.1394102172373; Thu, 06 Mar 2014 02:36:12 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 02:36:12 -0800 (PST) In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 6 Mar 2014 10:36:12 +0000 Message-ID: From: "Murray S. Kucherawy" To: James Mitchell Content-Type: multipart/alternative; boundary=047d7b15aeedc3d7ef04f3edb440 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fXOn7SeX3S0u9yIe2iJb-LXZS2U Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:36:18 -0000 --047d7b15aeedc3d7ef04f3edb440 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What about a client that doesn't know what CONTEXT to use? If the answer to that is that a client always has to fill in two variables instead of one, then you're basically doing templates. On Thu, Mar 6, 2014 at 10:31 AM, James Mitchell < james.mitchell@ausregistry.com.au> wrote: > What if the registry contains a base URL for the composition of RDAP path= s? > > e.g. > { > =B3com=B2 : =B3rdap.verisign.com=B2, > =B3au=B2 : =B3rdap.ausregistry.net.au/CONTEXT/ROOT=B2 > } > > A client would append =B3/domain/<>=B2, e.g. > rdap.verisign.com/domain/example.com and > rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au. Allows server= s > to place a registry-selector in the path name while keeping the whole > thing pretty simple. > > Thanks, > James > > On 6/03/2014 9:24 am, "Hollenbeck, Scott" > wrote: > > >> -----Original Message----- > >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > >> Newton > >> Sent: Thursday, March 06, 2014 2:59 AM > >> To: John Levine; weirds@ietf.org > >> Cc: apps-discuss@ietf.org > >> Subject: Re: [weirds] [apps-discuss] WEIRDS WG report > > > >[SAH] > > > >> Should we move beyond the simple URI templates form, I believe John is > >> absolutely right about the complexity. It will be too much. > > > >Are you suggesting a move back to what we had in the document prior to > >the change to .well-known, and no template(s)? > > > >Scott > > > >_______________________________________________ > >weirds mailing list > >weirds@ietf.org > >https://www.ietf.org/mailman/listinfo/weirds > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --047d7b15aeedc3d7ef04f3edb440 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What about a client that doesn't know what CONTEX= T to use?

If the answer to that is that a client always has to= fill in two variables instead of one, then you're basically doing temp= lates.


On Thu,= Mar 6, 2014 at 10:31 AM, James Mitchell <james.mitchell@a= usregistry.com.au> wrote:
What if the registry contains a base URL for= the composition of RDAP paths?

e.g.
{
=A0 =A0 =A0 =A0 =B3com=B2 : =B3rdap.verisign.com=B2,
=A0 =A0 =A0 =A0 =B3au=B2 : =B3rdap.ausregistry.net.au/CONTEXT/ROOT=B2 }

A client would append =B3/domain/<<domain-name>>=B2, e.g.
r= dap.verisign.com/domain/example.com and
rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.co= m.au. Allows servers
to place a registry-selector in the path name while keeping the whole
thing pretty simple.

Thanks,
James

On 6/03/2014 9:24 am, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:

>> -----Original Message-----
>> From: weirds [mailto:we= irds-bounces@ietf.org] On Behalf Of Andrew
>> Newton
>> Sent: Thursday, March 06, 2014 2:59 AM
>> To: John Levine; weirds@ietf.or= g
>> Cc: apps-discuss@ietf.org=
>> Subject: Re: [weirds] [apps-discuss] WEIRDS WG report
>
>[SAH]
>
>> Should we move beyond the simple URI templates form, I believe Joh= n is
>> absolutely right about the complexity. It will be too much.
>
>Are you suggesting a move back to what we had in the document prior to<= br> >the change to .well-known, and no template(s)?
>
>Scott
>
>_______________________________________________
>weirds mailing list
>weirds@ietf.org
>https://www.ietf.org/mailman/listinfo/weirds

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--047d7b15aeedc3d7ef04f3edb440-- From nobody Thu Mar 6 02:52:03 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64F91A0256 for ; Thu, 6 Mar 2014 02:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 It7PgCkqlsmx for ; Thu, 6 Mar 2014 02:52:01 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id B95681A0252 for ; Thu, 6 Mar 2014 02:52:00 -0800 (PST) Received: (qmail 79902 invoked from network); 6 Mar 2014 10:51:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1381d.5318534b.k1403; i=johnl-iecc.com@submit.iecc.com; bh=Zn3U69FrNBYPqBsR1tE/Jpk9Upo36Z7MGpMZi2Zpgo0=; b=BEaODPQdDMhqgv2HQ3/HmnWtpmSugHrSHcbZQim0Y4VDhZkZ3mdjaQsnZBdNiDPLVFTtW5LBhJOeuVDlKNV/xjVBZYXSihSSD9xC5om41BBfVYJcL0tkAtjecakXtYhZRqEmBWp4sCl1nsTgrtlm4ZYFk9jYgQRw+allARXcBdRqgtsjCJC9EffoQ2CiY9HQ/A8Fa1lQB/Duuyq8CCz9YlvlC/PX+fUoP/mIlN3iJmj2rA6mH3yRj7AIsNdS/SQJ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1381d.5318534b.k1403; olt=johnl-iecc.com@submit.iecc.com; bh=Zn3U69FrNBYPqBsR1tE/Jpk9Upo36Z7MGpMZi2Zpgo0=; b=pTYWHPMX6rtHf83VgAo7CjyG8S+62TYgF+/AY8vvNALYYMMLBWPgXLIWMfTbD2EpBZktHzbpjg1hd5ff65RLGKGGZfVoDHKalXJiceF8Frg/sxikhFeCThbb3pLxa//Q6XFOMuJaICtcEipSOA+TNH/wHCTGyXMunaoNe2B3sM1jWe3MnI8miGfDhF0Px1LqujtlNUJzBa5hmHoxIPOdeaKniBhlIyoTvIbj/KhOi2fVreBEmOVJfqlGHO8FnOfx Received: from dhcp-hotel-wifi-157-aa.meeting.ietf.org ([130.129.157.170]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 06 Mar 2014 10:51:54 -0000 Date: 6 Mar 2014 10:51:52 +0000 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/KjRfmTHVT-kFSXZVIJdq4BHv0cg Cc: "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:52:02 -0000 >> If the first URI template is http://service/domain/{domain} and the >> RIRs modify their templates to >> http://service/domain/{domain}?needNets={needNets}, clients unaware of >> the extension will not know to substitute anything for "needNets". >> Simple substitution, as proposed at the meeting, does not work here. >> >> > If constrained to prefix URIs only and thus limited to search-and-replace, > how would a client tell an RIR that it wants to set the needNets flag? If it were me, I'd have an IANA registry of fixed prefixes for queries, so whatever it was, it'd be in the registry. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Thu Mar 6 02:57:05 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8A51A0233 for ; Thu, 6 Mar 2014 02:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.563 X-Spam-Level: * X-Spam-Status: No, score=1.563 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 p2z6Om6-aJFc for ; Thu, 6 Mar 2014 02:57:03 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2846C1A0260 for ; Thu, 6 Mar 2014 02:57:02 -0800 (PST) Received: (qmail 80625 invoked from network); 6 Mar 2014 10:56:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=13af0.5318547b.k1403; i=johnl-iecc.com@submit.iecc.com; bh=jKqpztOPrCGVzmT2GOudZl4LnubAc74+oLB/VvhpMZc=; b=CSWekorY1sEgYdojslLvvGZalJJz5dRqhirHwj2rGXiLIRHRqk7YcgRd7MBbkw31xZZWG0ZLd/2Xq29yUqeGymDfiwwSdw3ZljZvZkY1FjAP/WlAkH3aT5xD/iByLXZFu9mTEesUEOs44bSO7591yw40JWzI4odGKhVZ8g/r2GG2wRdWjG74thzWKVEBnIlQ1HKGGosJlsq5oRgXMJFr7cwayM+bBdUbJe0pziEFoWEMlZ3ryoknEqCrK8UcsnJ7 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=13af0.5318547b.k1403; olt=johnl-iecc.com@submit.iecc.com; bh=jKqpztOPrCGVzmT2GOudZl4LnubAc74+oLB/VvhpMZc=; b=1oLMInKA0+7LwDyyiVJ4KzkJ8eu79mCJu9Hbb4mA2sHRbTkzQnaZmZBSqQH8/lWBw+cMzTMOqWmmNHqBocK6TmKTXNO/eRkmU1oAp6PRGQgdYv8s2L08xlqq/diWFP6xR3mcmVa6IrhkSYndg6i6DdP1rwVi8UlaIMm9rw5/KWzuEMsDPraZ2NC+665aQnslTdJZCqYoOKyVDDloRa/Ipa9j8wY72R0MlOiWk+zGdnDfsijS18ydf1Ekh7POck5l Received: from dhcp-hotel-wifi-157-aa.meeting.ietf.org ([130.129.157.170]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 06 Mar 2014 10:56:58 -0000 Date: 6 Mar 2014 10:56:56 +0000 Message-ID: From: "John R Levine" To: "James Mitchell" In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-917949633-1394103418=:24084" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/_nN7Mdyn2I5lztMPApDpCfWisSY Cc: "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:57:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-917949633-1394103418=:24084 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT > What if the registry contains a base URL for the composition of RDAP paths? > > e.g. > { > ³com² : ³rdap.verisign.com², > ³au² : ³rdap.ausregistry.net.au/CONTEXT/ROOT² > } > > A client would append ³/domain/<>², e.g. > rdap.verisign.com/domain/example.com and > rdap.ausregistry.net.au/CONTEXT/ROOT/domain/example.com.au. Allows servers > to place a registry-selector in the path name while keeping the whole > thing pretty simple. That was more or less the original plan. That came up in the design team meeting and I think that Mark said that they'd tell us that was not good practice but they'd probably let us do it. Given the range of questions that people might ask, if we go the template route I don't see much alternative to an explosion of NxM templates (N query types and M domains, IPs, etc.) I suppose we could try three metatemplates and a registry, but ugh. R's, John --3825401791-917949633-1394103418=:24084-- From nobody Thu Mar 6 02:57:18 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952901A0274; Thu, 6 Mar 2014 02:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] 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 pDetNxFAPASA; Thu, 6 Mar 2014 02:57:04 -0800 (PST) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) by ietfa.amsl.com (Postfix) with ESMTP id 678A31A0237; Thu, 6 Mar 2014 02:57:04 -0800 (PST) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( egs 8.14.5/8.14.5) with ESMTP id s26Av0OO013705; Thu, 6 Mar 2014 02:57:00 -0800 Received: from vpn-135-70-101-180.vpn.swst.att.com ([135.70.101.180]) by maillennium.att.com (mailgw1) with ESMTP id <20140306105659gw100j0c4ae>; Thu, 6 Mar 2014 10:56:59 +0000 X-Originating-IP: [135.70.101.180] Message-ID: <5318547A.80805@att.com> Date: Thu, 06 Mar 2014 05:56:58 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "weirds@ietf.org" References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/s-HRORmz3Yv5_N28gZZcFCNdvaU Cc: "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:57:07 -0000 On 3/6/14, 2:58 AM, Andrew Newton wrote: > My major objection to URI templates was the extra retrieval of the > template, but that is solved with their inclusion in the bootstrap. > > However, looking at a real world extension to one of the existing RDAP > queries I am beginning to wonder if URI templates are more of a > liability. Currently /domain/example.com returns the relevant domain > registration, info about DNSSEC, nameservers, contacts, etc... For > /domain/136.192.in-addr.arpa there may sometimes be a need to add in > related network registration information (actually, RIPE and ARIN do > this today with their custom REST interfaces). To signal this a client > could optionally add the query parameter ?needNets=true. > > If the first URI template is http://service/domain/{domain} and the > RIRs modify their templates to > http://service/domain/{domain}?needNets={needNets}, clients unaware of > the extension will not know to substitute anything for "needNets". > Simple substitution, as proposed at the meeting, does not work here. I disagree. The rule for such options should be that *) any parameters that are unknown SHOULD be removed, as in "?needNets=" from the previous example *) the server MUST handle extension parameters that are empty *) the server MUST treat extension parameters with an unexpanded value such as "{needNets}" as if it were empty In other words, if the server receives "?needNets={needNets}" OR "?needNets=" it needs to do the right thing. And the "simple" sed script mentioned in the room that does expansion just needs an additional -e 's/{[^}]*}//g'. Tony Hansen From nobody Thu Mar 6 02:58:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2E1A0279; Thu, 6 Mar 2014 02:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.504 X-Spam-Level: * X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 hLu2DjX0cQ-l; Thu, 6 Mar 2014 02:58:34 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [120.29.249.162]) by ietfa.amsl.com (Postfix) with ESMTP id F1BF31A0275; Thu, 6 Mar 2014 02:58:32 -0800 (PST) Received: from unknown (HELO ausregistry.com.au) ([10.30.220.61]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 06 Mar 2014 21:56:42 +1100 Received: from MELEX01.ausregistrygroup.local ([10.11.220.61]) by OFFEX01.ausregistrygroup.local ([169.254.2.91]) with mapi id 14.03.0174.001; Thu, 6 Mar 2014 21:58:26 +1100 From: James Mitchell To: "Murray S. Kucherawy" Thread-Topic: [weirds] [apps-discuss] WEIRDS WG report Thread-Index: AQHPORHte1IJoASib0+GjIruIS1/eJrTEUOAgADK6QD//0kSAIAAvpOA Date: Thu, 6 Mar 2014 10:58:22 +0000 Message-ID: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F4936C7EA@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Accept-Language: en-NZ, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.30.255.223] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: multipart/alternative; boundary="_000_CF3E01F82608Ejamesmitchellausregistrycomau_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/LGttfpHs0gNYao-DfpmoA7Kl94s Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:58:35 -0000 --_000_CF3E01F82608Ejamesmitchellausregistrycomau_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 VGhlIC9DT05URVhUL1JPT1QgaXMgdG8gYmUgcHJvdmlkZWQgYnkgd2hvbWV2ZXIgaXMgcmVxdWVz dGluZyB0aGUgZW50cnkgaW50byB0aGUgcmVnaXN0cnkgdGh1cyBoYXJkLWNvZGVkIGludG8gdGhl IHJlZ2lzdHJ5LiBUbyB1c2UgdGhlIHJlZ2lzdHJ5IGNsaWVudHMgb25seSBuZWVkIHRoZSBhYmls aXR5IHRvIGFwcGVuZCB0aGUgV0VSSURTIHNwZWNpZmljYXRpb24gZGVmaW5lZCBwYXRoIChhbmQg cXVlcnkgc3RyaW5ncyB3aGVuIHJlbGV2YW50KSB0byB0aGUgcmVsZXZhbnQgdmFsdWUuDQoNClBl cmhhcHMgdGhlIHVzZSBvZiAvQ09OVEVYVC9ST09UIHdhcyBtaXNsZWFkaW5nPw0KDQpGcm9tOiAi TXVycmF5IFMuIEt1Y2hlcmF3eSIgPHN1cGVydXNlckBnbWFpbC5jb208bWFpbHRvOnN1cGVydXNl ckBnbWFpbC5jb20+Pg0KRGF0ZTogVGh1cnNkYXksIDYgTWFyY2ggMjAxNCAxMDozNiBhbQ0KVG86 IEphbWVzIE1pdGNoZWxsIDxqYW1lcy5taXRjaGVsbEBhdXNyZWdpc3RyeS5jb20uYXU8bWFpbHRv OmphbWVzLm1pdGNoZWxsQGF1c3JlZ2lzdHJ5LmNvbS5hdT4+DQpDYzogIkhvbGxlbmJlY2ssIFNj b3R0IiA8c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPG1haWx0bzpzaG9sbGVuYmVja0B2ZXJpc2ln bi5jb20+PiwgQW5kcmV3IE5ld3RvbiA8YW5keUBoeHIudXM8bWFpbHRvOmFuZHlAaHhyLnVzPj4s IEpvaG4gTGV2aW5lIDxqb2hubEB0YXVnaC5jb208bWFpbHRvOmpvaG5sQHRhdWdoLmNvbT4+LCAi d2VpcmRzQGlldGYub3JnPG1haWx0bzp3ZWlyZHNAaWV0Zi5vcmc+IiA8d2VpcmRzQGlldGYub3Jn PG1haWx0bzp3ZWlyZHNAaWV0Zi5vcmc+PiwgImFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86 YXBwcy1kaXNjdXNzQGlldGYub3JnPiIgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzxtYWlsdG86YXBw cy1kaXNjdXNzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbd2VpcmRzXSBbYXBwcy1kaXNjdXNz XSBXRUlSRFMgV0cgcmVwb3J0DQoNCldoYXQgYWJvdXQgYSBjbGllbnQgdGhhdCBkb2Vzbid0IGtu b3cgd2hhdCBDT05URVhUIHRvIHVzZT8NCg0KSWYgdGhlIGFuc3dlciB0byB0aGF0IGlzIHRoYXQg YSBjbGllbnQgYWx3YXlzIGhhcyB0byBmaWxsIGluIHR3byB2YXJpYWJsZXMgaW5zdGVhZCBvZiBv bmUsIHRoZW4geW91J3JlIGJhc2ljYWxseSBkb2luZyB0ZW1wbGF0ZXMuDQoNCg0KT24gVGh1LCBN YXIgNiwgMjAxNCBhdCAxMDozMSBBTSwgSmFtZXMgTWl0Y2hlbGwgPGphbWVzLm1pdGNoZWxsQGF1 c3JlZ2lzdHJ5LmNvbS5hdTxtYWlsdG86amFtZXMubWl0Y2hlbGxAYXVzcmVnaXN0cnkuY29tLmF1 Pj4gd3JvdGU6DQpXaGF0IGlmIHRoZSByZWdpc3RyeSBjb250YWlucyBhIGJhc2UgVVJMIGZvciB0 aGUgY29tcG9zaXRpb24gb2YgUkRBUCBwYXRocz8NCg0KZS5nLg0Kew0KICAgICAgICCp+GNvban3 IDogqfhyZGFwLnZlcmlzaWduLmNvbTxodHRwOi8vcmRhcC52ZXJpc2lnbi5jb20+qfcsDQogICAg ICAgIKn4YXWp9yA6IKn4cmRhcC5hdXNyZWdpc3RyeS5uZXQuYXUvQ09OVEVYVC9ST09UPGh0dHA6 Ly9yZGFwLmF1c3JlZ2lzdHJ5Lm5ldC5hdS9DT05URVhUL1JPT1Q+qfcNCn0NCg0KQSBjbGllbnQg d291bGQgYXBwZW5kIKn4L2RvbWFpbi88PGRvbWFpbi1uYW1lPj6p9ywgZS5nLg0KcmRhcC52ZXJp c2lnbi5jb20vZG9tYWluL2V4YW1wbGUuY29tPGh0dHA6Ly9yZGFwLnZlcmlzaWduLmNvbS9kb21h aW4vZXhhbXBsZS5jb20+IGFuZA0KcmRhcC5hdXNyZWdpc3RyeS5uZXQuYXUvQ09OVEVYVC9ST09U L2RvbWFpbi9leGFtcGxlLmNvbS5hdTxodHRwOi8vcmRhcC5hdXNyZWdpc3RyeS5uZXQuYXUvQ09O VEVYVC9ST09UL2RvbWFpbi9leGFtcGxlLmNvbS5hdT4uIEFsbG93cyBzZXJ2ZXJzDQp0byBwbGFj ZSBhIHJlZ2lzdHJ5LXNlbGVjdG9yIGluIHRoZSBwYXRoIG5hbWUgd2hpbGUga2VlcGluZyB0aGUg d2hvbGUNCnRoaW5nIHByZXR0eSBzaW1wbGUuDQoNClRoYW5rcywNCkphbWVzDQoNCk9uIDYvMDMv MjAxNCA5OjI0IGFtLCAiSG9sbGVuYmVjaywgU2NvdHQiIDxzaG9sbGVuYmVja0B2ZXJpc2lnbi5j b208bWFpbHRvOnNob2xsZW5iZWNrQHZlcmlzaWduLmNvbT4+IHdyb3RlOg0KDQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogd2VpcmRzIFttYWlsdG86d2VpcmRzLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOndlaXJkcy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEFuZHJldw0KPj4gTmV3dG9uDQo+PiBTZW50OiBUaHVyc2RheSwgTWFyY2ggMDYsIDIwMTQgMjo1 OSBBTQ0KPj4gVG86IEpvaG4gTGV2aW5lOyB3ZWlyZHNAaWV0Zi5vcmc8bWFpbHRvOndlaXJkc0Bp ZXRmLm9yZz4NCj4+IENjOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmc8bWFpbHRvOmFwcHMtZGlzY3Vz c0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbd2VpcmRzXSBbYXBwcy1kaXNjdXNzXSBXRUlS RFMgV0cgcmVwb3J0DQo+DQo+W1NBSF0NCj4NCj4+IFNob3VsZCB3ZSBtb3ZlIGJleW9uZCB0aGUg c2ltcGxlIFVSSSB0ZW1wbGF0ZXMgZm9ybSwgSSBiZWxpZXZlIEpvaG4gaXMNCj4+IGFic29sdXRl bHkgcmlnaHQgYWJvdXQgdGhlIGNvbXBsZXhpdHkuIEl0IHdpbGwgYmUgdG9vIG11Y2guDQo+DQo+ QXJlIHlvdSBzdWdnZXN0aW5nIGEgbW92ZSBiYWNrIHRvIHdoYXQgd2UgaGFkIGluIHRoZSBkb2N1 bWVudCBwcmlvciB0bw0KPnRoZSBjaGFuZ2UgdG8gLndlbGwta25vd24sIGFuZCBubyB0ZW1wbGF0 ZShzKT8NCj4NCj5TY290dA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+d2VpcmRzIG1haWxpbmcgbGlzdA0KPndlaXJkc0BpZXRmLm9yZzxtYWls dG86d2VpcmRzQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vd2VpcmRzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQp3ZWlyZHMgbWFpbGluZyBsaXN0DQp3ZWlyZHNAaWV0Zi5vcmc8bWFpbHRvOndlaXJkc0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VpcmRzDQoN Cg== --_000_CF3E01F82608Ejamesmitchellausregistrycomau_ Content-Type: text/html; charset="euc-kr" Content-ID: <6C5FACA0ADF6A7439577916B9A39636E@ausregistry.com.au> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+VGhlIC9DT05U RVhUL1JPT1QgaXMgdG8gYmUgcHJvdmlkZWQgYnkgd2hvbWV2ZXIgaXMgcmVxdWVzdGluZyB0aGUg ZW50cnkgaW50byB0aGUgcmVnaXN0cnkgdGh1cyBoYXJkLWNvZGVkIGludG8gdGhlIHJlZ2lzdHJ5 LiBUbyB1c2UgdGhlIHJlZ2lzdHJ5IGNsaWVudHMgb25seSBuZWVkIHRoZSBhYmlsaXR5IHRvIGFw cGVuZCB0aGUgV0VSSURTIHNwZWNpZmljYXRpb24gZGVmaW5lZCBwYXRoIChhbmQgcXVlcnkgc3Ry aW5ncyB3aGVuIHJlbGV2YW50KQ0KIHRvIHRoZSByZWxldmFudCB2YWx1ZS48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PlBlcmhhcHMgdGhlIHVzZSBvZiAvQ09OVEVYVC9ST09UIHdhcyBt aXNsZWFkaW5nPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6 MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFE RElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAx cHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtNdXJyYXkg Uy4gS3VjaGVyYXd5JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3VwZXJ1c2VyQGdtYWlsLmNv bSI+c3VwZXJ1c2VyQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgNiBNYXJjaCAyMDE0IDEwOjM2IGFtPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+SmFtZXMgTWl0Y2hl bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5taXRjaGVsbEBhdXNyZWdpc3RyeS5jb20uYXUi PmphbWVzLm1pdGNoZWxsQGF1c3JlZ2lzdHJ5LmNvbS5hdTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7SG9sbGVuYmVjaywgU2NvdHQm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzaG9sbGVuYmVja0B2ZXJpc2lnbi5jb20iPnNob2xs ZW5iZWNrQHZlcmlzaWduLmNvbTwvYT4mZ3Q7LCBBbmRyZXcgTmV3dG9uICZsdDs8YSBocmVmPSJt YWlsdG86YW5keUBoeHIudXMiPmFuZHlAaHhyLnVzPC9hPiZndDssIEpvaG4gTGV2aW5lICZsdDs8 YSBocmVmPSJtYWlsdG86am9obmxAdGF1Z2guY29tIj5qb2hubEB0YXVnaC5jb208L2E+Jmd0OywN CiAmcXVvdDs8YSBocmVmPSJtYWlsdG86d2VpcmRzQGlldGYub3JnIj53ZWlyZHNAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86d2VpcmRzQGlldGYub3JnIj53ZWlyZHNAaWV0 Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9y ZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFw cHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPlJlOiBbd2VpcmRz XSBbYXBwcy1kaXNjdXNzXSBXRUlSRFMgV0cgcmVwb3J0PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+V2hhdCBhYm91dCBh IGNsaWVudCB0aGF0IGRvZXNuJ3Qga25vdyB3aGF0IENPTlRFWFQgdG8gdXNlPzxicj4NCjxicj4N CjwvZGl2Pg0KSWYgdGhlIGFuc3dlciB0byB0aGF0IGlzIHRoYXQgYSBjbGllbnQgYWx3YXlzIGhh cyB0byBmaWxsIGluIHR3byB2YXJpYWJsZXMgaW5zdGVhZCBvZiBvbmUsIHRoZW4geW91J3JlIGJh c2ljYWxseSBkb2luZyB0ZW1wbGF0ZXMuPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9l eHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgTWFyIDYs IDIwMTQgYXQgMTA6MzEgQU0sIEphbWVzIE1pdGNoZWxsIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8 YSBocmVmPSJtYWlsdG86amFtZXMubWl0Y2hlbGxAYXVzcmVnaXN0cnkuY29tLmF1IiB0YXJnZXQ9 Il9ibGFuayI+amFtZXMubWl0Y2hlbGxAYXVzcmVnaXN0cnkuY29tLmF1PC9hPiZndDs8L3NwYW4+ IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi Pg0KV2hhdCBpZiB0aGUgcmVnaXN0cnkgY29udGFpbnMgYSBiYXNlIFVSTCBmb3IgdGhlIGNvbXBv c2l0aW9uIG9mIFJEQVAgcGF0aHM/PGJyPg0KPGJyPg0KZS5nLjxicj4NCns8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgqfhjb22p9yA6IKn4PGEgaHJlZj0iaHR0cDovL3JkYXAudmVy aXNpZ24uY29tIiB0YXJnZXQ9Il9ibGFuayI+cmRhcC52ZXJpc2lnbi5jb208L2E+qfcsPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IKn4YXWp9yA6IKn4PGEgaHJlZj0iaHR0cDovL3Jk YXAuYXVzcmVnaXN0cnkubmV0LmF1L0NPTlRFWFQvUk9PVCIgdGFyZ2V0PSJfYmxhbmsiPnJkYXAu YXVzcmVnaXN0cnkubmV0LmF1L0NPTlRFWFQvUk9PVDwvYT6p9zxicj4NCn08YnI+DQo8YnI+DQpB IGNsaWVudCB3b3VsZCBhcHBlbmQgqfgvZG9tYWluLyZsdDsmbHQ7ZG9tYWluLW5hbWUmZ3Q7Jmd0 O6n3LCBlLmcuPGJyPg0KPGEgaHJlZj0iaHR0cDovL3JkYXAudmVyaXNpZ24uY29tL2RvbWFpbi9l eGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJkYXAudmVyaXNpZ24uY29tL2RvbWFpbi9leGFt cGxlLmNvbTwvYT4gYW5kPGJyPg0KPGEgaHJlZj0iaHR0cDovL3JkYXAuYXVzcmVnaXN0cnkubmV0 LmF1L0NPTlRFWFQvUk9PVC9kb21haW4vZXhhbXBsZS5jb20uYXUiIHRhcmdldD0iX2JsYW5rIj5y ZGFwLmF1c3JlZ2lzdHJ5Lm5ldC5hdS9DT05URVhUL1JPT1QvZG9tYWluL2V4YW1wbGUuY29tLmF1 PC9hPi4gQWxsb3dzIHNlcnZlcnM8YnI+DQp0byBwbGFjZSBhIHJlZ2lzdHJ5LXNlbGVjdG9yIGlu IHRoZSBwYXRoIG5hbWUgd2hpbGUga2VlcGluZyB0aGUgd2hvbGU8YnI+DQp0aGluZyBwcmV0dHkg c2ltcGxlLjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpKYW1lczxicj4NCjxkaXYgY2xhc3M9IkhP RW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KT24gNi8wMy8yMDE0IDk6MjQgYW0sICZxdW90 O0hvbGxlbmJlY2ssIFNjb3R0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2hvbGxlbmJlY2tA dmVyaXNpZ24uY29tIj5zaG9sbGVuYmVja0B2ZXJpc2lnbi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+ DQo8YnI+DQomZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7 IEZyb206IHdlaXJkcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp3ZWlyZHMtYm91bmNlc0BpZXRm Lm9yZyI+d2VpcmRzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQW5kcmV3PGJy Pg0KJmd0OyZndDsgTmV3dG9uPGJyPg0KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIE1hcmNoIDA2 LCAyMDE0IDI6NTkgQU08YnI+DQomZ3Q7Jmd0OyBUbzogSm9obiBMZXZpbmU7IDxhIGhyZWY9Im1h aWx0bzp3ZWlyZHNAaWV0Zi5vcmciPndlaXJkc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBD YzogPGEgaHJlZj0ibWFpbHRvOmFwcHMtZGlzY3Vzc0BpZXRmLm9yZyI+YXBwcy1kaXNjdXNzQGll dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbd2VpcmRzXSBbYXBwcy1kaXNj dXNzXSBXRUlSRFMgV0cgcmVwb3J0PGJyPg0KJmd0Ozxicj4NCiZndDtbU0FIXTxicj4NCiZndDs8 YnI+DQomZ3Q7Jmd0OyBTaG91bGQgd2UgbW92ZSBiZXlvbmQgdGhlIHNpbXBsZSBVUkkgdGVtcGxh dGVzIGZvcm0sIEkgYmVsaWV2ZSBKb2huIGlzPGJyPg0KJmd0OyZndDsgYWJzb2x1dGVseSByaWdo dCBhYm91dCB0aGUgY29tcGxleGl0eS4gSXQgd2lsbCBiZSB0b28gbXVjaC48YnI+DQomZ3Q7PGJy Pg0KJmd0O0FyZSB5b3Ugc3VnZ2VzdGluZyBhIG1vdmUgYmFjayB0byB3aGF0IHdlIGhhZCBpbiB0 aGUgZG9jdW1lbnQgcHJpb3IgdG88YnI+DQomZ3Q7dGhlIGNoYW5nZSB0byAud2VsbC1rbm93biwg YW5kIG5vIHRlbXBsYXRlKHMpPzxicj4NCiZndDs8YnI+DQomZ3Q7U2NvdHQ8YnI+DQomZ3Q7PGJy Pg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0O3dlaXJkcyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOndlaXJk c0BpZXRmLm9yZyI+d2VpcmRzQGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3dlaXJkcyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vd2VpcmRzPC9hPjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kd2Vp cmRzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp3ZWlyZHNAaWV0Zi5vcmciPndl aXJkc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3dlaXJkcyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vd2VpcmRzPC9hPjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CF3E01F82608Ejamesmitchellausregistrycomau_-- From nobody Thu Mar 6 03:03:42 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014781A02B5 for ; Thu, 6 Mar 2014 03:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 6PPGfPXeHmxL for ; Thu, 6 Mar 2014 03:03:38 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 65EC41A0299 for ; Thu, 6 Mar 2014 03:03:35 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id uo5so2484330pbc.10 for ; Thu, 06 Mar 2014 03:03:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MjbBd6xnupaz3xv6r56ZgnZjrhrFoIoltVljP+/ygxU=; b=mRZO8H/1Vnf+ak1ZVC4aAC5IuBrxhAXVL34FX82C9iUgpiCCqq3OyEqS97KM9RtjwK tEr5F/N3kbbnv+AHQhTC2zQQ+mG+Tv4wiBijrtTDEHt6EEt5j67FY2dWKue7QVftLf01 2wwxGG6npj6xWFLuisPBqUijNmSambipg2iQAH1A4b3fNVpsOry/ARC/LySTsPQ9Ema5 OJzo7A52qdSUDVBL7Rh/ooIJwIV9e2j00nrCCicrSuZsj5V9MJYv0hlNBGftpwI076Sj nMjHLvN9VaF46sOFuDjRqTv2bLo7Rff3h1urVuAAkCKJ2cF6Vg/MetJeXZcFlSsO27hv IkDQ== MIME-Version: 1.0 X-Received: by 10.68.212.10 with SMTP id ng10mr13448211pbc.95.1394103809582; Thu, 06 Mar 2014 03:03:29 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 03:03:29 -0800 (PST) In-Reply-To: <5318547A.80805@att.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> Date: Thu, 6 Mar 2014 11:03:29 +0000 Message-ID: From: "Murray S. Kucherawy" To: Tony Hansen Content-Type: multipart/alternative; boundary=e89a8fb2088859ac6004f3ee1671 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/usLcKSAQRyl5MQ9ody2fbI6I-yc Cc: "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:03:40 -0000 --e89a8fb2088859ac6004f3ee1671 Content-Type: text/plain; charset=ISO-8859-1 [dropping apps-discuss] On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen wrote: > > I disagree. The rule for such options should be that > > *) any parameters that are unknown SHOULD be removed, as in "?needNets=" > from the previous example > *) the server MUST handle extension parameters that are empty > *) the server MUST treat extension parameters with an unexpanded value > such as "{needNets}" as if it were empty > > In other words, if the server receives "?needNets={needNets}" OR > "?needNets=" it needs to do the right thing. > > And the "simple" sed script mentioned in the room that does expansion just > needs an additional -e 's/{[^}]*}//g'. I think the template would look like this: http://rdap.server.name.here/rdap{?domain,needNets} If the client has no defined value for needNets but wants a domain of example.com, the expansion becomes: http://rdap.server.name.here/rdap?domain=example.com If needNets is defined but empty: http://rdap.server.name.here/rdap?domain=example.com?needNets= The server simply declares a template that will produce the URIs it can handle. --e89a8fb2088859ac6004f3ee1671 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[dropping apps-discuss]

On Thu, Mar 6, 2014 at 10:56 AM, Tony Hanse= n <t= ony@att.com> wrote:

I disagree. The rule for such options should be that

*) any parameters that are unknown SHOULD be removed, as in "?needNets= =3D" from the previous example
*) the server MUST handle extension parameters that are empty
*) the server MUST treat extension parameters with an unexpanded value such= as "{needNets}" as if it were empty

In other words, if the server receives "?needNets=3D{needNets}" O= R "?needNets=3D" it needs to do the right thing.

And the "simple" sed script mentioned in the room that does expan= sion just needs an additional -e 's/{[^}]*}//g'.

I think the template would look like this:

If the client has no defin= ed value for needNets but wants a domain of = example.com, the expansion becomes:

http://rdap.server.name.here/rdap?domain=3Dexample.com

The server simply declares a template that will produce the = URIs it can handle.


--e89a8fb2088859ac6004f3ee1671-- From nobody Thu Mar 6 03:55:33 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02671A02A2 for ; Thu, 6 Mar 2014 03:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.357 X-Spam-Level: X-Spam-Status: No, score=-0.357 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_NEUTRAL=0.779] autolearn=no 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 6db56gep6bmX for ; Thu, 6 Mar 2014 03:55:29 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 39F7B1A026A for ; Thu, 6 Mar 2014 03:55:29 -0800 (PST) Received: (qmail 22265 invoked from network); 6 Mar 2014 11:55:25 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 6 Mar 2014 11:55:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5318622c.xn--30v786c.k1403; i=johnl@user.iecc.com; bh=ImQNSc9m3y3f3P6yDFvHdEYlxTcVbEy329jlwm7D8x8=; b=WRoSky4rE+13P4iSmw6jP5SIMgx3iJ6G8t/pBHBUNjw9WVLlw0Lre1aOTActJncvCORaEkdYMA42nl+koiOzmPiJB0CazfieZoBxeA2lnpq3drh3Y9XiQjZMaTlvjVk1YCGvtuZaQ/Xm66LCzxvnEbPXC+LEePFSzFQGsHBu361fyO1GiQy3+t4ti6eQh1uVT9KzjQt3btnmainAwK35uSZc0juvCnAZ5QQ0vH6VV2foQ70hDv2R1hqxEYBJGRmM DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5318622c.xn--30v786c.k1403; bh=ImQNSc9m3y3f3P6yDFvHdEYlxTcVbEy329jlwm7D8x8=; b=vXqfFjOXXQ3+DKI6O8e57vo9mm1KJspzTvjoVoxt+HSB+7v1WG02mKI+ePzioUUH60zTPq13jLDa1DdhVEIge876yI6hNLXDBlbs+0S/KCzwQd605ROMOT8BJ9H3IG0GZUK+qv7+Tzbl/SQ+hR+E5eLYxps5Ryc9R2NEM6dAJwViJPf+XGUR8ooTrvra+8bCqqYEBVi6V7nhl2fHtxxmoHhn306oWwzmnsTfSC8ngo6BqIRS1dwg+XW2Ux5loVae Date: 6 Mar 2014 11:55:02 -0000 Message-ID: <20140306115502.51570.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4hdvcvV_RlUzqaqH5yr_RLS1x6c Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:55:31 -0000 >I think the template would look like this: > >http://rdap.server.name.here/rdap{?domain,needNets} I think that if we're designing our own template format, we're in trouble. RFC 6570 is not my favorite RFC, but it seems unlikely we'd describe anything better. Speaking of better, an IANA registry of URI prefixes and another IANA registry of fixed suffix formats is looking better every day. R's, John From nobody Thu Mar 6 04:02:51 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A8E1A01C9 for ; Thu, 6 Mar 2014 04:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 n3thQplklizS for ; Thu, 6 Mar 2014 04:02:47 -0800 (PST) Received: from smtp1.dfinet.ch (smtp1.dfinet.ch [195.70.10.88]) by ietfa.amsl.com (Postfix) with SMTP id 796F41A008D for ; Thu, 6 Mar 2014 04:02:46 -0800 (PST) Received: (qmail 27450 invoked from network); 6 Mar 2014 12:02:41 -0000 X-Spam-CTCH-RefID: str=0001.0A0C0201.531863E1.008B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Received: from unknown (HELO ip167-164.axone.ch) (axonesmtp@dfimail.ch@127.0.0.1) by localhost with ESMTPA; 6 Mar 2014 12:02:41 -0000 Message-ID: <531863E6.9050702@axone.ch> Date: Thu, 06 Mar 2014 13:02:46 +0100 From: Werner Staub User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: weirds@ietf.org References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Antispam-Antivirus-Scanned: safemail.ch Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/U1Srv7vwfOhqcipOTlZj7XXAimo Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 12:02:49 -0000 Without excluding optional formats of higher complexity, the most convenient default style would be http://rdap.server.name.here/#example.com In the absence of a question mark and an equal sign, the search would be for the domain that follows the hash (#). The role of the hash sign would be treat the entire query string as an anchor in HTML terms, allowing browsers to change it with Javascript when the user searches for another domain. A good illustration is wikimapia.org where the geolocation permalink is updated based on user action. On 2014-03-06 12:03 , Murray S. Kucherawy wrote: > [dropping apps-discuss] > > On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen > wrote: > > > I disagree. The rule for such options should be that > > *) any parameters that are unknown SHOULD be removed, as in > "?needNets=" from the previous example > *) the server MUST handle extension parameters that are empty > *) the server MUST treat extension parameters with an unexpanded > value such as "{needNets}" as if it were empty > > In other words, if the server receives "?needNets={needNets}" OR > "?needNets=" it needs to do the right thing. > > And the "simple" sed script mentioned in the room that does > expansion just needs an additional -e 's/{[^}]*}//g'. > > > I think the template would look like this: > > http://rdap.server.name.here/rdap{?domain,needNets} > > If the client has no defined value for needNets but wants a domain of > example.com , the expansion becomes: > > http://rdap.server.name.here/rdap?domain=example.com > > If needNets is defined but empty: > > http://rdap.server.name.here/rdap?domain=example.com?needNets= > > The server simply declares a template that will produce the URIs it can > handle. > > > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > From nobody Thu Mar 6 04:03:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EA11A02E8 for ; Thu, 6 Mar 2014 04:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 leSgQE6SLyMZ for ; Thu, 6 Mar 2014 04:03:19 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 972731A02C6 for ; Thu, 6 Mar 2014 04:03:19 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id lj1so2545893pab.22 for ; Thu, 06 Mar 2014 04:03:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dxyqiHWXUtYeNb+tYNKtNQB+sLPhpcIHwZjv9G5iMfE=; b=yFHi/uq3zok1S7z48WAFnUUpMD5jYmJ0U2SYcIQq05EiLl3dEqHdoLFl9SRDzi1K6L JfyHM4x79gL34P/sIA95jiLQEErNYQHEpkHdi6TWRLOzWeB3jl1JVxefvU8Z9nzhn8FN iQ6YxZ2Ro39vQZhYO+hir6PrXtFIMD9xzGYQPoedzx4Cqi/vobZ0oU5yM6eLXj+frIS+ O3txtZomkaafg8cB/7svO0pyuu7SdcY3Zd04wqGLikQCk+Z3JV1Nw6K+7ofJbiJ4+BLY oEAhX02wfsiVsul4I9H/TmlQ3/s1F8rk8ik1399rJ8O4SFwH/DH6wY5KhneespySfqn0 IiTA== MIME-Version: 1.0 X-Received: by 10.66.163.138 with SMTP id yi10mr13649791pab.95.1394107395813; Thu, 06 Mar 2014 04:03:15 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 04:03:15 -0800 (PST) In-Reply-To: References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> Date: Thu, 6 Mar 2014 12:03:15 +0000 Message-ID: From: "Murray S. Kucherawy" To: Andrew Newton Content-Type: multipart/alternative; boundary=047d7b86f2621b37ba04f3eeecc4 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/ACJlQz2aXWVxllZsJqdcDn9vqwg Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 12:03:21 -0000 --047d7b86f2621b37ba04f3eeecc4 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton wrote: > > If the first URI template is http://service/domain/{domain} and the > RIRs modify their templates to > http://service/domain/{domain}?needNets={needNets}, clients unaware of > the extension will not know to substitute anything for "needNets". > Simple substitution, as proposed at the meeting, does not work here. > > Also, I'm not sure I'm a fan of a query syntax where part of the question follows path syntax and part of it follows query syntax. --047d7b86f2621b37ba04f3eeecc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 7:58 AM, Andrew Newton <andy@hxr.us&= gt; wrote:
=

If the first URI template is http://service/domain/{domain} and the
RIRs modify their templates to
http://service/domain/{domain}?needNets=3D{needNets}, clients u= naware of
the extension will not know to substitute anything for "needNets"= .
Simple substitution, as proposed at the meeting, does not work here.


Also, I'm not sure I'm a fan o= f a query syntax where part of the question follows path syntax and part of= it follows query syntax.
--047d7b86f2621b37ba04f3eeecc4-- From nobody Thu Mar 6 05:14:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40551A025E for ; Thu, 6 Mar 2014 05:14:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 beqlqLzlgtHl for ; Thu, 6 Mar 2014 05:14:12 -0800 (PST) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id CAD4A1A02C4 for ; Thu, 6 Mar 2014 05:14:12 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s26DE7oA025659 for ; Thu, 6 Mar 2014 05:14:08 -0800 Received: from vpn-135-70-100-231.vpn.swst.att.com ([135.70.100.231]) by maillennium.att.com (mailgw1) with ESMTP id <20140306131407gw100j0c4de>; Thu, 6 Mar 2014 13:14:07 +0000 X-Originating-IP: [135.70.100.231] Message-ID: <5318749E.9080205@att.com> Date: Thu, 06 Mar 2014 08:14:06 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: "weirds@ietf.org" References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020902050308090208000000" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/QIOb-OGsYbk82qPJEoh3_BO5zaU Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:14:15 -0000 This is a multi-part message in MIME format. --------------020902050308090208000000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/6/14, 6:03 AM, Murray S. Kucherawy wrote: > [dropping apps-discuss] > > On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen > wrote: > > > I disagree. The rule for such options should be that > > *) any parameters that are unknown SHOULD be removed, as in > "?needNets=" from the previous example > *) the server MUST handle extension parameters that are empty > *) the server MUST treat extension parameters with an unexpanded > value such as "{needNets}" as if it were empty > > In other words, if the server receives "?needNets={needNets}" OR > "?needNets=" it needs to do the right thing. > > And the "simple" sed script mentioned in the room that does > expansion just needs an additional -e 's/{[^}]*}//g'. > > > I think the template would look like this: > > http://rdap.server.name.here/rdap{?domain,needNets} > I hope not. That is no longer something that can be expanded through a *simple* script. > If the client has no defined value for needNets but wants a domain of > example.com , the expansion becomes: > > http://rdap.server.name.here/rdap?domain=example.com > > If needNets is defined but empty: > > http://rdap.server.name.here/rdap?domain=example.com?needNets= This is not a legal URL. The "?needNets=" should be "&needNets=" > > The server simply declares a template that will produce the URIs it > can handle. I agree with this. Tony --------------020902050308090208000000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/6/14, 6:03 AM, Murray S. Kucherawy wrote:
[dropping apps-discuss]

On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen <tony@att.com> wrote:

I disagree. The rule for such options should be that

*) any parameters that are unknown SHOULD be removed, as in "?needNets=" from the previous example
*) the server MUST handle extension parameters that are empty
*) the server MUST treat extension parameters with an unexpanded value such as "{needNets}" as if it were empty

In other words, if the server receives "?needNets={needNets}" OR "?needNets=" it needs to do the right thing.

And the "simple" sed script mentioned in the room that does expansion just needs an additional -e 's/{[^}]*}//g'.

I think the template would look like this:


I hope not. That is no longer something that can be expanded through a *simple* script.

If the client has no defined value for needNets but wants a domain of example.com, the expansion becomes:


This is not a legal URL. The "?needNets=" should be "&needNets="


The server simply declares a template that will produce the URIs it can handle.

I agree with this.

    Tony

--------------020902050308090208000000-- From nobody Thu Mar 6 05:26:32 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB4A1A00A9 for ; Thu, 6 Mar 2014 05:26:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 oaGNVkIHaR6l for ; Thu, 6 Mar 2014 05:26:29 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 06AAB1A0073 for ; Thu, 6 Mar 2014 05:26:28 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id x10so2527078pdj.34 for ; Thu, 06 Mar 2014 05:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=etujNUblnwN0O6M2zmvMVKypDohrac3fzk0CC/Sta7Q=; b=RY12KX9BMXS4Cp51/1gNTdGPmGi8P+mJ3bozG2rGjvhJHNQ5PKDQZS2r8xTWep2CHB +62BjkVhEey4df3DtmLFyGv24JOGbzO1vXd5VtICLsPhi0e2YQiun2KYsuSyjTvxUlhN UsIz5qalOk8s9XaPlo2EA430cpOUy134+6ObIP6th2/Hj/DVkV5KbvesSIlM1rhKsKfc UiZXV6V5WvBUEV/RRf7D+qdiyGSU4i2FZx5cM3+J0vY33qfLPmuDZ4jpnKi4HTroQs1F a7zuoy5xXjTHzt9MQKUUHuUGTUJZ0A3f3E9IyndIp+TlCtvtuus1dD5t1jXjDfUEXyko 8ibw== MIME-Version: 1.0 X-Received: by 10.68.231.35 with SMTP id td3mr14024984pbc.137.1394112385232; Thu, 06 Mar 2014 05:26:25 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 05:26:25 -0800 (PST) In-Reply-To: <5318749E.9080205@att.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> <5318749E.9080205@att.com> Date: Thu, 6 Mar 2014 13:26:25 +0000 Message-ID: From: "Murray S. Kucherawy" To: Tony Hansen Content-Type: multipart/alternative; boundary=047d7b33d5927fb57304f3f01539 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/YMsJZjyUdRa3o8Zg4Sh1sJkSyiU Cc: "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:26:31 -0000 --047d7b33d5927fb57304f3f01539 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 1:14 PM, Tony Hansen wrote: > I think the template would look like this: > > > http://rdap.server.name.here/rdap{?domain,needNets} > > > I hope not. That is no longer something that can be expanded through a > *simple* script. > I'm saying under RFC6570, that's the template you'd use to handle this use case. The simpler template Andy's talking about is something like: http://rdap.server.name.here/rdap/{domain}?needNets={needNets} ...which could be resolved with two string substitutions. What if there are three parameters? Or four? Or a dozen? > If the client has no defined value for needNets but wants a domain of > example.com, the expansion becomes: > > http://rdap.server.name.here/rdap?domain=example.com > > If needNets is defined but empty: > > http://rdap.server.name.here/rdap?domain=example.com?needNets= > > > This is not a legal URL. The "?needNets=" should be "&needNets=" > Right, sorry, my typo. --047d7b33d5927fb57304f3f01539 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 1:14 PM, Tony Hansen <tony@att.com&= gt; wrote:
=
=20 =20 =20
I think the tem= plate would look like this:

I hope not. That is no longer something that can be expanded through a *simple* script.

I'm saying= under RFC6570, that's the template you'd use to handle this use ca= se.=A0 The simpler template Andy's talking about is something like:

...which could be resolved with two string sub= stitutions.

What if there are three parameters?=A0 Or four?=A0 Or a doze= n?


If the client has no defined value for needNets but wants a domain of example.com, the expansion becomes:


This is not a legal URL. The "?needNets=3D" should be "&= amp;needNets=3D"

Right, sorry, m= y typo.
--047d7b33d5927fb57304f3f01539-- From nobody Thu Mar 6 05:28:38 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6831A02C6 for ; Thu, 6 Mar 2014 05:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.547] 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 LJ958zSieLL8 for ; Thu, 6 Mar 2014 05:28:28 -0800 (PST) Received: from egssmtp03.att.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA191A023E for ; Thu, 6 Mar 2014 05:28:28 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com ( egs 8.14.5/8.14.5) with ESMTP id s26DSNwh027274 for ; Thu, 6 Mar 2014 05:28:24 -0800 Received: from vpn-135-70-100-231.vpn.swst.att.com ([135.70.100.231]) by maillennium.att.com (mailgw1) with ESMTP id <20140306132823gw100j0c4ee>; Thu, 6 Mar 2014 13:28:23 +0000 X-Originating-IP: [135.70.100.231] Message-ID: <531877F6.1040608@att.com> Date: Thu, 06 Mar 2014 08:28:22 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: weirds@ietf.org References: <20140306115502.51570.qmail@joyce.lan> In-Reply-To: <20140306115502.51570.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/fVku90p8r7I6Tlm9yk23LHvX4kE Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:28:30 -0000 On 3/6/14, 6:55 AM, John Levine wrote: >> I think the template would look like this: >> >> http://rdap.server.name.here/rdap{?domain,needNets} > I think that if we're designing our own template format, we're in > trouble. RFC 6570 is not my favorite RFC, but it seems unlikely > we'd describe anything better. And suddenly we go from super-simple templates to something requiring a complete parser. But I do agree with the sentiment. I'm not a great fan of the URI Template language, but it DOES have the advantages of being well defined and freely available code. Tony Hansen > Speaking of better, an IANA registry of URI prefixes and another > IANA registry of fixed suffix formats is looking better every day. From nobody Thu Mar 6 05:35:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1661A01F3 for ; Thu, 6 Mar 2014 05:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.425 X-Spam-Level: X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.547] autolearn=no 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 0oz1KR_Ge3GD for ; Thu, 6 Mar 2014 05:35:28 -0800 (PST) Received: from egssmtp01.att.com (egssmtp01.att.com [144.160.112.12]) by ietfa.amsl.com (Postfix) with ESMTP id E28921A01AE for ; Thu, 6 Mar 2014 05:35:27 -0800 (PST) Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp01.att.com ( egs 8.14.5/8.14.5) with ESMTP id s26DZNlW015795 for ; Thu, 6 Mar 2014 07:35:23 -0600 Received: from vpn-135-70-100-231.vpn.swst.att.com ([135.70.100.231]) by maillennium.att.com (mailgw1) with ESMTP id <20140306133522gw100j0c4fe>; Thu, 6 Mar 2014 13:35:23 +0000 X-Originating-IP: [135.70.100.231] Message-ID: <53187999.1060206@att.com> Date: Thu, 06 Mar 2014 08:35:21 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 CC: "weirds@ietf.org" References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> <5318749E.9080205@att.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020304000509000209020305" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/v2EanK4vS_NJnAq4QWxQ2ieRjuQ Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 13:35:29 -0000 This is a multi-part message in MIME format. --------------020304000509000209020305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/6/14, 8:26 AM, Murray S. Kucherawy wrote: > On Thu, Mar 6, 2014 at 1:14 PM, Tony Hansen > wrote: > > I think the template would look like this: >> >> http://rdap.server.name.here/rdap{?domain,needNets} >> > > I hope not. That is no longer something that can be expanded > through a *simple* script. > > > I'm saying under RFC6570, that's the template you'd use to handle this > use case. The simpler template Andy's talking about is something like: > > http://rdap.server.name.here/rdap/{domain}?needNets={needNets} > > > ...which could be resolved with two string substitutions. > > What if there are three parameters? Or four? Or a dozen? I think both scale the same. From the description at the meeting, it was NOT clear that 6570 URI Templates were being described, especially since there was the remark about simple templates that could be easily processed by a simple script. 6570 templates definitely do NOT match this description. But I don't think it's a problem if we go in the direction of 6570 instead of "simple templates". Tony --------------020304000509000209020305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/6/14, 8:26 AM, Murray S. Kucherawy wrote:
On Thu, Mar 6, 2014 at 1:14 PM, Tony Hansen <tony@att.com> wrote:
I think the template would look like this:

I hope not. That is no longer something that can be expanded through a *simple* script.

I'm saying under RFC6570, that's the template you'd use to handle this use case.  The simpler template Andy's talking about is something like:

...which could be resolved with two string substitutions.

What if there are three parameters?  Or four?  Or a dozen?

I think both scale the same.

From the description at the meeting, it was NOT clear that 6570 URI Templates were being described, especially since there was the remark about simple templates that could be easily processed by a simple script. 6570 templates definitely do NOT match this description.

But I don't think it's a problem if we go in the direction of 6570 instead of "simple templates".

    Tony
--------------020304000509000209020305-- From nobody Thu Mar 6 06:58:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDB91A0102 for ; Thu, 6 Mar 2014 06:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable 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 6GCquaGgePHJ for ; Thu, 6 Mar 2014 06:58:01 -0800 (PST) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC791A0083 for ; Thu, 6 Mar 2014 06:58:01 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id rd3so2768355pab.11 for ; Thu, 06 Mar 2014 06:57:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jC3H10mTH+iPN97yaAaKfihr8RTH7C/hFjI3qVftuc4=; b=H6I1KlN2eQrXGqC2NIC5vie5sk2DRvtW0eFdqKLvyF9e7YxToQFzGAkq3wm1HxbDla nkPd9LaLsfUYVZZQJJYXkMXEu55FQQ7vc4u1xeLztt5ZRmY8P2W2naS6pruafsESSgSp 9Z1Ed9kkryxtsjHVcPQzWrDy+tfFRutA4StC0M5fdXTwZvL37snnUBaBrW8P5v2Nnvb5 xcORzcygYaKuuY5LhHNYDv64oO1pcqgHLIbXeV+o+kABFP7PK/g3c41NALDU0SwA1LBC QJ2aIf3661Rz99XECniyBSKPraJ174mJhDHSuAhDZ5SvkNfM1yaX3ZwmudmWU7yztBME V+AA== X-Gm-Message-State: ALoCoQnu4TxV7mtBczCudwZ43vP89Z9ujXHf9BlnXgDVtWorcyefXVIHHw6zmWDHRrYyj7VkmzcP MIME-Version: 1.0 X-Received: by 10.68.34.197 with SMTP id b5mr769628pbj.16.1394117877505; Thu, 06 Mar 2014 06:57:57 -0800 (PST) Received: by 10.68.143.4 with HTTP; Thu, 6 Mar 2014 06:57:57 -0800 (PST) X-Originating-IP: [2001:67c:1232:152:c518:ef56:9da0:3c21] In-Reply-To: <5318547A.80805@att.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> Date: Thu, 6 Mar 2014 14:57:57 +0000 Message-ID: From: Andrew Newton To: Tony Hansen Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/F9N91IRTwu9N7X14bArBC5qyjD0 Cc: "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:58:03 -0000 Thanks Tony, I think that answers my question. -andy On Thu, Mar 6, 2014 at 10:56 AM, Tony Hansen wrote: > On 3/6/14, 2:58 AM, Andrew Newton wrote: >> >> My major objection to URI templates was the extra retrieval of the >> template, but that is solved with their inclusion in the bootstrap. >> >> However, looking at a real world extension to one of the existing RDAP >> queries I am beginning to wonder if URI templates are more of a >> liability. Currently /domain/example.com returns the relevant domain >> registration, info about DNSSEC, nameservers, contacts, etc... For >> /domain/136.192.in-addr.arpa there may sometimes be a need to add in >> related network registration information (actually, RIPE and ARIN do >> this today with their custom REST interfaces). To signal this a client >> could optionally add the query parameter ?needNets=true. >> >> If the first URI template is http://service/domain/{domain} and the >> RIRs modify their templates to >> http://service/domain/{domain}?needNets={needNets}, clients unaware of >> the extension will not know to substitute anything for "needNets". >> Simple substitution, as proposed at the meeting, does not work here. > > > I disagree. The rule for such options should be that > > *) any parameters that are unknown SHOULD be removed, as in "?needNets=" > from the previous example > *) the server MUST handle extension parameters that are empty > *) the server MUST treat extension parameters with an unexpanded value such > as "{needNets}" as if it were empty > > In other words, if the server receives "?needNets={needNets}" OR > "?needNets=" it needs to do the right thing. > > And the "simple" sed script mentioned in the room that does expansion just > needs an additional -e 's/{[^}]*}//g'. > > Tony Hansen > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Mar 6 07:20:43 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585DE1A0070 for ; Thu, 6 Mar 2014 07:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 qQ9LOoFOIC88 for ; Thu, 6 Mar 2014 07:20:39 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8CE1A0026 for ; Thu, 6 Mar 2014 07:20:39 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id uo5so2737837pbc.38 for ; Thu, 06 Mar 2014 07:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZwDcjedHu8tSBQcCjmup14n3YkonFcstda6u2nMEXbI=; b=yl18r53UucU4FjMyYYCjhs0R2cbL8ofTCh3+7M4vGjsy7oVftdHeeAYtLEo2NtlPj+ RvM+ceGjOAq8jaXyY5p0CZa7rQh7o2fkcLo+5uQVnVJVAoiOOrfk22LAR7m8cXfdYQRh eqbyUbT5DacT2SFO6RUDqT80u3wqeMUupWIKxmaczjds+f0UG7VQqGcluvgVbmMbC7XR 40KcXY9T+k/z983xXt8M+a0UQxi722kWlOcfHNfGbETw1AMIIEpWuODsPm730rSIvF+h wT35fCimW7q1D8xWsfkV/w1a3t7cMDQOkrKovFc06BF/cgvynaa1Y2btTlt70ItDIOaU 3lEQ== MIME-Version: 1.0 X-Received: by 10.68.170.36 with SMTP id aj4mr15364548pbc.54.1394119235795; Thu, 06 Mar 2014 07:20:35 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 07:20:35 -0800 (PST) In-Reply-To: <53187999.1060206@att.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> <5318749E.9080205@att.com> <53187999.1060206@att.com> Date: Thu, 6 Mar 2014 15:20:35 +0000 Message-ID: From: "Murray S. Kucherawy" To: Tony Hansen Content-Type: multipart/alternative; boundary=047d7bacb21cd3002404f3f1ad01 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/6-gNPY9_aXCvdgJ2Ikx9RMTJD9k Cc: "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:20:41 -0000 --047d7bacb21cd3002404f3f1ad01 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 1:35 PM, Tony Hansen wrote: > > From the description at the meeting, it was NOT clear that 6570 URI > Templates were being described, especially since there was the remark about > simple templates that could be easily processed by a simple script. 6570 > templates definitely do NOT match this description. > http://www.example.com/rdap/{domain} is a subset of what RFC6570 enables. > But I don't think it's a problem if we go in the direction of 6570 instead > of "simple templates". > To be clear, I fully agree that supporting URI templates in WEIRDS does make clients more complex. It would make any client more complex. However, given that there are dozens of implementations in various languages, the complexity is well understood by now, and thus very manageable in things that will use them. I believe the pain WEIRDS has to take on here is being over-stated. I also think, and I believe Scott agreed (and he should correct me if otherwise), that this is an appropriate thing to do now rather than later in the name of extensibility. -MSK --047d7bacb21cd3002404f3f1ad01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 1:35 PM, Tony Hansen <tony@att.com&= gt; wrote:
=
=20 =20 =20

From the description at the meeting, it was NOT clear that 6570 URI Templates were being described, especially since there was the remark about simple templates that could be easily processed by a simple script. 6570 templates definitely do NOT match this description.

http://www.example.com/rdap/{domain} i= s a subset of what RFC6570 enables.


But I don't think it's a problem if we go in the direction of 6= 570 instead of "simple templates".

To be clear, I ful= ly agree that supporting URI templates in WEIRDS does make clients more com= plex.=A0 It would make any client more complex.=A0 However, given that ther= e are dozens of implementations in various languages, the complexity is wel= l understood by now, and thus very manageable in things that will use them.= =A0 I believe the pain WEIRDS has to take on here is being over-stated.

I also think, and I believe Scott agreed (and he should corr= ect me if otherwise), that this is an appropriate thing to do now rather th= an later in the name of extensibility.

-MSK
--047d7bacb21cd3002404f3f1ad01-- From nobody Thu Mar 6 07:26:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A141A00CD for ; Thu, 6 Mar 2014 07:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 BlsqdgD7QgyU for ; Thu, 6 Mar 2014 07:26:30 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B71A00AE for ; Thu, 6 Mar 2014 07:26:28 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUxiToFab/Nxk02G7wxgwcoDK50zq3DdZ@postini.com; Thu, 06 Mar 2014 07:26:26 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s26FQN7I002473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 10:26:23 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 10:26:24 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , Tony Hansen Thread-Topic: [weirds] [apps-discuss] WEIRDS WG report Thread-Index: AQHPOU+kxNQBCxQfhE+ZxLHKrexHgprULepw Date: Thu, 6 Mar 2014 15:26:22 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4936D44E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <5318547A.80805@att.com> <5318749E.9080205@att.com> <53187999.1060206@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: multipart/alternative; boundary="_000_831693C2CDA2E849A7D7A712B24E257F4936D44EBRN1WNEXMBX01vc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/FQQ2x72XD4B_hYywnhDB-4Ln9ss Cc: "weirds@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:26:34 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4936D44EBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucher= awy Sent: Thursday, March 06, 2014 10:21 AM To: Tony Hansen Cc: weirds@ietf.org Subject: Re: [weirds] [apps-discuss] WEIRDS WG report On Thu, Mar 6, 2014 at 1:35 PM, Tony Hansen > wrote: >From the description at the meeting, it was NOT clear that 6570 URI Templat= es were being described, especially since there was the remark about simple= templates that could be easily processed by a simple script. 6570 template= s definitely do NOT match this description. http://www.example.com/rdap/{domain} is a subset of what RFC6570 enables. But I don't think it's a problem if we go in the direction of 6570 instead = of "simple templates". To be clear, I fully agree that supporting URI templates in WEIRDS does mak= e clients more complex. It would make any client more complex. However, g= iven that there are dozens of implementations in various languages, the com= plexity is well understood by now, and thus very manageable in things that = will use them. I believe the pain WEIRDS has to take on here is being over= -stated. I also think, and I believe Scott agreed (and he should correct me if other= wise), that this is an appropriate thing to do now rather than later in the= name of extensibility. [SAH] Yes, that's what I said. If we're going to do this we'd be far better= off doing it now. Scott --_000_831693C2CDA2E849A7D7A712B24E257F4936D44EBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: weirds [= mailto:weirds-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, March 06, 2014 10:21 AM
To: Tony Hansen
Cc: weirds@ietf.org
Subject: Re: [weirds] [apps-discuss] WEIRDS WG report

 

On Thu, Mar 6, 2014 at 1:35 PM, Tony Hansen <tony@att.com> wrote:


>From the description at the meeting, it was NOT clear that 6570 URI Templat= es were being described, especially since there was the remark about simple= templates that could be easily processed by a simple script. 6570 template= s definitely do NOT match this description.

 

http://www.example.com/rdap/{domain} is= a subset of what RFC6570 enables.


But I don't think it's a problem if we go in the direction of 6570 instead = of "simple templates".

 

To be clear, I fully = agree that supporting URI templates in WEIRDS does make clients more comple= x.  It would make any client more complex.  However, given that t= here are dozens of implementations in various languages, the complexity is well understood by now, and thus very managea= ble in things that will use them.  I believe the pain WEIRDS has to ta= ke on here is being over-stated.

I also think, and I b= elieve Scott agreed (and he should correct me if otherwise), that this is a= n appropriate thing to do now rather than later in the name of extensibilit= y.

[SAH] Yes, that’= s what I said. If we’re going to do this we’d be far better off= doing it now.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F4936D44EBRN1WNEXMBX01vc_-- From nobody Thu Mar 6 07:36:19 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4E21A0064; Thu, 6 Mar 2014 07:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 C6gbrD3HkJ0H; Thu, 6 Mar 2014 07:36:13 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1BE1A00DD; Thu, 6 Mar 2014 07:36:08 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id fp1so2698218pdb.28 for ; Thu, 06 Mar 2014 07:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=17MxNZQ0sjfaCRo5WaBSnwZMUssFDoqwprAaGXN6mn0=; b=BkHjX21+zX2fUIiTD8VqF+tVBU8mxy+8gSavNYHtJdKPISKY8SBWn6wSjjrRRZs3gm Jgf8qwA9cNOICsCzZHxcTGNQz7uBtVDZv7J3mmE70ONJhLmm84VUrTG6p0Ppao4U4CD7 7FM9HEULcseFAnrxdiU+ERrv8712r0nvtrHU6We0x+hllBxf1dbfGJ4yrpiACtLuRoMF ad7pmsQV+t6FWWpYKkLpAuoIixf4apwzDCUMOLXjj/QKwFGn2bOGuQc/xOCCrJmfhfG9 uCMbIxbmgdODvDF/h7BOwUjXBjl7Om1jJ3AYmR1rmQlqPmG708pG57c30IpP5wfMk+/a FLjg== MIME-Version: 1.0 X-Received: by 10.66.118.71 with SMTP id kk7mr15328711pab.14.1394120164274; Thu, 06 Mar 2014 07:36:04 -0800 (PST) Received: by 10.66.220.102 with HTTP; Thu, 6 Mar 2014 07:36:04 -0800 (PST) In-Reply-To: <53188B3A.9070000@ninebynine.org> References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> <53188B3A.9070000@ninebynine.org> Date: Thu, 6 Mar 2014 15:36:04 +0000 Message-ID: From: "Murray S. Kucherawy" To: Graham Klyne Content-Type: multipart/alternative; boundary=e89a8ffbad052a757104f3f1e521 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/7sI0EC-Zp2l0XDwuyBIj7MgoGzM Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:36:16 -0000 --e89a8ffbad052a757104f3f1e521 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 6, 2014 at 2:50 PM, Graham Klyne wrote: > Thus, the main problem I see is the extra round trip that may be needed to > fully realize the benefit of using templates. I can't judge if this is > acceptable, but I note that the protocol design already anticipates > additional round trips in the form of HTTP redirects. > One of the original concerns we had with using URI templates was the two round trips: one to get the template, one to execute the template. If the template is stored in the bootstrap table, one of those round trips is replaced by a local filesystem operation, and we're left with just the query, which we have to make under any model. > The problem I see with putting URI templates in the bootstrap (which some > comments in the meeting noted could lead to their being hard-coded in > client applications) is that we are not significantly better off than the > current prefix-based solution, but with the added complexity of having to > deal with (or circumvent) the use of URI templates. It also introduces the > spectre of NxM entries in the bootstrap registry as John has noted. > Further, how would it work with redirects to a different server that might > use a different URI sub-structure? > I don't believe either of those are particularly ugly impositions, unless one considers anything with non-zero cost to be ugly. If the registry has NxM entries and is expressed in (say) JSON, the JSON parser will still make extraction of the desired values easy. Nobody has argued (yet) that doing the bootstrap table in JSON is a problem, so I'm assuming for the sake of argument that that's given. If we use templates instead of prefixes, then there needs to be a function of some kind to make the substitutions, and it's a question of whether that's something like "sed" or something that implements full template expansion. Having tried both under the REPUTE work, my experience suggests that they are actually of almost equal complexity. Also, the following two things are, to me, logically equivalent: 1) Take URI prefix "X", append "/domain/", then append the domain name you're interested in. Query the result. 2) Take URI template "X/domain/{domain}", and replace "{domain}" with the domain name you're interested in. Query the result. If you buy that argument, then we're really arguing about whether a string append operation is substantially more complex than a substring replace operation. There are ample implementations of both, so I don't believe that's an issue. Since people like to use the shell script as the baseline, this amounts to a call to "sed" (available, and free), or a call to a different tool (available, and free) that can expand templates. Also in either approach, we need to enumerate all the supported substitutions for a given query type and what values should be used in those substitutions. There's no added documentation burden there. If the primary concern is the "get-off-my-lawn" argument, then I think the > prefix solution is probably good enough, but if adopted I think it would be > appropriate to include some commentary addressing the concerns of > http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn(specifically sections 1 and 2.3). A wider concern is that publication of > this as a standard might be seen as a precedent to doing it in situations > where the detrimental impact of constraints on URI patterns would be more > severe. > > I think such commentary might include mention of the fact that the service > is not for general deployment, but is expected to be fielded by specific > organizations for quite specific purposes, and that the bootstrap prefix > mechanism means that clients can be told to use a different part of the > service's URI space if operational circumstances change. Thus, the need to > retain compatibility with properly implemented clients does not completely > block changes to the service provision environment. > Yes, this was the sentiment at the end of the design team meeting; using prefixes in the registry instead of templates would probably skate by the get-off-my-lawn-draft, and the burden would be on us to explain why that's so. -MSK --e89a8ffbad052a757104f3f1e521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 6, 2014 at 2:50 PM, Graham Klyne <GK@ninebyni= ne.org> wrote:
Thus, the main probl= em I see is the extra round trip that may be needed to fully realize the be= nefit of using templates. =A0I can't judge if this is acceptable, but I= note that the protocol design already anticipates additional round trips i= n the form of HTTP redirects.

One of the original concerns we had = with using URI templates was the two round trips: one to get the template, = one to execute the template.=A0 If the template is stored in the bootstrap = table, one of those round trips is replaced by a local filesystem operation= , and we're left with just the query, which we have to make under any m= odel.
=A0
<= div> The problem I see with putting URI templates in the bootstrap (which some c= omments in the meeting noted could lead to their being hard-coded in client= applications) is that we are not significantly better off than the current= prefix-based solution, but with the added complexity of having to deal wit= h (or circumvent) the use of URI templates. =A0It also introduces the spect= re of NxM entries in the bootstrap registry as John has noted. =A0Further, = how would it work with redirects to a different server that might use a dif= ferent URI sub-structure?

I don't believe either of those = are particularly ugly impositions, unless one considers anything with non-z= ero cost to be ugly.=A0 If the registry has NxM entries and is expressed in= (say) JSON, the JSON parser will still make extraction of the desired valu= es easy.=A0 Nobody has argued (yet) that doing the bootstrap table in JSON = is a problem, so I'm assuming for the sake of argument that that's = given.

If we use templates instead of prefixes, then there needs to be a funct= ion of some kind to make the substitutions, and it's a question of whet= her that's something like "sed" or something that implements = full template expansion.=A0 Having tried both under the REPUTE work, my exp= erience suggests that they are actually of almost equal complexity.

Also, the following two things are, to me, logically equival= ent:

1) Take URI prefix "X", append "/doma= in/", then append the domain name you're interested in.=A0 Query t= he result.

2) Take URI template "X/domain/{domain}", and repl= ace "{domain}" with the domain name you're interested in.=A0 = Query the result.

If you buy that argument, th= en we're really arguing about whether a string append operation is subs= tantially more complex than a substring replace operation.=A0 There are amp= le implementations of both, so I don't believe that's an issue.=A0 = Since people like to use the shell script as the baseline, this amounts to = a call to "sed" (available, and free), or a call to a different t= ool (available, and free) that can expand templates.

Also in either approach, we need to enumerate all the suppor= ted substitutions for a given query type and what values should be used in = those substitutions.=A0 There's no added documentation burden there.

If the primary concern is the "get-off-my-lawn" argument, then I = think the prefix solution is probably good enough, but if adopted I think i= t would be appropriate to include some commentary addressing the concerns o= f http://tools.ietf.org/html/draft-ietf-appsawg-uri-ge= t-off-my-lawn (specifically sections 1 and 2.3). =A0A wider concern is = that publication of this as a standard might be seen as a precedent to doin= g it in situations where the detrimental impact of constraints on URI patte= rns would be more severe.

I think such commentary might include mention of the fact that the service = is not for general deployment, but is expected to be fielded by specific or= ganizations for quite specific purposes, and that the bootstrap prefix mech= anism means that clients can be told to use a different part of the service= 's URI space if operational circumstances change. =A0Thus, the need to = retain compatibility with properly implemented clients does not completely = block changes to the service provision environment.

Yes, this was the s= entiment at the end of the design team meeting; using prefixes in the regis= try instead of templates would probably skate by the get-off-my-lawn-draft,= and the burden would be on us to explain why that's so.

-MSK
--e89a8ffbad052a757104f3f1e521-- From nobody Thu Mar 6 07:49:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8C1A0002; Thu, 6 Mar 2014 06:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 8glbXcpPbDpu; Thu, 6 Mar 2014 06:51:26 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 6961E1A0070; Thu, 6 Mar 2014 06:51:26 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1WLZdn-00086V-e5; Thu, 06 Mar 2014 14:51:19 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1WLZdn-0005bJ-0S; Thu, 06 Mar 2014 14:51:19 +0000 Message-ID: <53188B3A.9070000@ninebynine.org> Date: Thu, 06 Mar 2014 14:50:34 +0000 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Andrew Newton References: <5316B4AC.4000701@it.aoyama.ac.jp> <20140305150713.4611.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/yIm_qopko-4mTN5m9M2K4iedPNA X-Mailman-Approved-At: Thu, 06 Mar 2014 07:49:06 -0800 Cc: John Levine , "weirds@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [weirds] [apps-discuss] WEIRDS WG report X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:51:36 -0000 I chimed in earlier on this discussion, and listened in on the WG meeting discussions this week. TL;DR: I'm thinking that the use of URI templates in the registry (bootstrap) is the worst kind of compromise, and I think this might be a case where the current non-templated solution is appropriate (but should be explained why it is). ... In my view, there are two distinct but related reasons to favour using templates: 1. the "get-off-my-lawn" argument, in that it allows services total control over the allocation and use of their URI space, and reduces the constraints on how the service may be deployed. 2. Long term flexibility, ala REST style (cf. Roy Fielding's "software design on a scale of decades" - http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-724). I mention this because there was an explicit mention in the WG meeting of a desire for flexibility/extensibility. I see using service-provided URI templates is *a* way to achieve this: coupling between the server and client is dramatically reduced, and as long as clients follow the appropriate procedures, the service can change and rearrange its URI space (effectively, its API) to meet evolving needs. But this comes at a cost. As Roy notes "Many of the [REST] constraints are directly opposed to short-term efficiency" (ibid.). The cost here is the extra round trip. I see that as the cost of long term flexibility, but I can't judge if that cost is too high (taking into account appropriate use of web cacheing, etc.) The other cost is client complexity. In my experience, the development overhead (complexity) of using URI Templates is non-zero, but is not great, given the range of libraries available. YMMV. The current WEIRDS document says: "The goal of this document is to tie together usage patterns of HTTP into a common profile applicable to the various types of Directory Services serving Registration Data using RESTful practices." If you are serious about following RESTful practices, then I think the cost of the extra round trip must be accepted. Otherwise, I'd urge deleting the qualification "using RESTful practices" (again, see the blog post and comments cited above). ... Thus, the main problem I see is the extra round trip that may be needed to fully realize the benefit of using templates. I can't judge if this is acceptable, but I note that the protocol design already anticipates additional round trips in the form of HTTP redirects. The problem I see with putting URI templates in the bootstrap (which some comments in the meeting noted could lead to their being hard-coded in client applications) is that we are not significantly better off than the current prefix-based solution, but with the added complexity of having to deal with (or circumvent) the use of URI templates. It also introduces the spectre of NxM entries in the bootstrap registry as John has noted. Further, how would it work with redirects to a different server that might use a different URI sub-structure? If the primary concern is the "get-off-my-lawn" argument, then I think the prefix solution is probably good enough, but if adopted I think it would be appropriate to include some commentary addressing the concerns of http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn (specifically sections 1 and 2.3). A wider concern is that publication of this as a standard might be seen as a precedent to doing it in situations where the detrimental impact of constraints on URI patterns would be more severe. I think such commentary might include mention of the fact that the service is not for general deployment, but is expected to be fielded by specific organizations for quite specific purposes, and that the bootstrap prefix mechanism means that clients can be told to use a different part of the service's URI space if operational circumstances change. Thus, the need to retain compatibility with properly implemented clients does not completely block changes to the service provision environment. ... HTH #g -- On 06/03/2014 07:58, Andrew Newton wrote: > My major objection to URI templates was the extra retrieval of the > template, but that is solved with their inclusion in the bootstrap. > > However, looking at a real world extension to one of the existing RDAP > queries I am beginning to wonder if URI templates are more of a > liability. Currently /domain/example.com returns the relevant domain > registration, info about DNSSEC, nameservers, contacts, etc... For > /domain/136.192.in-addr.arpa there may sometimes be a need to add in > related network registration information (actually, RIPE and ARIN do > this today with their custom REST interfaces). To signal this a client > could optionally add the query parameter ?needNets=true. > > If the first URI template is http://service/domain/{domain} and the > RIRs modify their templates to > http://service/domain/{domain}?needNets={needNets}, clients unaware of > the extension will not know to substitute anything for "needNets". > Simple substitution, as proposed at the meeting, does not work here. > > Should we move beyond the simple URI templates form, I believe John is > absolutely right about the complexity. It will be too much. > > -andy > > On Wed, Mar 5, 2014 at 3:07 PM, John Levine wrote: >>> Looking at the above "key-value table that supports longest-match >>> lookups resulting in URI templates that are then used to construct a >>> query that will either return an answer or a redirection", this to me >>> smells like over-engineering even just when reading it (not to speak of >>> having to implement it). >>> >>> Of course, if the WEIRDS WG is happy with that, ... >> >> Not particularly, but our preferred solution, a fixed URL suffix >> syntax that we append to a per-thing (domain, IP range, etc.) prefix >> is apparently forbidden to us. >> >> The redirects have been there all along to provide a less broken >> version of what thin WHOIS does now. >> >> R's, >> John >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Thu Mar 6 11:17:49 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923251A014C for ; Thu, 6 Mar 2014 11:17:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.848 X-Spam-Level: X-Spam-Status: No, score=-4.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, 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 YQZZP9W5eMgB for ; Thu, 6 Mar 2014 11:17:45 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E6F651A0102 for ; Thu, 6 Mar 2014 11:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1394133461; x=1425669461; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Z3JQHv+xtFrw9UROVvG+zO2al2v+XBpCWp8eeiCjySw=; b=fGdG2p9vqBDxFNGOLRBIx9ollU4U5esASYbDrNIyMFc3O4JmZQ/qOogf zVPNv+8YH0YFIcAP10D1weuZ7FuxLiMCY/1/3xHfnRbstYCVqx4ZopPXk VnYaT0Ma7giTRAeX9ePChz8F9Kb37cny/xKNusJ4NlKsdbMKZVrGDbeqb M=; X-IronPort-AV: E=McAfee;i="5400,1158,7369"; a="109959371" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 06 Mar 2014 11:16:43 -0800 X-IronPort-AV: E=Sophos;i="4.97,602,1389772800"; d="scan'208";a="641375221" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 06 Mar 2014 11:16:37 -0800 Received: from dhcp-ac59.meeting.ietf.org (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Mar 2014 11:16:23 -0800 Message-ID: <5318C982.1080503@qti.qualcomm.com> Date: Thu, 6 Mar 2014 19:16:18 +0000 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <831693C2CDA2E849A7D7A712B24E257F49368A9C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49368A9C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/NYWhkg_t7mK1wdZkG8UKI4pKxQI Cc: "weirds@ietf.org" Subject: Re: [weirds] [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 19:17:47 -0000 And there was an error in the posted version, so a new version (RFC 7159) was posted. Reference to that please. pr On 3/2/14 4:14 PM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: rfc-dist-bounces@rfc-editor.org [mailto:rfc-dist-bounces@rfc- >> editor.org] On Behalf Of rfc-editor@rfc-editor.org >> Sent: Sunday, March 02, 2014 11:10 AM >> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >> Cc: drafts-update-ref@iana.org; json@ietf.org; rfc-editor@rfc- >> editor.org >> Subject: [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) >> Data Interchange Format >> >> A new Request for Comments is now available in online RFC libraries. >> >> >> RFC 7158 >> >> Title: The JavaScript Object Notation (JSON) >> Data Interchange Format >> Author: T. Bray, Ed. >> Status: Standards Track >> Stream: IETF >> Date: March 2014 >> Mailbox: tbray@textuality.com >> Pages: 16 >> Characters: 27451 >> Obsoletes: RFC 4627 >> >> I-D Tag: draft-ietf-json-rfc4627bis-10.txt >> >> URL: http://www.rfc-editor.org/rfc/rfc7158.txt >> >> JavaScript Object Notation (JSON) is a lightweight, text-based, >> language-independent data interchange format. It was derived from >> the ECMAScript Programming Language Standard. JSON defines a small >> set of formatting rules for the portable representation of structured >> data. >> >> This document removes inconsistencies with other specifications of >> JSON, repairs specification errors, and offers experience-based >> interoperability guidance. >> >> This document is a product of the JavaScript Object Notation Working >> Group of the IETF. >> >> This is now a Proposed Standard. >> > We might need to update some references... > > Scott > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Mar 6 12:04:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0892B1A0192 for ; Thu, 6 Mar 2014 12:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Dtg7OyHS-bTQ for ; Thu, 6 Mar 2014 12:04:35 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 99FBE1A017D for ; Thu, 6 Mar 2014 12:04:34 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUxjUzvW0EP5RljMn4+sjpb6BpPb8/MJP@postini.com; Thu, 06 Mar 2014 12:04:31 PST Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id s26K4Tv1011245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 15:04:29 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 15:04:29 -0500 From: "Hollenbeck, Scott" To: Pete Resnick Thread-Topic: [weirds] [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format Thread-Index: AQHPOXCdjQzkXugK4Ey153kS5Nw0S5rUe656 Date: Thu, 6 Mar 2014 20:04:28 +0000 Message-ID: <5EF6D11D-207E-44D6-9CF6-B8FBBCF798F2@verisign.com> References: <831693C2CDA2E849A7D7A712B24E257F49368A9C@BRN1WNEXMBX01.vcorp.ad.vrsn.com>, <5318C982.1080503@qti.qualcomm.com> In-Reply-To: <5318C982.1080503@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/k5FQ03nQ9ac8U5M_763293xoIGM Cc: "weirds@ietf.org" Subject: Re: [weirds] [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) Data Interchange Format X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:04:39 -0000 Will do - thanks! Scott > On Mar 6, 2014, at 7:16 PM, "Pete Resnick" wr= ote: >=20 > And there was an error in the posted version, so a new version (RFC 7159)= was posted. Reference to that please. >=20 > pr >=20 > On 3/2/14 4:14 PM, Hollenbeck, Scott wrote: >>> -----Original Message----- >>> From: rfc-dist-bounces@rfc-editor.org [mailto:rfc-dist-bounces@rfc- >>> editor.org] On Behalf Of rfc-editor@rfc-editor.org >>> Sent: Sunday, March 02, 2014 11:10 AM >>> To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org >>> Cc: drafts-update-ref@iana.org; json@ietf.org; rfc-editor@rfc- >>> editor.org >>> Subject: [rfc-dist] RFC 7158 on The JavaScript Object Notation (JSON) >>> Data Interchange Format >>>=20 >>> A new Request for Comments is now available in online RFC libraries. >>>=20 >>>=20 >>> RFC 7158 >>>=20 >>> Title: The JavaScript Object Notation (JSON) >>> Data Interchange Format >>> Author: T. Bray, Ed. >>> Status: Standards Track >>> Stream: IETF >>> Date: March 2014 >>> Mailbox: tbray@textuality.com >>> Pages: 16 >>> Characters: 27451 >>> Obsoletes: RFC 4627 >>>=20 >>> I-D Tag: draft-ietf-json-rfc4627bis-10.txt >>>=20 >>> URL: http://www.rfc-editor.org/rfc/rfc7158.txt >>>=20 >>> JavaScript Object Notation (JSON) is a lightweight, text-based, >>> language-independent data interchange format. It was derived from >>> the ECMAScript Programming Language Standard. JSON defines a small >>> set of formatting rules for the portable representation of structured >>> data. >>>=20 >>> This document removes inconsistencies with other specifications of >>> JSON, repairs specification errors, and offers experience-based >>> interoperability guidance. >>>=20 >>> This document is a product of the JavaScript Object Notation Working >>> Group of the IETF. >>>=20 >>> This is now a Proposed Standard. >> We might need to update some references... >>=20 >> Scott >>=20 >> _______________________________________________ >> weirds mailing list >> weirds@ietf.org >> https://www.ietf.org/mailman/listinfo/weirds >=20 > --=20 > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 >=20 From nobody Wed Mar 12 10:57:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6448D1A066A for ; Wed, 12 Mar 2014 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] 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 Y58_7S0hGt2B for ; Wed, 12 Mar 2014 10:57:20 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBDB1A063C for ; Wed, 12 Mar 2014 10:57:20 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 3E4551653A4; Wed, 12 Mar 2014 13:57:14 -0400 (EDT) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 4FCFD165337; Wed, 12 Mar 2014 13:57:13 -0400 (EDT) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 12 Mar 2014 13:57:13 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.48]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Wed, 12 Mar 2014 13:57:12 -0400 From: Andy Newton To: James Mitchell , "weirds@ietf.org" Thread-Topic: [weirds] Response for variant domain names Thread-Index: AQHPOHKJH2ZUMxJask6jy+hlpJADO5rdyBSA Date: Wed, 12 Mar 2014 17:57:12 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.1.30.36] Content-Type: multipart/alternative; boundary="_000_CF4617852D5EDandyarinnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/XIm8V3zjtu4PJGGpR4wYggKyES4 Subject: Re: [weirds] Response for variant domain names X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 17:57:25 -0000 --_000_CF4617852D5EDandyarinnet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Have you looked at the example on page 31? That would be more useful, in my= opinion. With your approach you=92ll need to register =93primary-domain=94= in the 5988 registry. -andy From: James Mitchell > Date: Wednesday, March 5, 2014 at 8:58 AM To: "weirds@ietf.org" > Subject: [weirds] Response for variant domain names All, I mentioned changing the response for variants at the meeting yesterday. Th= is is what I have in mind: query: /domain/blocked-variant.tld Response: { "ldhName" : "blocked-variant.tld" "status" : =93unregistered" "links" : [ { "value" : "http://example.com/domain/blocked-variant.tld", "rel" : "primary-domain=94, //??? "href" : "http://example.com/domain/primary-domain.tld", "type" : "application/rdap+json" } ] // optionally include the primary domain response here } I prefer this approach because the response is for the name present in the = query, not for another name. The response clearly relates the queried name = to the primary name via the status =96 not all registries compute or store = all variants, and listing all (blocked) variants in a response is out of th= e question (exponential explosion). Further, a redirect does not quite work= , as (active) variants have information beyond a status, for example the da= te time the variant became activated, and some may even contain separate de= legation information (some registries accept DS per variant instead of a DN= SKEY for all variant names AFAIK). Further, the variant relation values and definitions should be updated. * =93unregistered=94 is the logical opposite of =93registered=94 and th= e description should say exactly that. I disagree with the existing descrip= tion as the name is =93in" the registry, but not with full domain data. IMO= a weirds server can stop at the registered and unregistered statuses. * Unregistered names can be subdivided into two buckets describing weth= er the name is available for registration, =93blocked=94 or =93withheld=94.= IMO the distinction is relevant only in the provisioning protocol, however= some weirds servers may choose to make the distinction. Unfortunately neit= her status is currently available (withheld is effectively available by cho= osing either registration restricted or open registration - the latter brin= g the variant relation into question IMO). I=92d prefer removing =93registr= ation restricted=94 and =93open registration=94 in favour of adding both = =93blocked=94 and =93withheld=94. Further, it should be responsibility of the client to infer =93unregistered= =94 from =93blocked=94 or =93withheld=94 instead of the server returning tw= o statuses. Regards, James Mitchell ARI Registry Services --_000_CF4617852D5EDandyarinnet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2E0013FCF1604B40B2A9EA0B5D0F300D@corp.arin.net> Content-Transfer-Encoding: quoted-printable
Have you looked at the example on page 31? That would be more useful, = in my opinion. With your approach you=92ll need to register =93primary-doma= in=94 in the 5988 registry.

-andy

From: James Mitchell <james.mitchell@ausregistry.com.a= u>
Date: Wednesday, March 5, 2014 at 8= :58 AM
To: "weirds@ietf.org" <= weirds@ietf.org>
Subject: [weirds] Response for vari= ant domain names

All,

I mentioned changing the response for variants at the meeting yesterday. Th= is is what I have in mind:

query: /domain/blocked-variant.tld
Response:
{
"ldhNa= me" : "blocked-variant.tld"
"statu= s" : =93unregistered"
"links" :
[
{
"rel" : "primary-domain=94, //??= ?
"type" : "application/rdap+j= son"
}
]
// optional= ly include the primary domain response here
}

I prefer this approach because the response is for the name present in the = query, not for another name. The response clearly relates the queried name = to the primary name via the status =96 not all registries compute or store = all variants, and listing all (blocked) variants in a response is out of the question (exponential explosion). Fur= ther, a redirect does not quite work, as (active) variants have information= beyond a status, for example the date time the variant became activated, a= nd some may even contain separate delegation information (some registries accept DS per variant instead of a= DNSKEY for all variant names AFAIK).

Further, the variant relation values and definitions should be updated.
  • =93unregistered=94 is the logical opposite of =93registered=94 and the = description should say exactly that. I disagree with the existing descripti= on as the name is =93in" the registry, but not with full domain data. = IMO a weirds server can stop at the registered and unregistered statuses.
  • Unregistered names can be subdivided in= to two buckets describing wether the name is available for registration, = =93blocked=94 or =93withheld=94. IMO the distinction is relevant only in th= e provisioning protocol, however some weirds servers may choose to make the distinction. Unfortunately neither status is currently available (withheld= is effectively available by choosing either registration restricted or ope= n registration - the latter bring the variant relation into question IMO). = I=92d prefer removing =93registration restricted=94 and =93open registration=94 in favour of adding both =93bloc= ked=94 and =93withheld=94.
Further, it should be responsibility of the client to infer =93unregis= tered=94 from =93blocked=94 or =93withheld=94 instead of the server returni= ng two statuses.

Regards,
James Mitchell
ARI Registry Services


--_000_CF4617852D5EDandyarinnet_-- From nobody Thu Mar 13 10:13:15 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F411A09EC for ; Thu, 13 Mar 2014 10:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 INeUN5EO58ti for ; Thu, 13 Mar 2014 10:13:03 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6D71A08ED for ; Thu, 13 Mar 2014 10:13:03 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:d5d1:ac74:fa48:a37a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id C2E514034B for ; Thu, 13 Mar 2014 13:12:56 -0400 (EDT) Message-ID: <5321E718.9090703@viagenie.ca> Date: Thu, 13 Mar 2014 13:12:56 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "weirds@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/VMX_By26eE7oItA2TG_Jkj8QkpY Subject: [weirds] xn--* X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:13:09 -0000 All, What was the conclusion about /domains?name=xn--* again? Is it a legal query or not? The current text allows LDH and U-labels. Since A-labels are a subset of LDH, xn--* would be allowed too. Is this interpretation correct? Do we really mean LDH, or do we mean NR-LDH? (Refer to https://tools.ietf.org/html/rfc5890#page-10 for terminology graph...) Thanks, Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Thu Mar 13 11:23:59 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0561A0A51 for ; Thu, 13 Mar 2014 11:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 4MCgHmdrx7ll for ; Thu, 13 Mar 2014 11:23:56 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C49011A0A77 for ; Thu, 13 Mar 2014 11:23:55 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WOAIG-0007Qc-6C for weirds@ietf.org; Thu, 13 Mar 2014 18:23:48 +0000 Received: from mail-ig0-f171.google.com ([209.85.213.171]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WOAIG-0004RS-5w for weirds@ietf.org; Thu, 13 Mar 2014 18:23:48 +0000 Received: by mail-ig0-f171.google.com with SMTP id hl1so17987041igb.4 for ; Thu, 13 Mar 2014 11:23:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8FOZLqVo9/roOHglkU68DmeF5e/DNK0n8hq3aUjHuZA=; b=bfZcES0u0WpxL8meZh4UiFX6WKhCsCHSCP+45YzmSm2eH1KsVJRHEe8NXbbLsEO+FC tvKnzxbgjWVY902IfJpuuh49QwHd7MJteZtvMa3tGUziV9Zgq6t0apXRQRlMD6eftqDT oq9QX0T0hGXnT7JL+A7v0b2pySLFVvkrvL2ztCDjtGnpdjSxW109PtfNEZUu30SrXCvU E7OIhFuF+31jq4fZCXNTDO5vJZPJtXPREbM0Y4IwfxZNiaruWZC1MB5+QiPM1pq/2HGQ tVeZfcPCxjMDV+xUli8D0RWaF6IY1wbAD457xEOhMVyltcNTjyEx56SXZQa276qyTE9X WC7w== X-Gm-Message-State: ALoCoQl7iJcT2HlaYHcB9xL2hnH5wFvmR5dIGFVC7dduPAkobo/x3Sw4Cz5C6ld9gPiTENNnEBk5IdmkxV3OpQFN42sxlTMOfb8XNLuqo+bFBIBsVmuqL+cYj4nPEqjQIrbrt07cyELZ X-Received: by 10.43.146.69 with SMTP id jx5mr2843028icc.42.1394735023403; Thu, 13 Mar 2014 11:23:43 -0700 (PDT) X-Received: by 10.43.146.69 with SMTP id jx5mr2843022icc.42.1394735023316; Thu, 13 Mar 2014 11:23:43 -0700 (PDT) Received: from [192.168.2.12] (bas5-toronto47-1176440350.dsl.bell.ca. [70.31.14.30]) by mx.google.com with ESMTPSA id pn6sm10798541igb.4.2014.03.13.11.23.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 11:23:42 -0700 (PDT) Message-ID: <5321F7A5.1010309@afilias.info> Date: Thu, 13 Mar 2014 14:23:33 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Simon Perreault , "weirds@ietf.org" References: <5321E718.9090703@viagenie.ca> In-Reply-To: <5321E718.9090703@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/vJeU1Nbcv9J6pbbjuWZefOrCYqA Subject: Re: [weirds] xn--* X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:23:58 -0000 There was a prohibition against search of labels beginning with xn-- in earlier drafts but was removed in draft-ietf-weirds-rdap-query-07. Here is one thread about it http://www.ietf.org/mail-archive/web/weirds/current/msg03050.html -Ernie On 2014-03-13 1:12 PM, Simon Perreault wrote: > All, > > What was the conclusion about /domains?name=xn--* again? Is it a legal > query or not? > > The current text allows LDH and U-labels. Since A-labels are a subset of > LDH, xn--* would be allowed too. Is this interpretation correct? > > Do we really mean LDH, or do we mean NR-LDH? (Refer to > https://tools.ietf.org/html/rfc5890#page-10 for terminology graph...) > > Thanks, > Simon From nobody Thu Mar 13 11:57:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2C51A03E2 for ; Thu, 13 Mar 2014 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 8PMwRFQmz1eI for ; Thu, 13 Mar 2014 11:57:27 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 8154A1A02E6 for ; Thu, 13 Mar 2014 11:57:25 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WOAog-0001wS-6I for weirds@ietf.org; Thu, 13 Mar 2014 18:57:18 +0000 Received: from mail-ig0-f174.google.com ([209.85.213.174]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WOAog-0006BS-62 for weirds@ietf.org; Thu, 13 Mar 2014 18:57:18 +0000 Received: by mail-ig0-f174.google.com with SMTP id h18so18108380igc.1 for ; Thu, 13 Mar 2014 11:57:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=D1MO8svfn2FJwJDLMla7hhIPRYype2KHt47SN1kH9bA=; b=Goz3bE9s52yGZIo6iCXeiwCCr9X/pn5cCIrRh05WsUF5TkV0xQNbmsGvPstY5Pyp1O Z+zHBVdzXDlS7mLPi5zAUuDIr1sn5McFPC/T1Dhbn5F6be2JQuNIv3W531iuOElB2P/8 zlD96+jCOHKRs5viHw7+UBMqcNb2cF+Zk4WhSDyDck0/X8MIx61hI7xpzXcfHgXRLe8a HuMM69HVqPthmYD/imFaq0xlccvp8KKHcDPnMU1oOMuB0wHDB3DKRSXCD7T5loYqrt0P xfA7pfQRo1Sqd4pfRXutvuFM6Y1G4bM+dVMilHT9+zoTyhE4V2v8ubtQA9i1Z+ydEatu hkXA== X-Gm-Message-State: ALoCoQl0lWaxRgZy2h6hIS+DfU9hFeUrMR8jHSlDUddFjACU8nEmkZfoLCBqwAFXv2yoH+wNX3+cHesXpIHjw/Tp0/izlve0EthtozYBsSbbGtFktLTpdCK8bhBk63lwLJaeWKMOdIai X-Received: by 10.50.138.104 with SMTP id qp8mr3448390igb.39.1394737033369; Thu, 13 Mar 2014 11:57:13 -0700 (PDT) X-Received: by 10.50.138.104 with SMTP id qp8mr3448374igb.39.1394737033166; Thu, 13 Mar 2014 11:57:13 -0700 (PDT) Received: from [192.168.2.12] (bas5-toronto47-1176440350.dsl.bell.ca. [70.31.14.30]) by mx.google.com with ESMTPSA id rj10sm71001482igc.8.2014.03.13.11.57.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Mar 2014 11:57:11 -0700 (PDT) Message-ID: <5321FF83.8010801@afilias.info> Date: Thu, 13 Mar 2014 14:57:07 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: WEIRDS Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/x82oGDS8ER2YbUrPweHu9I0LOuQ Cc: WEIRDS Interop Subject: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 18:57:29 -0000 According to http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-10#section-4, the valid search patterns are only xxx* or xxx*.tld the search pattern "exam*" will match "example.com" and "example.net". The search pattern "exam*.com" will match "example.com". Additional pattern matching processing is beyond the scope of this specification. The Inter-Op test has a number of search test cases of the form xxx.* which it expects to succeed. For example, ts_query_3_2_1_3 GET http:// ... /.well-known/rdap/domains?name=cafe.* I think it makes sense for wild card search to also include exact name lookup. This is the pattern xxx (or xxx.tld). This search form would address an earlier discussion of how to find out whether a name exists or not without requiring a large response from the server. I think the spec should be changed to include these two search patterns: xxx.* xxx (includes xxx.tld) -Ernie From nobody Fri Mar 14 03:47:43 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2B21A0115 for ; Fri, 14 Mar 2014 03:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no 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 dPVmSZsqxHSP for ; Fri, 14 Mar 2014 03:47:41 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 2351E1A010E for ; Fri, 14 Mar 2014 03:47:41 -0700 (PDT) Received: from [IPv6:2001:1488:ac14:1400:1aa9:5ff:fef6:7aa9] (unknown [IPv6:2001:1488:ac14:1400:1aa9:5ff:fef6:7aa9]) by mail.nic.cz (Postfix) with ESMTPSA id A268F13FCE3 for ; Fri, 14 Mar 2014 11:47:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394794053; bh=9ohXPjLxr+bTuuwQOI00o4G2sWcebQwzjLDwpgpoHEo=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=tLAOnuhMph0tsJAZ7DDEiEEiJ2HLdr0S/qRacMZuAjNAPcmT5sbo2MctCeqq5Eq09 l4KLomxqnFigxrtxVKR+MX3GQoaseD5aB+gpj+z9gVSiQiVV6aRXuzLyxjV+A9t9/2 kp7q2wxRJJwLU0iEm4RNIqZ+xkMiTv21cueUQEUY= Message-ID: <5322DE43.4040409@nic.cz> Date: Fri, 14 Mar 2014 11:47:31 +0100 From: "jan.korous@nic.cz" Organization: nic.cz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10 MIME-Version: 1.0 To: weirds@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4icM09fCRV91mZsFhLeKd8ih0bs Subject: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 10:47:42 -0000 Section 2.3 of Redirection draft mentions authoritative source for entities and name servers. Bootstrap draft doesn't include these objects and in case of entities it explicitly states that: "Since there is no global namespace for entities, this document does not describe how to find the authoritative RDAP server for entities." Since name servers can be used cross-zone there's no hierarchy and maintaining information about authoritative sources could be non-trivial. What is the current thinking about this topic? Best regards Jan Korous -- Jan Korous CZ.NIC Americka 23 120 00 Prague Czech Republic From nobody Fri Mar 14 08:21:34 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF04F1A0163 for ; Fri, 14 Mar 2014 08:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 64PjKKotRiRc for ; Fri, 14 Mar 2014 08:21:31 -0700 (PDT) Received: from exprod6og119.obsmtp.com (exprod6og119.obsmtp.com [64.18.1.234]) by ietfa.amsl.com (Postfix) with ESMTP id C10C51A0164 for ; Fri, 14 Mar 2014 08:21:29 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob119.postini.com ([64.18.5.12]) with SMTP ID DSNKUyMecmOUhTLw/wT4NTks8596d1rmkyVi@postini.com; Fri, 14 Mar 2014 08:21:24 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2EFLMoK004402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Mar 2014 11:21:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Mar 2014 11:21:21 -0400 From: "Hollenbeck, Scott" To: Simon Perreault , "weirds@ietf.org" Thread-Topic: [weirds] xn--* Thread-Index: AQHPPt+Dkzjot3+iDUCmSOr0xNFJl5rgtDjQ Date: Fri, 14 Mar 2014 15:21:21 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49373CD4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <5321E718.9090703@viagenie.ca> In-Reply-To: <5321E718.9090703@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.173.152.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/k5kQ3w0-F30f0gbq-4YLY9sEvnc Subject: Re: [weirds] xn--* X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:21:33 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Simon > Perreault > Sent: Thursday, March 13, 2014 1:13 PM > To: weirds@ietf.org > Subject: [weirds] xn--* >=20 > All, >=20 > What was the conclusion about /domains?name=3Dxn--* again? Is it a legal > query or not? >=20 > The current text allows LDH and U-labels. Since A-labels are a subset > of > LDH, xn--* would be allowed too. Is this interpretation correct? >=20 > Do we really mean LDH, or do we mean NR-LDH? (Refer to > https://tools.ietf.org/html/rfc5890#page-10 for terminology graph...) My intention was LDH. Scott From nobody Fri Mar 14 08:31:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA04F1A0166 for ; Fri, 14 Mar 2014 08:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 MiTzeU_VK4Cq for ; Fri, 14 Mar 2014 08:31:33 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1381A015B for ; Fri, 14 Mar 2014 08:31:33 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:10d5:d586:2398:9812]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 835D2403CA; Fri, 14 Mar 2014 11:31:26 -0400 (EDT) Message-ID: <532320CE.9010901@viagenie.ca> Date: Fri, 14 Mar 2014 11:31:26 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Hollenbeck, Scott" , "weirds@ietf.org" References: <5321E718.9090703@viagenie.ca> <831693C2CDA2E849A7D7A712B24E257F49373CD4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49373CD4@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/4uKxRuLFxoM_QXSSWG1nirMrWPo Subject: Re: [weirds] xn--* X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:31:35 -0000 Le 2014-03-14 11:21, Hollenbeck, Scott a crit : >> What was the conclusion about /domains?name=xn--* again? Is it a legal >> query or not? >> >> The current text allows LDH and U-labels. Since A-labels are a subset >> of >> LDH, xn--* would be allowed too. Is this interpretation correct? >> >> Do we really mean LDH, or do we mean NR-LDH? (Refer to >> https://tools.ietf.org/html/rfc5890#page-10 for terminology graph...) > > My intention was LDH. Thanks to the both of you! Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Fri Mar 14 08:43:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029551A0168 for ; Fri, 14 Mar 2014 08:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 2cpriC53Syar for ; Fri, 14 Mar 2014 08:43:25 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id D78861A0161 for ; Fri, 14 Mar 2014 08:43:24 -0700 (PDT) Received: (qmail 43128 invoked from network); 14 Mar 2014 15:43:17 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 14 Mar 2014 15:43:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53232395.xn--btvx9d.k1403; i=johnl@user.iecc.com; bh=5Az3vjDYH/4Qb1EWfgpaT3as21aTwGv3W0xgzCXHUqE=; b=lDFgMuTuSl8V1a9s5VwUIMVlLW1oBLLt6i6zlOJ9uee2K6OPsMsGp6LkCOEsFxTc4YFFeLBlJM1avHQ6fJnBqnujpKl6BCq853U4RroIHHkkFcQsf5ZSSRVY88/xlYjaFANaEMKh6qJwDRcYSVLvZNLtzFK/Ceg6MrCWTE67cLbeFRv1QDDncWsWKM3n/3D9rFwbhA47RPdK3E6JhVnTQ4MMgSZjkzUI1ZH2Q9bVRQArqAZeT/yMCXXh+p0rmLsb DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53232395.xn--btvx9d.k1403; bh=5Az3vjDYH/4Qb1EWfgpaT3as21aTwGv3W0xgzCXHUqE=; b=JEhE9ssVZOKEkd2C/Uk7VoCQGrSipiRWDs++qeYgxmt1i8CdyxqVpQdgyqTfOZuJiwWnw81Z1+hXEJZpYp4O5ndRqFMmcjevOLHP4KXs6ZjQmJW0bbu06nXYIM5tG4ohiRFQy/9kCN64ezo3EHEBP2tS557/5EnJzY3//kScSbNOEmIVYiG/xaBIJVrzUXiJ0mBNSB/bqUccpQg+USiUPlwysw3/FewtY3cB1vqJBa5ILW06LwVSlebwyJEI35zQ Date: 14 Mar 2014 15:42:55 -0000 Message-ID: <20140314154255.86918.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <5322DE43.4040409@nic.cz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/C1xqBducEULESkheTbLBkpGAl30 Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 15:43:26 -0000 >What is the current thinking about this topic? I brought this up a few times. If a query goes through http redirects before being answers, it can be hard for a client to tell what server provided the final response. So I agree that if the response includes entity references, it needs to tell where to look them up, either by returning the entities as URLs, or by a field with the URL prefix (I hope not a template) for the server. R's, John From nobody Fri Mar 14 09:42:48 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABE91A0194 for ; Fri, 14 Mar 2014 09:42:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 Sq_-hm65NSjZ for ; Fri, 14 Mar 2014 09:42:45 -0700 (PDT) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDDE1A018B for ; Fri, 14 Mar 2014 09:42:45 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id m20so3185428qcx.35 for ; Fri, 14 Mar 2014 09:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Ym9rfSfe9nQ8uPak77lRdAoAv9mZyBnpZ1fMTM5/VWw=; b=qn/nzDqugAvdfc0oFe/X9C1tm80jfzntyHPf53+sNMqyouoZOm1X8Q99BSz9x/Rr4q zjlpr7EE6OWVK6SYpCsENnOM8XXHfHcVPtnsHrWL27whUL4ZH+lULZzD122+yu27vV8F HJm3dXHus1UGNnzK29Vo4DMhPbDgAmnK15jPVYF2bvvN0qepmHVJvRkHLKyCNzNab9Qa W7H97HphxhW9eyjufHH0v8wwDsOedFk9xEcxvwgNzZgZEZ5qM+7PL3iZfrICzKRiPSmt opA/uitFwAB7N54pjx6uak8n8LWDmB/bRpE9qg7O4Bg/dB+yblBHVOXZAhlmMtPProme xxLw== X-Received: by 10.140.25.104 with SMTP id 95mr5224614qgs.39.1394815358083; Fri, 14 Mar 2014 09:42:38 -0700 (PDT) Received: from 87-7-200.lacnic.net.uy ([2001:13c7:7001:7000:8d0f:d439:aeb8:1050]) by mx.google.com with ESMTPSA id i14sm17531147qaj.11.2014.03.14.09.42.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Mar 2014 09:42:36 -0700 (PDT) Message-ID: <53233179.3070805@gmail.com> Date: Fri, 14 Mar 2014 13:42:33 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "jan.korous@nic.cz" , weirds@ietf.org References: <5322DE43.4040409@nic.cz> In-Reply-To: <5322DE43.4040409@nic.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/2n4_APsdWAoGB0smI6IZRjUn3q4 Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:42:46 -0000 I'm revising the redirects draft according to some recently received suggestions. I'd be happy to add text in this regard, but I'm not very familiar with the names side of things. Open question: - do we just need more text and clarifications or do we need some additional protocol stuff, like new attributes in json responses ? cheers! ~Carlos On 3/14/14, 7:47 AM, jan.korous@nic.cz wrote: > Section 2.3 of Redirection draft mentions authoritative source for > entities and name servers. > > Bootstrap draft doesn't include these objects and in case of entities it > explicitly states that: > "Since there is no global namespace for entities, this document does not > describe how to find the authoritative RDAP server for entities." > > Since name servers can be used cross-zone there's no hierarchy and > maintaining information about authoritative sources could be non-trivial. > > What is the current thinking about this topic? > > Best regards > > Jan Korous > From nobody Mon Mar 17 03:34:26 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1761A03D6 for ; Mon, 17 Mar 2014 03:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 XhgURKbFhJn1 for ; Mon, 17 Mar 2014 03:34:16 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 28F911A03C7 for ; Mon, 17 Mar 2014 03:34:16 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id p10so5421314pdj.3 for ; Mon, 17 Mar 2014 03:34:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0+5UjSX8w/LsMMRXRMLeBNETa+ZWlXT6764L+u5BJjU=; b=g6XPRMpyR6/DdIAza6e6/pJx1Iq1N2YcUroLnQSb6cQ4I4hLlfQovoRE971DnCpXvj wS2KMScuegzVx8Q2f+6xcgJJy/IIaKYvy7fzfrANfREftzyWxOTC9By6AXo3VL3RqnhE eOT2jnbM0nKGhoRAOqIfmu2s6wbYCg1clTlfDH4XtqAeCUZDhbCMGEd8qIZhsRz1Ppl1 48uKsgFhyJjEULf0CAcL2UsDm/z9rpMQ9QxOFG75OdA0082ARKlsoCQ9sYyjmtSlacRH FPadyr6wajP/Px6ZfSj18evpe0geRPN6rObdt7RkaZyjaEVOTOXxdjXrw0TgzRSWR7n/ xd6w== X-Gm-Message-State: ALoCoQkgl4QW+9EsnT0J2dsEpaoz7l0oC6sm2A3Hj7g4gEHh8oCyLxlGEmMGMxTEcujSZt18XfFM MIME-Version: 1.0 X-Received: by 10.68.200.74 with SMTP id jq10mr2322578pbc.169.1395052448339; Mon, 17 Mar 2014 03:34:08 -0700 (PDT) Received: by 10.68.143.4 with HTTP; Mon, 17 Mar 2014 03:34:08 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: <20140314154255.86918.qmail@joyce.lan> References: <5322DE43.4040409@nic.cz> <20140314154255.86918.qmail@joyce.lan> Date: Mon, 17 Mar 2014 06:34:08 -0400 Message-ID: From: Andrew Newton To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/Qhz19chFHpUgRaB9ck_G3N350vw Cc: "weirds@ietf.org" Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 10:34:18 -0000 See paragraphs 1 & 2 of Section 6 in json-response. -andy On Fri, Mar 14, 2014 at 11:42 AM, John Levine wrote: >>What is the current thinking about this topic? > > I brought this up a few times. If a query goes through http redirects > before being answers, it can be hard for a client to tell what server > provided the final response. So I agree that if the response includes > entity references, it needs to tell where to look them up, either by > returning the entities as URLs, or by a field with the URL prefix (I > hope not a template) for the server. > > R's, > John > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Mon Mar 17 09:17:12 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7251A0446 for ; Mon, 17 Mar 2014 09:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 83-U9LSmYSW8 for ; Mon, 17 Mar 2014 09:17:10 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id C17541A0431 for ; Mon, 17 Mar 2014 09:17:09 -0700 (PDT) Received: (qmail 82164 invoked from network); 17 Mar 2014 16:17:01 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 17 Mar 2014 16:17:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53271ffd.xn--hew.k1403; i=johnl@user.iecc.com; bh=PsES8LQK0gv1TwHKiGZvjgzL4tfTtfhGdHeCus9AWBE=; b=eR3UJ7wgED0XfV5vWxBSu5d6J07NgWzx/VNEcE8vl1/R0mdYQrRSHTjKJX5phKf0rVWzghkkdHD0B8nlh/bAGPquE26uQCfJIEO77/SYmUAiZ1DndR0NwpnoSgeTFhe1jSMrpPgx0pfyiP4aZU3nBXyZk9QNMhGsnT9d3gXQgEwTiITnYARjMrOGEnBccVyVY3HW7ov4Do4SHZJene4rwo68KcQqHLixTbCAD3vc9hnsz1Ospc/97vT19l+jM2TE DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=53271ffd.xn--hew.k1403; bh=PsES8LQK0gv1TwHKiGZvjgzL4tfTtfhGdHeCus9AWBE=; b=vk1QXi73eyHMUZ1zWNF9Hk3aZhFE4JG+QHSyxQL/UbS/lZmLaoJXBLokqxhgyZSGp53uowtgYllsoge+lKjbCFH1JI83QLwaTqWzeOede4X/mQDfZQ4b+1Tb+WumdBrUW+BbdW2oeBf8fYHvXj+YViE1fVfwJUHQ+1/8uFQtDcVj/hdCIIb0JYQStxmuprDVvGE6l1DXIAw1Rr8Wv5bXT2MtiSuohhB7qCIvaDJ6+F3MOI3UytzQp30culLRfy3j Date: 17 Mar 2014 16:16:39 -0000 Message-ID: <20140317161639.1416.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rpLrI8rtAHWsezKCHnP8CGdGn4g Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:17:11 -0000 In article you write: >See paragraphs 1 & 2 of Section 6 in json-response. I should read the drafts more often, shouldn't I? It looks OK except where it says Clients MUST be able to process object instances without a "self" link. I think we've agreed that entity handles are specific to servers, so without the link you can't tell where to look it up other than by guessing, which is slow and unreliable. R's, John >> I brought this up a few times. If a query goes through http redirects >> before being answers, it can be hard for a client to tell what server >> provided the final response. So I agree that if the response includes >> entity references, it needs to tell where to look them up, either by >> returning the entities as URLs, or by a field with the URL prefix (I >> hope not a template) for the server. From nobody Mon Mar 17 11:13:37 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E521A048C for ; Mon, 17 Mar 2014 11:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Kx0ofJ17Bosy for ; Mon, 17 Mar 2014 11:13:34 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2326D1A046F for ; Mon, 17 Mar 2014 11:13:34 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r10so5869552pdi.21 for ; Mon, 17 Mar 2014 11:13:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tWT69IREMcPjy0CU7bvU5vXvT9zEaWilkU7eWZEEifE=; b=mykxPx9u7Lp2/2/zeBSiTSkzqUJxSm33tSeWyI0pdsfawA1JtLCscsevTcvQUwxrAO EV36Z6boquve6rbHE4PWthgN/SN1EfQm2GMOm0X8toF/HbGIOCWlM8Cu7neMMn/64/OC S+vzVLEAfFNnWIGmAiGfoFRDwy7kRPEblLD3+NghkKoHdXTqOwJHGE+3sBXJl1JfVPod vUtyv897tPOgSt0UCNQbYJBIq6xEx+52/V4CmvrQkDqpO5377raynMFtPfVM3w0BhRvt bedh6ifGJlUekCUWSNtlIeBP0PfLtKgQ8BgwWk8NNpQUDwTKznfAsy0P70vK5pjGEmWD iFMA== X-Gm-Message-State: ALoCoQm8NF4m7qqDlsVy/fpOuhSCcQAY5g79qyaFel12widanOp37v4jC4Op3CBmxnStF8qFwga9 MIME-Version: 1.0 X-Received: by 10.68.34.197 with SMTP id b5mr27542093pbj.16.1395080006181; Mon, 17 Mar 2014 11:13:26 -0700 (PDT) Received: by 10.68.143.4 with HTTP; Mon, 17 Mar 2014 11:13:26 -0700 (PDT) X-Originating-IP: [71.191.38.92] In-Reply-To: <20140317161639.1416.qmail@joyce.lan> References: <20140317161639.1416.qmail@joyce.lan> Date: Mon, 17 Mar 2014 14:13:26 -0400 Message-ID: From: Andrew Newton To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/z6Mix7m075NYgDki7L0UBaMwdLk Cc: "weirds@ietf.org" Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 18:13:35 -0000 Servers SHOULD provide it. However, if they don't clients MUST be able to deal with the absence of that link. -andy On Mon, Mar 17, 2014 at 12:16 PM, John Levine wrote: > In article you write: >>See paragraphs 1 & 2 of Section 6 in json-response. > > I should read the drafts more often, shouldn't I? > > It looks OK except where it says > > Clients MUST be able to process object instances without a "self" > link. > > I think we've agreed that entity handles are specific to servers, so > without the link you can't tell where to look it up other than by > guessing, which is slow and unreliable. > > R's, > John > > > > >>> I brought this up a few times. If a query goes through http redirects >>> before being answers, it can be hard for a client to tell what server >>> provided the final response. So I agree that if the response includes >>> entity references, it needs to tell where to look them up, either by >>> returning the entities as URLs, or by a field with the URL prefix (I >>> hope not a template) for the server. > From nobody Mon Mar 17 12:04:41 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711941A0307 for ; Mon, 17 Mar 2014 12:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 zh1uKFvYFTHg for ; Mon, 17 Mar 2014 12:04:37 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id DB89D1A0457 for ; Mon, 17 Mar 2014 12:04:36 -0700 (PDT) Received: (qmail 9540 invoked from network); 17 Mar 2014 19:04:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=2543.5327473c.k1403; i=johnl-iecc.com@submit.iecc.com; bh=bZtBsNAtENNCe4zxILdZbkR3M8Ox2tw7UK0zGhdPmNE=; b=sDSVqN/5LBTe6rOr4HASjGzBQx4Dc4kGp1Nzf97NPWBpeF4pcuEGr19Algb8W0j4Gl8HjiGICC5GolJ7Iy29nR0Zlt4jQWx1Ze5UcLLuyJrYf4QOqyi80L3of1fl+y9OiXnfHYvwMSosZEtjHXdj63tKf1uk73bpE+IrxTVdzdfYZidAS3UbUYglgVaiTWA12InWx+ndJeQ6O7guI+6Xlhs7r/8yZ3K4NRglNJwi7jzjiilkDQxmEy7/6YJi+tGu DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=2543.5327473c.k1403; olt=johnl-iecc.com@submit.iecc.com; bh=bZtBsNAtENNCe4zxILdZbkR3M8Ox2tw7UK0zGhdPmNE=; b=s99hnwN9PJ3USuQPBkKRNtSExiALs8TwtPr+7ICurIxL1ZWuKjXTSVTQRP3CZy7Ig06PPzChgYj+y3s0aE/bb/u00Qfd6JebuvwiQmSdGbChcPz4OKmnKspi9vq+JtKGeSzAWdYr+OM1B7FB9EU6SIdCvzd3MwxKvunBh9f8y3qcPZtz7P6JmFroxdzHIxsFl6ScVNwmqjEZko/D48D9GFPshq95gnRJT9uh21PAfph7v5M4oclcfxJ/IHA7G2Zq Received: from [2604:6000:1407:e00c:226:2dff:fef7:2823] ([IPv6:2604:6000:1407:e00c:226:2dff:fef7:2823]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP6; 17 Mar 2014 19:04:28 -0000 Date: 17 Mar 2014 15:04:17 -0400 Message-ID: From: "John R Levine" To: "Andrew Newton" In-Reply-To: References: <20140317161639.1416.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/lxcRwhslersmKQ7ac0q2ikv-VYg Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Authoritative server for entities X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 19:04:38 -0000 > Servers SHOULD provide it. However, if they don't clients MUST be able > to deal with the absence of that link. So long as dealing with it includes the option of giving up, that seems OK. R's, John > On Mon, Mar 17, 2014 at 12:16 PM, John Levine wrote: >> In article you write: >>> See paragraphs 1 & 2 of Section 6 in json-response. >> >> I should read the drafts more often, shouldn't I? >> >> It looks OK except where it says >> >> Clients MUST be able to process object instances without a "self" >> link. >> >> I think we've agreed that entity handles are specific to servers, so >> without the link you can't tell where to look it up other than by >> guessing, which is slow and unreliable. From nobody Tue Mar 18 07:24:46 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEB81A040C for ; Tue, 18 Mar 2014 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 WYx79UOu9J8N for ; Tue, 18 Mar 2014 07:24:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id E88DF1A037C for ; Tue, 18 Mar 2014 07:24:39 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WPuwR-0000Bc-4Y for weirds@ietf.org; Tue, 18 Mar 2014 14:24:31 +0000 Received: from mail-ig0-f181.google.com ([209.85.213.181]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WPuwR-0008W6-4J for weirds@ietf.org; Tue, 18 Mar 2014 14:24:31 +0000 Received: by mail-ig0-f181.google.com with SMTP id h18so8696777igc.2 for ; Tue, 18 Mar 2014 07:24:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=VusfdAAI+s1YsHQMOtETS2BSKqyQcziIiiM815CtLz0=; b=ZwmlcRhqWp4YtORV7W//MG2DHSwY+Tw6GcbMdHjh9z0NRYJaMV1FmtpAhTrzoErfJ8 lk4JF0gKqHHcInDL/ArXo62Tv2HYySGyavRT+b5ZvnYvpLcnVN8LktY3AhIpCFmLP+PK Wi3biQSGDnQe/+8nPkGILsRsRG1DrQybVOVlZKnMR0xA9lxASs71gu3+0bkbAXXdxET8 wIyDHwPJCMeDv73DGQ3ENehb+svjIyx+0mSMHj6ftLL4i4uFmAs3DqAokUgVr2XGlcns vx/V9ogU70SUX3OwAAMKn7mMYjjlQ6VL8K2JknxGjsDdwE6EPVm3MHDdLLDDfu3pyyqs FEQA== X-Received: by 10.50.43.170 with SMTP id x10mr19166328igl.20.1395152663912; Tue, 18 Mar 2014 07:24:23 -0700 (PDT) X-Gm-Message-State: ALoCoQmoLcu/u5JJgmvHxjVhjupMxQMPWlkNe0J6ahAt6Y7AccNEBOzYxF2viuOFgVTFqu6alBbqSl+BGvtTSyi3f63fBTBFCGaQd6GzS85QObpWjaOUhqL9MoSDfVr6r7JCQeZpVJ4Q X-Received: by 10.50.43.170 with SMTP id x10mr19166157igl.20.1395152662399; Tue, 18 Mar 2014 07:24:22 -0700 (PDT) Received: from [192.168.2.12] ([69.157.45.203]) by mx.google.com with ESMTPSA id jc1sm23349445igb.12.2014.03.18.07.24.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 07:24:21 -0700 (PDT) Message-ID: <5328570E.5050908@afilias.info> Date: Tue, 18 Mar 2014 10:24:14 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: WEIRDS , WEIRDS Interop Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/PC1HcYDXJR06SFLhRMZ92oy0ses Subject: [weirds] Http return code 400 vs 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:24:45 -0000 The spec that covers this behaviour is http://tools.ietf.org/html/draft-ietf-weirds-using-http-08#section-5.4 5.4. Malformed Queries If a server receives a query which it cannot interpret as an RDAP query, it returns a 400 response code. There are a number of Inter-Op test cases that flag a return of 400 instead of 404 as an error and vice versa. There are a whole set of missing Inter-Op test cases when a url path is incorrect, for example, instead of /domains?name=abc* /domains?nam=abc* /domain?name=abc* /domai?name=abc* and instead of domain/abc.info /domai/abc.info Here it seems the return codes should all be 400. This most likely points to an error in the client code. In the Inter-Op test cases, the error is always a result of the user input, such as the domain name or nameserver name. For all these cases, it would be most helpful to return 404 to distinguish user input user error from implementation error. So the following test cases (and variations) should return 404, not 400 ts_query_3_1_3_5U /domain/σειράτάξησυπουργείωνΣύνθεσηυπουργικούσυμβουλίουουουο.info ts_query_3_1_3_7 /domain/xn--cafés.com Perhaps the spec could be clarified to make this distinction more clear. As currently stated whether to return a 400 or a 404 is somewhat arbitrary. -Ernie From nobody Tue Mar 18 07:50:01 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706831A046B for ; Tue, 18 Mar 2014 07:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 8NboyIrBIfKC for ; Tue, 18 Mar 2014 07:49:57 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8934F1A037C for ; Tue, 18 Mar 2014 07:49:57 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 30F1D40D17 for ; Tue, 18 Mar 2014 10:49:49 -0400 (EDT) Message-ID: <53285D0C.4090706@viagenie.ca> Date: Tue, 18 Mar 2014 10:49:48 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: weirds@ietf.org References: <5328570E.5050908@afilias.info> In-Reply-To: <5328570E.5050908@afilias.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/GbA8coyNRTW1Npu-8ssxDLyYRmA Subject: Re: [weirds] Http return code 400 vs 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 14:49:59 -0000 Le 2014-03-18 10:24, Ernie Dainow a écrit : > The spec that covers this behaviour is > http://tools.ietf.org/html/draft-ietf-weirds-using-http-08#section-5.4 > 5.4. Malformed Queries > If a server receives a query which it cannot interpret as an RDAP > query, it returns a 400 response code. > > There are a number of Inter-Op test cases that flag a return of 400 > instead of 404 as an error and vice versa. > > There are a whole set of missing Inter-Op test cases when a url path is > incorrect, for example, instead of /domains?name=abc* > /domains?nam=abc* > /domain?name=abc* > /domai?name=abc* > and instead of domain/abc.info > /domai/abc.info > > Here it seems the return codes should all be 400. This most likely > points to an error in the client code. Agreed. We have one similar test named "ts_query_3". It could be expanded with the set you suggest. > In the Inter-Op test cases, the error is always a result of the user > input, such as the domain name or nameserver name. For all these cases, > it would be most helpful to return 404 to distinguish user input user > error from implementation error. > > So the following test cases (and variations) should return 404, not 400 > ts_query_3_1_3_5U > /domain/σειράτάξησυπουργείωνΣύνθεσηυπουργικούσυμβουλίουουουο.info > ts_query_3_1_3_7 /domain/xn--cafés.com To be clear: these are two examples of invalid IDN. The first one contains a disallowed character (capital sigma, Σ), while the second one start with "xn--" but contains a non-LDH character. This makes the desired return code 400 rather than 404. 404 would only be returned to a query for a *valid* IDN. User input has nothing to do with it: with a conforming client implementation, it would be impossible for the user to generate such invalid IDN queries. The client implementation would have to implement the IDNA algorithm, which would process user input such that the client never sends invalid IDNs to the server. Therefore, only a buggy client (or our very devious test suite) would send invalid IDN queries. 400 is thus the appropriate status code for the two queries above. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 08:56:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEF01A06E8 for ; Tue, 18 Mar 2014 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 rh8kGyLtJVpI for ; Tue, 18 Mar 2014 08:56:32 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 535EB1A06EC for ; Tue, 18 Mar 2014 08:56:20 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id E26B440DB0; Tue, 18 Mar 2014 11:56:11 -0400 (EDT) Message-ID: <53286C9B.2080502@viagenie.ca> Date: Tue, 18 Mar 2014 11:56:11 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ernie Dainow , weirds@ietf.org References: <5328570E.5050908@afilias.info> <53285D0C.4090706@viagenie.ca> <5328657F.8050900@afilias.info> In-Reply-To: <5328657F.8050900@afilias.info> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/sn1O-MgXEcGWpBp6PZac3nNMChY Subject: Re: [weirds] Http return code 400 vs 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 15:56:34 -0000 Le 2014-03-18 11:25, Ernie Dainow a écrit : > RDAP will be used as a backend for a lot of web application. So the user > will be entering the domain name to lookup, and could enter > > σειράτάξησυπουργείωνΣύνθεσηυπουργικούσυμβουλίουουουο.info > > just as easily as you did in your test script. So the error originates > with user input. The current text allows A-labels and U-labels to be sent to the server. That means that only IDNA-valid strings are allowed (see RFC 5890 section 2.3.2.1). The above example is not IDNA-valid, which means it is not a U-label. If we want to impose no IDNA requirements on the client, then it is not sufficient to allow U-label queries: we need to allow raw Unicode. The server would then run the IDNA algorithm on the raw Unicode, generating an IDNA-valid string, and running the query on that. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 12:05:22 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02B1A063E for ; Tue, 18 Mar 2014 12:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 cJxhvV0toKF8 for ; Tue, 18 Mar 2014 12:05:12 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 94B001A075E for ; Tue, 18 Mar 2014 12:05:11 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WPzJv-0007mw-45 for weirds@ietf.org; Tue, 18 Mar 2014 19:05:03 +0000 Received: from mail-ob0-f169.google.com ([209.85.214.169]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WPzJv-000572-3b for weirds@ietf.org; Tue, 18 Mar 2014 19:05:03 +0000 Received: by mail-ob0-f169.google.com with SMTP id va2so7393430obc.0 for ; Tue, 18 Mar 2014 12:04:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=GrKXjWrCp0otQGkRx+7bnIlIGa8DfYrySDABqtcokUY=; b=LurQGv4PQXSTZ+TMAeQ2jQUckNzeGYfd8pUxct3pMaDtX5+2XbCpKaR74eELkLijIU 1X5Aj7tuduNxn4xGh6gnKqQf0AEivIRszEJEbitQvv5Lhem/xcnc/gibf2J35R6WO8LY F5ZhDO9D8oVpoBlblWgBZdRaeLuiMLOH24qpyyOmMQ9ggdcYwdmE4v4yj2Atcg2OJfqO oR7AqcF9UctBoSFMraTcsHKT6jtqWZ0ie25jPGhpfluQ+Kwgxw8BWlOCdCFkLUYM6Vkc 1weRs7Q2s9LcgkPpGRJ0YdFrvjmgyD7ERBA54CRQlVIpbEuIysrU6hujidDf2GcOGyvE /AgA== X-Gm-Message-State: ALoCoQm83Gr6Z4q7geB/8eNV0oIZODzr9g5dU8MEJPULX1vKRUwt1DBX68NO1Zy+W/FUgTzHyxDI7ol0Ntw9H2/yzIpsYrpnmVup6O5mGAVZlUjwrWnZcTFtg3kXIzlA3a4Ms8u8EhxQ X-Received: by 10.60.51.230 with SMTP id n6mr28333382oeo.35.1395169497520; Tue, 18 Mar 2014 12:04:57 -0700 (PDT) X-Received: by 10.60.51.230 with SMTP id n6mr28333365oeo.35.1395169497408; Tue, 18 Mar 2014 12:04:57 -0700 (PDT) Received: from [192.168.2.12] ([69.157.45.203]) by mx.google.com with ESMTPSA id qh4sm33781056obc.4.2014.03.18.12.04.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Mar 2014 12:04:56 -0700 (PDT) Message-ID: <532898D4.4000204@afilias.info> Date: Tue, 18 Mar 2014 15:04:52 -0400 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: WEIRDS References: <5321FF83.8010801@afilias.info> In-Reply-To: <5321FF83.8010801@afilias.info> Content-Type: multipart/alternative; boundary="------------040209000907010209090603" Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/558MSdTBFumT7NoJ2jJ-oUw3S8E Cc: WEIRDS Interop Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:05:15 -0000 This is a multi-part message in MIME format. --------------040209000907010209090603 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Actually what is the expectation of the server to process searches for xxx* or xxx.* It seems that a server needs to submit this search to every tld server. This implies it needs to cycle through all the urls in the IANA bootstrap table. From the client's point of view, this is a single request, so it expects a single response. That means the server has to aggregate all the results from each server it queries into one integrated response. If one server exceeds its search limit and returns "searchResultsTruncated" : true, there is no way to indicate what subset of the total response it applies to. These search capabilities are fairly complicated and go beyond current whois functionality. Unless they can be simplified, I think they should be deferred to a later version of RDAP. The only supported search patterns that correspond to typical whois servers is a search for xxx*.tld or xxx (exact lookup). -Ernie On Thu, Mar 13, 2014 at 2:57 PM, Ernie Dainow > wrote: According to http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-10#section-4, the valid search patterns are only xxx* or xxx*.tld the search pattern "exam*" will match "example.com " and "example.net ". The search pattern "exam*.com" will match "example.com ". Additional pattern matching processing is beyond the scope of this specification. The Inter-Op test has a number of search test cases of the form xxx.* which it expects to succeed. For example, ts_query_3_2_1_3 GET http:// ... /.well-known/rdap/domains?name=cafe.* I think it makes sense for wild card search to also include exact name lookup. This is the pattern xxx (or xxx.tld). This search form would address an earlier discussion of how to find out whether a name exists or not without requiring a large response from the server. I think the spec should be changed to include these two search patterns: xxx.* xxx (includes xxx.tld) -Ernie --------------040209000907010209090603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Actually what is the expectation of the server to process searches for xxx* or xxx.*

It seems that a server needs to submit this search to every tld server. This implies it needs to cycle through all the urls in the IANA bootstrap table. From the client's point of view, this is a single request, so it expects a single response. That means the server has to aggregate all the results from each server it queries into one integrated response. If one server exceeds its search limit and returns "searchResultsTruncated" : true, there is no way to indicate what subset of the total response it applies to.

These search capabilities are fairly complicated and go beyond current whois functionality. Unless they can be simplified, I think they should be deferred to a later version of RDAP. The only supported search patterns that correspond to typical whois servers is a search for xxx*.tld or xxx (exact lookup).

-Ernie


On Thu, Mar 13, 2014 at 2:57 PM, Ernie Dainow <edainow@afilias.info> wrote:
According to http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-10#section-4, the valid search patterns are only xxx* or xxx*.tld

    the search pattern "exam*" will match "example.com" and
   "example.net".  The search pattern "exam*.com" will match
   "example.com".  Additional pattern matching processing is beyond the
   scope of this specification.

The Inter-Op test has a number of search test cases of the form xxx.* which it expects to succeed.
 For example, ts_query_3_2_1_3
    GET http:// ... /.well-known/rdap/domains?name=cafe.*

I think it makes sense for wild card search to also include exact name lookup. This is the pattern xxx (or xxx.tld). This search form would address an earlier discussion of how to find out whether a name exists or not without requiring a large response from the server.

I think the spec should be changed to include these two search patterns:
xxx.*
xxx (includes xxx.tld)

-Ernie

--------------040209000907010209090603-- From nobody Tue Mar 18 12:13:29 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C491D1A0455 for ; Tue, 18 Mar 2014 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 vQ7_QgtC3bmU for ; Tue, 18 Mar 2014 12:13:25 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 854691A044C for ; Tue, 18 Mar 2014 12:13:25 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id EB81740377 for ; Tue, 18 Mar 2014 15:13:16 -0400 (EDT) Message-ID: <53289ACC.1090406@viagenie.ca> Date: Tue, 18 Mar 2014 15:13:16 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: weirds@ietf.org References: <5321FF83.8010801@afilias.info> <532898D4.4000204@afilias.info> In-Reply-To: <532898D4.4000204@afilias.info> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/AwZc9N7VerbIViyXfcSUyts9TuY Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 19:13:28 -0000 Le 2014-03-18 15:04, Ernie Dainow a crit : > Actually what is the expectation of the server to process searches for > xxx* or xxx.* > > It seems that a server needs to submit this search to every tld server. > This implies it needs to cycle through all the urls in the IANA > bootstrap table. From the client's point of view, this is a single > request, so it expects a single response. That means the server has to > aggregate all the results from each server it queries into one > integrated response. If one server exceeds its search limit and returns > "searchResultsTruncated" : true, there is no way to indicate what subset > of the total response it applies to. Why would the RDAP server query other servers? Why doesn't it only return what it has or hasn't in its own database? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 13:39:52 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6661A06F5 for ; Tue, 18 Mar 2014 13:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 NgjfakCb0BtS for ; Tue, 18 Mar 2014 13:39:46 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 783631A06E8 for ; Tue, 18 Mar 2014 13:39:46 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WQ0nR-00072U-51 for weirds@ietf.org; Tue, 18 Mar 2014 20:39:37 +0000 Received: from mail-lb0-f173.google.com ([209.85.217.173]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WQ0nR-0000u3-3w for weirds@ietf.org; Tue, 18 Mar 2014 20:39:37 +0000 Received: by mail-lb0-f173.google.com with SMTP id p9so5127634lbv.4 for ; Tue, 18 Mar 2014 13:39:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=yTCJCOtFf/h2sUKyaH2oKqNJVJH7/a1oS1U2OE8x7JA=; b=LdaTDbWO9UVkt9AfU3jVr/oC8dEtH6AxAzCImT0oRjPJbzUHIG9NfN7viVMOF+lUN2 TXC7YJWdiQxwtn47SWMooRHwzsG01YcyaoctFxh/tue3XdSm3LzcNBxtZg+SjB3hYZQG ZycCqapxPKkJmjkFcnmEW8GaWDvgPrE25moPJyzrg5uZWWTwbymx7+cboeeSW7NhaOp1 8qYiwVtBJNYnPH3FaDvNlIM2Pbsaus4dSHBamunfZcAn2kwuniFB66U9h9dvTMQ0Ln/C cPKTQjCSoa0sppVCPZjgki+qSh0ROYQXOHwQw7TqOjIWNsS2DCqg/1rRf/Apd/rzZZsk wYxw== X-Gm-Message-State: ALoCoQlpA6Sg3rUxc1Y2aTU+VHXfs+N+P3nBZ4MLttqn2vPg48PeewwkApaGVg7S1IOgglDblOjvG1RXLeT5tZoYfeI7gIQMB3PjZ/tjs8owtbrq/l991pKBJr8US+OX0XN1YjfO2hzE X-Received: by 10.152.2.225 with SMTP id 1mr2827171lax.37.1395175170874; Tue, 18 Mar 2014 13:39:30 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.2.225 with SMTP id 1mr2827160lax.37.1395175170739; Tue, 18 Mar 2014 13:39:30 -0700 (PDT) Received: by 10.112.204.34 with HTTP; Tue, 18 Mar 2014 13:39:30 -0700 (PDT) In-Reply-To: <53289ACC.1090406@viagenie.ca> References: <5321FF83.8010801@afilias.info> <532898D4.4000204@afilias.info> <53289ACC.1090406@viagenie.ca> Date: Tue, 18 Mar 2014 16:39:30 -0400 Message-ID: From: Ernie Dainow To: Simon Perreault Content-Type: multipart/alternative; boundary=089e013c61a073a33704f4e7882f Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/8rK-MW6KQsXI_5UYx6idnqupUtI Cc: "weirds@ietf.org" Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:39:49 -0000 --089e013c61a073a33704f4e7882f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 18, 2014 at 3:13 PM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 15:04, Ernie Dainow a =E9crit : > > Actually what is the expectation of the server to process searches for > > xxx* or xxx.* > > > > It seems that a server needs to submit this search to every tld server. > > This implies it needs to cycle through all the urls in the IANA > > bootstrap table. From the client's point of view, this is a single > > request, so it expects a single response. That means the server has to > > aggregate all the results from each server it queries into one > > integrated response. If one server exceeds its search limit and returns > > "searchResultsTruncated" : true, there is no way to indicate what subse= t > > of the total response it applies to. > > Why would the RDAP server query other servers? Why doesn't it only > return what it has or hasn't in its own database? > That is a search for xxx*.tld or xxx.tld. The spec gives an explicit example for xxx*: the search pattern "exam*" will match "example.com" and "example.net"= . If you are the com server and just return "example.com" this is misleading to the client if "example.net" also exists on the net server. xxx.* is also a search across tld's Searches across tld's should be deferred. -Ernie > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --089e013c61a073a33704f4e7882f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 18, 2014 at 3:13 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 2014-03-18 15:04, Ernie Dainow a =E9crit :
> Actually what is the expectation of the server to proc= ess searches for
> xxx* or xxx.*
>
> It seems that a server needs to submit this search to every tld server= .
> This implies it needs to cycle through all the urls in the IANA
> bootstrap table. From the client's point of view, this is a single=
> request, so it expects a single response. That means the server has to=
> aggregate all the results from each server it queries into one
> integrated response. If one server exceeds its search limit and return= s
> "searchResultsTruncated" : true, there is no way to indicate= what subset
> of the total response it applies to.

Why would the RDAP server query other servers? Why doesn't it onl= y
return what it has or hasn't in its own database?
=
That is a search for xxx*.tld or xxx.tld.
=A0
The spec gives an explicit example for xxx*:
=A0 =A0 =A0 t= he search pattern "exam*" will match "example.com" and=A0"example.net".

If you are the com server and just return "= example.com"=A0this = is misleading to the client if "example= .net" also exists on the net server.

xxx.* is also a search across tld's

<= /div>
Searches across tld's should be deferred.

-Ernie

=A0

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca
STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca

_______________________________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--089e013c61a073a33704f4e7882f-- From nobody Tue Mar 18 14:03:35 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA441A0427 for ; Tue, 18 Mar 2014 14:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.825 X-Spam-Level: X-Spam-Status: No, score=-1.825 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, 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 nQGCkCXMmLCS for ; Tue, 18 Mar 2014 14:03:29 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7101A0125 for ; Tue, 18 Mar 2014 14:03:29 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1WQ1AO-0001J4-5X for weirds@ietf.org; Tue, 18 Mar 2014 21:03:20 +0000 Received: from mail-lb0-f176.google.com ([209.85.217.176]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1WQ1AO-0002cD-4a for weirds@ietf.org; Tue, 18 Mar 2014 21:03:20 +0000 Received: by mail-lb0-f176.google.com with SMTP id 10so5205579lbg.35 for ; Tue, 18 Mar 2014 14:03:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=swNi5wtO3NlW5WXU/8mLxlrBtGt/jeCsxwM+iLxI03E=; b=mE+Eyxke1buTm4ySIwHsJ40VTYMdBmkjfCaJh/R7eI3stqwNPMIX4zh0UHn/05PZru wx2T791vELzkbH69uZ84cwZk9f2kIBvqIvBWLIGxbKXtcttxTJ3S/wjTfpqPJHEr7yvP +31AK9YB7DSj5xNOt1aFjz503ltwPsRpDkdCTS/Eg1alybHoRGTmChrAPJa4+L5hl89P wrlKd0ACdtSMLgeBrGfLc+h0xcIwj+ksUIS05axmUFGtYVfNB4WozTXlZ+b2T4qFeIb1 DEml9psfGmrwy0NC7KX5dBhLAMvrXT8/p0MOmypo+Wd24tZyLrk06l/p2zXDEouccQLt m64A== X-Gm-Message-State: ALoCoQkkxl1Ghh57eHFNnCPPHHKkI7Ml8HdWY0xHIzbSIu6YPzM/aV6uNUIQibpwur2TTr6uLmPPziPzfW/ceyvkESx49AKuNewpCUt7xx9lO8u4/7x2AXrgN3La8PBlIyxppRMoqPJo X-Received: by 10.112.13.101 with SMTP id g5mr2943213lbc.39.1395176594000; Tue, 18 Mar 2014 14:03:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.13.101 with SMTP id g5mr2943198lbc.39.1395176593876; Tue, 18 Mar 2014 14:03:13 -0700 (PDT) Received: by 10.112.204.34 with HTTP; Tue, 18 Mar 2014 14:03:13 -0700 (PDT) In-Reply-To: <53286C9B.2080502@viagenie.ca> References: <5328570E.5050908@afilias.info> <53285D0C.4090706@viagenie.ca> <5328657F.8050900@afilias.info> <53286C9B.2080502@viagenie.ca> Date: Tue, 18 Mar 2014 17:03:13 -0400 Message-ID: From: Ernie Dainow To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c3a6fc46fc5304f4e7dd54 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/-kqZy6Gk4KozMBY-NGXSyj3OuMU Cc: "weirds@ietf.org" Subject: Re: [weirds] Http return code 400 vs 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:03:31 -0000 --001a11c3a6fc46fc5304f4e7dd54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The query spec specifies IDNA processing as in RFC5891: If the client sends the server an IDN in U-label format, servers that support IDNs MUST convert the IDN into A-label format and perform IDNA processing as specified in RFC 5891 [RFC5891]. The server should perform an exact match lookup using the A-label. The reference for lookup (as opposed to name registration) is in RFC 5891, Section 5. In 5.2. it says The string is converted from the local character set into Unicode, if it is not already in Unicode. We have usually tried to offload the burden of difficult checking from the client to the server. That principle applies here -- the client can submit Unicode and the server does all the IDNA validity checking. -Ernie On Tue, Mar 18, 2014 at 11:56 AM, Simon Perreault < simon.perreault@viagenie.ca> wrote: > Le 2014-03-18 11:25, Ernie Dainow a =C3=A9crit : > > RDAP will be used as a backend for a lot of web application. So the use= r > > will be entering the domain name to lookup, and could enter > > > > =CF=83=CE=B5=CE=B9=CF=81=CE=AC=CF=84=CE=AC=CE=BE=CE=B7=CF=83=CF=85=CF= =80=CE=BF=CF=85=CF=81=CE=B3=CE=B5=CE=AF=CF=89=CE=BD=CE=A3=CF=8D=CE=BD=CE=B8= =CE=B5=CF=83=CE=B7=CF=85=CF=80=CE=BF=CF=85=CF=81=CE=B3=CE=B9=CE=BA=CE=BF=CF= =8D=CF=83=CF=85=CE=BC=CE=B2=CE=BF=CF=85=CE=BB=CE=AF=CE=BF=CF=85=CE=BF=CF=85= =CE=BF=CF=85=CE=BF.info > > > > just as easily as you did in your test script. So the error originates > > with user input. > > The current text allows A-labels and U-labels to be sent to the server. > That means that only IDNA-valid strings are allowed (see RFC 5890 > section 2.3.2.1). The above example is not IDNA-valid, which means it is > not a U-label. > > If we want to impose no IDNA requirements on the client, then it is not > sufficient to allow U-label queries: we need to allow raw Unicode. The > server would then run the IDNA algorithm on the raw Unicode, generating > an IDNA-valid string, and running the query on that. > > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca > STUN/TURN server --> http://numb.viagenie.ca > --001a11c3a6fc46fc5304f4e7dd54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The query spec specifies IDNA processing as in RFC589= 1:
=C2=A0 =C2=A0If the client sends the server an IDN in U-label = format, servers that
=C2=A0 =C2=A0support IDNs MUST convert the I= DN into A-label format and perform
=C2=A0 =C2=A0IDNA processing as specified in RFC 5891 [RFC5891]. The s= erver
=C2=A0 =C2=A0should perform an exact match lookup using the= A-label.
=C2=A0 =C2=A0
The reference for lookup (as op= posed to name registration) is in=C2=A0=C2=A0RFC 5891, Section 5.=C2=A0
In 5.2. it says
= The string is converted from the local character set into Unicode, i= f
it is not al= ready in Unicode.

We have usually tried to offload the burden of difficul= t checking from the client to the server. That principle applies here -- th= e client can submit Unicode and the server does all the IDNA validity check= ing.

-Ernie



On Tue, Mar 18, 2014 at 11:56 AM, S= imon Perreault <simon.perreault@viagenie.ca> wrote= :
Le 2014-03-18 11:25, Ernie Dainow a =C3=A9cr= it :
> RDAP will be used as a backend for a lot of web applic= ation. So the user
> will be entering the domain name to lookup, and could enter
>
> =CF=83=CE=B5=CE=B9=CF=81=CE=AC=CF=84=CE=AC=CE=BE=CE=B7=CF=83=CF=85=CF= =80=CE=BF=CF=85=CF=81=CE=B3=CE=B5=CE=AF=CF=89=CE=BD=CE=A3=CF=8D=CE=BD=CE=B8= =CE=B5=CF=83=CE=B7=CF=85=CF=80=CE=BF=CF=85=CF=81=CE=B3=CE=B9=CE=BA=CE=BF=CF= =8D=CF=83=CF=85=CE=BC=CE=B2=CE=BF=CF=85=CE=BB=CE=AF=CE=BF=CF=85=CE=BF=CF=85= =CE=BF=CF=85=CE=BF.info
>
> just as easily as you did in your test script. So the error originates=
> with user input.

The current text allows A-labels and U-labels to be sent to the serve= r.
That means that only IDNA-valid strings are allowed (see RFC 5890
section 2.3.2.1). The above example is not IDNA-valid, which means it is not a U-label.

If we want to impose no IDNA requirements on the client, then it is not
sufficient to allow U-label queries: we need to allow raw Unicode. The
server would then run the IDNA algorithm on the raw Unicode, generating
an IDNA-valid string, and running the query on that.

Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source =C2=A0 =C2=A0 =C2=A0 =C2=A0--> http://ecdysis.viagenie.ca
STUN/TURN server =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --> http://numb.viagenie.ca=

--001a11c3a6fc46fc5304f4e7dd54-- From nobody Tue Mar 18 14:06:06 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5201A0427 for ; Tue, 18 Mar 2014 14:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 7lIBK8gZguFH for ; Tue, 18 Mar 2014 14:06:04 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8619B1A0421 for ; Tue, 18 Mar 2014 14:06:04 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:f981:e226:281f:c92d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id F104040377; Tue, 18 Mar 2014 17:05:55 -0400 (EDT) Message-ID: <5328B533.1000005@viagenie.ca> Date: Tue, 18 Mar 2014 17:05:55 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ernie Dainow References: <5328570E.5050908@afilias.info> <53285D0C.4090706@viagenie.ca> <5328657F.8050900@afilias.info> <53286C9B.2080502@viagenie.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/wP_BZ2KBf2-b6OHstO-zZVvNC30 Cc: "weirds@ietf.org" Subject: Re: [weirds] Http return code 400 vs 404 X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:06:06 -0000 Le 2014-03-18 17:03, Ernie Dainow a écrit : > The query spec specifies IDNA processing as in RFC5891: > If the client sends the server an IDN in U-label format, servers that > support IDNs MUST convert the IDN into A-label format and perform > IDNA processing as specified in RFC 5891 [RFC5891]. The server > should perform an exact match lookup using the A-label. > > The reference for lookup (as opposed to name registration) is in RFC > 5891, Section 5. > In 5.2. it says > The string is converted from the local character set into Unicode, if > it is not already in Unicode. > > We have usually tried to offload the burden of difficult checking from > the client to the server. That principle applies here -- the client can > submit Unicode and the server does all the IDNA validity checking. I fully agree with that principle. That's why I suggest to allow not only A-label and U-label requests, but any raw Unicode string. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Tue Mar 18 17:50:27 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8E51A046F for ; Tue, 18 Mar 2014 17:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no 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 dKVm9V8jqWWa for ; Tue, 18 Mar 2014 17:50:24 -0700 (PDT) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) by ietfa.amsl.com (Postfix) with ESMTP id 656721A0335 for ; Tue, 18 Mar 2014 17:50:23 -0700 (PDT) Received: (qmail 27825 invoked from network); 19 Mar 2014 00:50:12 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 19 Mar 2014 00:50:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5328e9c4.xn--9vv.k1403; i=johnl@user.iecc.com; bh=LJtoQqfPRuywFqso1+tyYEyZUZjGIiYl88wiCLq1ONk=; b=p35CCM/VsxYMhRgjslZ8G8uGvOHtCuP2qU1ua82UIw19oEP/2uL/4T/CC9uItLqlJe4e6tBj2+WBDzPYi6RTX8/aU1RfcztfVRyUdwZ+Nw4p0InZqy+DIp9WUg8sxY2r0R1VezeMfSVpF5LHWfKppRih8ohGiWJQ07pyD/71o1UsC85WIe2YNCyMbwopioSlptFXnTBdiFD1sKPJaCiS5kuqhqNESRsE8rYkHGqDCl2z1jZslQ+/Xg8iKuYuXM6l DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5328e9c4.xn--9vv.k1403; bh=LJtoQqfPRuywFqso1+tyYEyZUZjGIiYl88wiCLq1ONk=; b=ZPmoudeD5W98G8eLWg0r+GddNgLxqaGj0xtSdBkUlliIbwU+Of4T7f2AROrfbXWFigVx5Gcs2R9P1MXvksSo7B06VgvUbH2JN8uIC9XIc7TVEjMEmm4blXgqYZLEgGAFGT6Eh8IurqMCzo1GLqBpPoZrpcdMTrGVugM6CXDnv+epkhkenTnrX858uFklfTCxJJUdPl7rvG27aZgNdfzR/mVFvhauPfOyqBCCtMmRY2PMkNEZB4olS9rWq1mkIukM Date: 19 Mar 2014 00:49:50 -0000 Message-ID: <20140319004950.10409.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/gA3TynjPFP-PsQlB3Qk7Wc_9tKY Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 00:50:26 -0000 >The spec gives an explicit example for xxx*: > the search pattern "exam*" will match "example.com" and "example.net". If that's what the spec says, the spec needs to be fixed. The intention is to match what current WHOIS servers do, which is a prefix match on whatever data the server handles. Nobody expects it to go searching other servers. R's, John From nobody Tue Mar 18 18:03:15 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF771A04B1 for ; Tue, 18 Mar 2014 18:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 A5nufC_V-J-A for ; Tue, 18 Mar 2014 18:03:10 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 21E341A0335 for ; Tue, 18 Mar 2014 18:03:10 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 9FFDB2136A6; Tue, 18 Mar 2014 21:03:01 -0400 (EDT) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id 22A55213680; Tue, 18 Mar 2014 21:03:01 -0400 (EDT) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 18 Mar 2014 21:03:00 -0400 Received: from CHAXCH02.corp.arin.net ([169.254.2.48]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 18 Mar 2014 21:02:59 -0400 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Inter-Op discrepancy with specs: Search patterns Thread-Index: AQHPQt4iYLnhIoxc5EqxBlSUHWxr6prnkaQAgABF8QD//8CZAA== Date: Wed, 19 Mar 2014 01:02:58 +0000 Message-ID: In-Reply-To: <20140319004950.10409.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [192.149.252.96] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/TtCDkDHjzPPm7alYk9vRod7h6Qc Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 01:03:13 -0000 On 3/18/14, 8:49 PM, "John Levine" wrote: >>The spec gives an explicit example for xxx*: >> the search pattern "exam*" will match "example.com" and >>"example.net". > >If that's what the spec says, the spec needs to be fixed. > >The intention is to match what current WHOIS servers do, which is a >prefix match on whatever data the server handles. Nobody expects it >to go searching other servers. I don=B9t think searching other servers was ever the intent. The purpose of this is to allow one query to search both .com and .net (or whatever) if that server handles both .com and .net (or whatever). -andy From nobody Wed Mar 19 00:38:31 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D94E1A03B1 for ; Wed, 19 Mar 2014 00:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 H4d5Iu-1b_qu for ; Wed, 19 Mar 2014 00:38:26 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 93A461A03AD for ; Wed, 19 Mar 2014 00:38:09 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUylJWB4Bd6FBQ+yDz1UwYyCeVgprTBwv@postini.com; Wed, 19 Mar 2014 00:38:17 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s2J7c0xn025050 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 03:38:00 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 03:38:00 -0400 From: "Hollenbeck, Scott" To: Andy Newton Thread-Topic: [weirds] Inter-Op discrepancy with specs: Search patterns Thread-Index: AQHPQt4iGe5mHPGuXU6j62qytZuhqJrnkaQAgABF8QCAAAOsAIAAK1Bn Date: Wed, 19 Mar 2014 07:37:59 +0000 Message-ID: References: <20140319004950.10409.qmail@joyce.lan>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/OVuD4MYNNQJnydljbUGAYxMMiZM Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Inter-Op discrepancy with specs: Search patterns X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:38:28 -0000 (Sorry for top posting) What Andy said below is correct. Scott > On Mar 19, 2014, at 10:03 AM, "Andy Newton" wrote: >=20 > On 3/18/14, 8:49 PM, "John Levine" wrote: >=20 >>> The spec gives an explicit example for xxx*: >>> the search pattern "exam*" will match "example.com" and >>> "example.net". >>=20 >> If that's what the spec says, the spec needs to be fixed. >>=20 >> The intention is to match what current WHOIS servers do, which is a >> prefix match on whatever data the server handles. Nobody expects it >> to go searching other servers. >=20 > I don=B9t think searching other servers was ever the intent. The purpose = of > this is to allow one query to search both .com and .net (or whatever) if > that server handles both .com and .net (or whatever). >=20 > -andy >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From nobody Sun Mar 30 02:57:07 2014 Return-Path: X-Original-To: weirds@ietfa.amsl.com Delivered-To: weirds@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EB21A0841 for ; Sun, 30 Mar 2014 02:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 VBXz65Izq0HD for ; Sun, 30 Mar 2014 02:57:04 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id AE3FD1A07AE for ; Sun, 30 Mar 2014 02:57:03 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id b13so4748437wgh.17 for ; Sun, 30 Mar 2014 02:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=4rgn6mSmnuK572pBGF5CrisIhCT6lKl9IQpV5++TEis=; b=bP49Okd6NYjz2R1vtjZxqFRs93c8j7+G3fBL3OhxY3G4ctTYJuiIjMlw8diGtLiWPh N46dUAPvsuFNQqh1h/rVhAlQ+q0AYVnTNS0w89tTbdo1Ab8Pm6FWOOXbzOGAEVabQjmK cNOqsCkMhlQEk7NAl+igwH3njVn4ilU0r/i5r2A6IKJ1qKv8soCnJk2JNeubUsYWxg2t vVoYULT5spJm/5B/o/75sI6nySZxhKTTGvmfY2ck4NDuvxFeZSaKfK5aM0HO6C1Ll/bH cBlUtDIcjbo5cyQ0GKDh5bUFTICuxNmOtb9B2tM2rgYYX2Ld/ZdkMvKLTfvEPrK2BkGz 8gbg== MIME-Version: 1.0 X-Received: by 10.194.2.145 with SMTP id 17mr590451wju.60.1396173420488; Sun, 30 Mar 2014 02:57:00 -0700 (PDT) Received: by 10.180.90.140 with HTTP; Sun, 30 Mar 2014 02:57:00 -0700 (PDT) Date: Sun, 30 Mar 2014 02:57:00 -0700 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7b3a896cc5ee2d04f5cff46a Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/rWoJ80Cl3Qis1p7Hb07OsnhlBvQ Subject: [weirds] IETF 89 Minutes X-BeenThere: weirds@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 09:57:05 -0000 --047d7b3a896cc5ee2d04f5cff46a Content-Type: text/plain; charset=ISO-8859-1 I have posted the minutes from our meeting at IETF 89. Apologies for how long this has taken. They are available here: http://www.ietf.org/proceedings/89/minutes/minutes-89-weirds Please advise ASAP if there's anything in there that needs to be corrected. There were several action items that resulted from this meeting, mainly getting some discussion threads going and getting our few remaining issues recorded in tracker items so we can be sure they are addressed. I plan to do that in the coming week. As Olaf suggested, at the rate we're progressing, we should be able to finish this work such that we don't need to meet in Toronto. Let's make it happen! -MSK, WEIRDS co-chair --047d7b3a896cc5ee2d04f5cff46a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have posted the minutes from our meeting at IE= TF 89.=A0 Apologies for how long this has taken.=A0 They are available here= :

http://www.ietf.org/proceedings/89/minutes/minutes-89-weirds

Please advise ASAP if there's anything in there that needs to= be corrected.

There were several action items that resulted from th= is meeting, mainly getting some discussion threads going and getting our fe= w remaining issues recorded in tracker items so we can be sure they are add= ressed.=A0 I plan to do that in the coming week.

As Olaf suggested, at the rate we're progressing, we sho= uld be able to finish this work such that we don't need to meet in Toro= nto.=A0 Let's make it happen!

-MSK, WEIRDS co-c= hair
--047d7b3a896cc5ee2d04f5cff46a--