From shollenbeck@verisign.com Mon Dec 2 04:07:22 2013 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 5C3871AE3FD for ; Mon, 2 Dec 2013 04:07:22 -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 mxNE89vyNZ7b for ; Mon, 2 Dec 2013 04:07:18 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 24F171AE351 for ; Mon, 2 Dec 2013 04:07:11 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKUpx37L5tMGPZ66a1YspOikOVhViv0a8h@postini.com; Mon, 02 Dec 2013 04:07:16 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 rB2C78xs026565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 07:07:08 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 2 Dec 2013 07:07:07 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: [weirds] DNS Bootstrapping revisited Thread-Index: AQHO7k1RV+OeUHqpMkuxdJwUsJ/085pA0C1g Date: Mon, 2 Dec 2013 12:07:06 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492F2C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F492EDEE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131125180112.55423.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F492EF0B6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5294903A.8060609@gmail.com> <831693C2CDA2E849A7D7A712B24E257F492EF110@BRN1WNEXMBX01.vcorp.ad.vrsn.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_831693C2CDA2E849A7D7A712B24E257F492F2C57BRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: John Levine , "carlos@lacnic.net" , "weirds@ietf.org" Subject: Re: [weirds] DNS Bootstrapping revisited 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, 02 Dec 2013 12:07:22 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F492F2C57BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Saturday, November 30, 2013 11:25 PM To: Hollenbeck, Scott Cc: carlos@lacnic.net; John Levine; weirds@ietf.org Subject: Re: [weirds] DNS Bootstrapping revisited On Tue, Nov 26, 2013 at 4:17 AM, Hollenbeck, Scott > wrote: > -----Original Message----- > From: Carlos M. Martinez [mailto:carlosm3011@gmail.com] > Sent: Tuesday, November 26, 2013 7:13 AM > To: Hollenbeck, Scott; John Levine; weirds@ietf.org > Subject: Re: [weirds] DNS Bootstrapping revisited > > Is bootstrapping some queries and not all acceptable for the WG ? Good question. As I said, "If bootstrapping remains a problem to be address= ed we should be very clear about the limitations and types of queries that = it cannot address". Can you clarify "types of queries"? Are you talking about something other= than names queries vs. number queries? [SAH] No, I'm specifically referring to bootstrapping a search for a domain= pattern like "example*", or an entity search with no association to an ear= lier query. There are some patterns for which it is impossible to determine= a server identity or a clue that can be used to associate a query with a s= erver. Those limitations need to be acknowledged. Scott --_000_831693C2CDA2E849A7D7A712B24E257F492F2C57BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Saturday, November 30, 2013 11:25 PM
To: Hollenbeck, Scott
Cc: carlos@lacnic.net; John Levine; weirds@ietf.org
Subject: Re: [weirds] DNS Bootstrapping revisited<= /p>

 

On Tue, Nov 26, 2013 at 4:17 AM, Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

> -----Original Message-----
> From: Carlos M. Martinez [mailto:carlosm3011@gmail.com]
> Sent: Tuesday, November 26, 2013 7:13 AM
> To: Hollenbeck, Scott; John Levine; weirds@ietf.org
> Subject: Re: [weirds] DNS Bootstrapping revisited
>

> Is bootstrapping= some queries and not all acceptable for the WG ?

Good question. As I said, "If bootstrapping rem= ains a problem to be addressed we should be very clear about the limitation= s and types of queries that it cannot address".

 


Can you clarify "types of queries"?   Are you talking about = something other than names queries vs. number queries?

 

[SAH] No, I’m specifically referring= to bootstrapping a search for a domain pattern like “example*”= , or an entity search with no association to an earlier query. There are so= me patterns for which it is impossible to determine a server identity or a cl= ue that can be used to associate a query with a server. Those limitations n= eed to be acknowledged.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F492F2C57BRN1WNEXMBX01vc_-- From prvs=00412f3063=johnl@taugh.com Mon Dec 2 06:27:16 2013 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 30F3B1AE434 for ; Mon, 2 Dec 2013 06:27:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.792 X-Spam-Level: X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 0WKs-mOwCnhg for ; Mon, 2 Dec 2013 06:27:14 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 026AB1AE2CC for ; Mon, 2 Dec 2013 06:27:13 -0800 (PST) Received: (qmail 83403 invoked from network); 2 Dec 2013 14:27:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 2 Dec 2013 14:27:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529c98be.xn--hew.k1310; i=sendmail-bs@submit.iecc.com; bh=yDDRpHCoqwGjpwz1mQ3i/MNXT7DUHr7VVVH+ont58vc=; b=KrvFqEHeE7ij9Ld7SFfqyoLtu2Jps9P6qlZJyIMk2S4ZTSgOTT/ZTOYTktePrNl7RvUAmWPxHYrcxvTcDnh7fnTr6hxrvTyEisU0BAvG+3E2K5UaawGvSbA3GdrqxFrtPkPJn0laVTGqiTI/CUZ8GdUESeb2yHPQZNVC9i7op1mSHzWqAXgZYrhNxHHjLn6ZrTbyFpIce68EJm0I/XXDiTTFc1lnsbsgi/X0V1Xa+NnQ4ZSeQS5mw5aYagn+xQpf DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:from:to:cc:subject:in-reply-to:message-id:references:mime-version:content-type:user-agent:cleverness; s=529c98be.xn--hew.k1310; olt=sendmail-bs@submit.iecc.com; bh=yDDRpHCoqwGjpwz1mQ3i/MNXT7DUHr7VVVH+ont58vc=; b=jVRG5Lqg3E1ffjHx+jjdgiftGQXJ/02/w8bO0Dh3SnPPAccaKlQShtAgnsMQtTdeVPPMphIfprLNKG8Jf8E5yguaw5SsdokTSivXunP7uXwZ+1w2BjuknpTwY+c2aOVQMPem27tqjOWHx2qA1r8qFS0bH24liSFDfmDqpdMlzSZDbER0DijEC7g33uRlAv9DhBGvBha+u/UJ8qjAJ9UpvkX04pjNnmDb8h7UsXWaMrO2xQSo3YZUNoBUBm5l/XB2 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 2 Dec 2013 14:27:10 -0000 Date: Mon, 2 Dec 2013 09:27:10 -0500 (EST) From: John R Levine To: "Hollenbeck, Scott" In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492F2C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F492EDEE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131125180112.55423.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F492EF0B6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5294903A.8060609@gmail.com> <831693C2CDA2E849A7D7A712B24E257F492EF110@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F492F2C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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 Cc: "weirds@ietf.org" Subject: Re: [weirds] DNS Bootstrapping revisited 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, 02 Dec 2013 14:27:16 -0000 > Can you clarify "types of queries"? Are you talking about something other than names queries vs. number queries? > > [SAH] No, I'm specifically referring to bootstrapping a search for a domain pattern like "example*", or an entity search with no association to an earlier query. There are some patterns for which it is impossible to determine a server identity or a clue that can be used to associate a query with a server. Those limitations need to be acknowledged. Completely agree. I understand (in general principle) how one might bootstrap individual domain names at the TLD level, IP addresses, and ASNs. I don't think there is any plausible way to bootstrap anything else. R's, John From shollenbeck@verisign.com Mon Dec 2 06:40:51 2013 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 D56381AE48B for ; Mon, 2 Dec 2013 06:40:51 -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 siWOl7zJH7-x for ; Mon, 2 Dec 2013 06:40:50 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id 93C011A8028 for ; Mon, 2 Dec 2013 06:40:48 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUpyb7p6sPuuWDY661TXQ0dozOUSLASVi@postini.com; Mon, 02 Dec 2013 06:40:47 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 rB2EejAs030985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 09:40:45 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 2 Dec 2013 09:40:45 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] comments on draft-ietf-weirds-rdap-query-08 Thread-Index: AQHO66kB6c8cgiaRTEuipVa6qehkfppA/OYg Date: Mon, 2 Dec 2013 14:40:44 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492F30A1@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20131127194116.GN15479@mx1.yitter.info> In-Reply-To: <20131127194116.GN15479@mx1.yitter.info> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] comments on draft-ietf-weirds-rdap-query-08 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, 02 Dec 2013 14:40:52 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldw0KPiBTdWxsaXZhbg0KPiBT ZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEzIDI6NDEgUE0NCj4gVG86IHdlaXJkc0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBbd2VpcmRzXSBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXdlaXJk cy1yZGFwLXF1ZXJ5LTA4DQo+IA0KPiBIaSwNCj4gDQo+IE5vdyB0aGF0IEknbSBhbGwgc29ydGVk IG91dCBvbiB3aGljaCBkb2N1bWVudCBJIG91Z2h0IHRvIGJlIHBheWluZw0KPiBhdHRlbnRpb24g dG8sIEknbSByZXZpZXdpbmcgZHJhZnQtaWV0Zi13ZWlyZHMtcmRhcC1xdWVyeS0wOC4gIEhlcmUg YXJlDQo+IHNvbWUgY29tbWVudHMuDQo+IA0KPiBTZWN0aW9uIDMuMS4zOiAid2hlcmUgWFhYWCBp cyBhIGZ1bGx5LXF1YWxpZmllZCBkb21haW4gbmFtZSBbUkZDNDM0M10iDQo+IFRoZSBzdHJpbmcg ImZ1bGx5LXF1YWxpZmllZCBkb21haW4gbmFtZSIgZG9lcyBub3QsIGFzIG5lYXIgYXMgSSBjYW4N Cj4gdGVsbCwgYXBwZWFyIGluIFJGQyA0MzQzLiAgV2hhdCBpc24ndCBjbGVhciB0byBtZSBpcyB3 aGV0aGVyIHRoaXMgaXMNCj4gX3JlYWxseV8gZnVsbHktcXVhbGlmaWVkIGluIHRoZSBETlMgc2Vu c2UgLS0gZS5nLiAiZXhhbXBsZS5jb20uIjsgb3INCj4gZnVsbHktcXVhbGlmaWVkIGluIHRoZSB3 YXkgYW4gZW5vcm1vdXMgbnVtYmVyIG9mIHBlb3BsZSB1c3VhbGx5IHVzZQ0KPiBpdCwgd2hpY2gg aXMgcmVhbGx5ICJxdWFsaWZpZWQgcmVsYXRpdmUgdG8gdGhlIHJvb3QiIC0tDQo+IGUuZy4gImV4 YW1wbGUuY29tIi4NCg0KVHlwaWNhbCBjbGllbnQgdXNlIGlzICJxdWFsaWZpZWQgcmVsYXRpdmUg dG8gdGhlIHJvb3QiLg0KDQpXZSBjb3VsZCBwcm9iYWJseSBjb21lIHVwIHdpdGggYSBiZXR0ZXIg cmVmZXJlbmNlIHRoYW4gNDM0My4gSW4gRVBQIHdlIHVzZSBSRkNzIDk1MiBhbmQgMTEyMyBmb3Ig ZG9tYWluIGFuZCBob3N0IG5hbWUgc3ludGF4LiBXaGljaCByZWZlcmVuY2Ugd291bGQgeW91IHJl Y29tbWVuZD8NCg0KPiBMYXRlciwgIklETiBsYWJlbHMgU0hPVUxEIE5PVCBiZSByZXByZXNlbnRl ZCBhcyBhIG1peHR1cmUgb2YgQS1sYWJlbHMNCj4gYW5kIFUtbGFiZWxzLiIgIEkgdGhpbmsgdGhp cyBwcm9iYWJseSBtZWFucyAiSWYgWFhYWCBjb250YWlucyBhbnkgSURODQo+IGxhYmVsLCB0aGVu IGV2ZXJ5IElETiBsYWJlbCBpbiBYWFhYIFNIT1VMRCBiZSBlaXRoZXIgQS1sYWJlbHMgb3INCj4g VS1sYWJlbHMsIGFuZCBub3QgYSBtaXh0dXJlLiIgIFBlcmhhcHMgc2hvcnRlciBhbmQgc3RpbGwg YXMgY2xlYXIgaXMsDQo+ICJJRE5zIFNIT1VMRCBOT1QgYmUgcmVwcmVzZW50ZWQgYXMgYSBtaXh0 dXJlIG9mIEEtbGFiZWxzIGFuZCBVLWxhYmVsczsNCj4gdGhhdCBpcywgYW55IElETiBTSE9VTEQg dXNlIG9ubHkgQS1sYWJlbHMgb3Igb25seSBVLWxhYmVscy4iICBUaGUNCj4gcmVhc29uIEknbSBo YXZpbmcgdHJvdWJsZSB3aXRoIHRoaXMgaXMgdGhhdCAieG4tLWp4YWxwZGxwLmNvbSINCj4gY29u dGFpbnMgYW4gQS1sYWJlbCBhbmQgYW4gTlItTERIIGxhYmVsLCBzbyB3ZSBjYW4ndCBqdXN0IHNh eSAibm8NCj4gbWl4aW5nIi4gIElmIG5vYm9keSBlbHNlIGZpbmRzIHRoZSBleGlzdGluZyB0ZXh0 IHBvc3NpYmx5IG1pc2xlYWRpbmcsDQo+IEkgZG9uJ3QgZmVlbCB0b28gc3Ryb25nbHkgYWJvdXQg aXQuDQoNCkknbGwgdXNlIHlvdXIgdGV4dCAtIHRoYW5rcy4NCg0KPiBIYXZpbmcgcmVhZCB0aGlz IHNlY3Rpb24gYW5kIHNlY3Rpb24gNiwgSSByZWFsbHkgdGhpbmsgdGhhdCAzLjIuMw0KPiBzaG91 bGQgZWl0aGVyIHNheSB0aGF0IGl0IG9ubHkgc3VwcG9ydHMgQVNDSUksIG9yIGVsc2UgdGhhdCB3 ZSBzaG91bGQNCj4gc2F5IHNvbWV0aGluZyBtb3JlIGFib3V0IHRoZSBvbi10aGUtd2lyZSBiZWhh dmlvdXIgcGFydGljdWxhcmx5IGZvcg0KPiBlbnRpdHkgbmFtZSBzZWFyY2hlcy4gIEkgdGhpbmsg anVzdCBob3BpbmcgdGhhdCBib3RoIGVuZHMgd2lsbCBkbyB0aGUNCj4gcmlnaHQgdGhpbmcgaXMg YW4gZXhjZWxsZW50IHdheSB0byByZWR1Y2UgaW50ZXJvcGVyYWJpbGl0eS4gIEhlcmUgaXMNCj4g d2hhdCBJIHRoaW5rIHNob3VsZCBoYXBwZW4uDQo+IA0KPiAgICAgIEFuIFJEQVAgY2xpZW50IHdp c2hpbmcgdG8gcGVyZm9ybSBhbiBlbnRpdHkgc2VhcmNoIGJ5IG5hbWUgTVVTVA0KPiAgICAgIGNv bnZlcnQgdGhlIHNlYXJjaCB0ZXJtIGludG8gVW5pY29kZSBpbiBVVEYtOCBlbmNvZGluZyB1c2lu Zw0KPiAgICAgIHdoYXRldmVyIGxvY2FsIHJ1bGVzIGFyZSBpbiBlZmZlY3QuICBJdCBTSE9VTEQg bWFwIGZ1bGx3aWR0aCBhbmQNCj4gICAgICBoYWxmd2lkdGggY2hhcmFjdGVycyB0byB0aGVpciBk ZWNvbXBvc2l0aW9uIGVxdWl2YWxlbnRzLiAgSXQgTUFZDQo+ICAgICAgcGVyZm9ybSBhbnkgbG9j YWwgY2FzZSBtYXBwaW5nIGRlZW1lZCBuZWNlc3NhcnkuICBJdCBTSE9VTEQNCj4gICAgICBub3Jt YWxpemUgdGhlIHN0cmluZyB1c2luZyBORkMuICBJIHRoaW5rIHRoaXMgaXMgYWxsIEknZCB3YW50 IHRvDQo+ICAgICAgcHV0IGluIGEgcHJlY2lzIHByb2ZpbGUgZm9yIGNsaWVudHM7IGl0J2QgYmUg YmFzZWQgb24NCj4gICAgICBGcmVlRm9ybUNsYXNzLiAgSXQnZCBiZSBjbGVhbmVyIHRvIHB1dCB0 aGlzIGFsbCBpbiBhIHByb2ZpbGUuDQo+ICAgICAgRmFpbHVyZSB0byBtYXAgZnVsbHdpZHRoIGFu ZCBoYWxmd2lkdGggY2hhcmFjdGVycyBhcmUgbW9yZSBsaWtlbHkNCj4gICAgICB0byBsZWFkIHRv IGZhbHNlIG5lZ2F0aXZlcyBpbiBzZWFyY2hlcy4gIEZhaWx1cmUgdG8gcGVyZm9ybSBORkMNCj4g ICAgICBvbiB0aGUgc3RyaW5nIGluY3JlYXNlcyB0aGUgcHJvYmFiaWxpdHkgdGhhdCB0aGUgc2Vy dmVyIHdpbGwNCj4gICAgICBwZXJmb3JtIE5GQyBhbmQgbWF0Y2ggb24gc29tZXRoaW5nIGRpZmZl cmVudCB0aGFuIHdoYXQgd2FzIHNlbnQuDQo+IA0KPiAgICAgIEFuIFJEQVAgc2VydmVyIHJlY2Vp dmluZyBhIHNlYXJjaCB0ZXJtIHN0cmluZyBNVVNUIHRyZWF0IHRoZQ0KPiAgICAgIGlucHV0IGFz IFVuaWNvZGUgaW4gVVRGLTggZW5jb2RpbmcuICBJZiB0aGUgc2VhcmNoIHRlcm0gaXMgbm90DQo+ ICAgICAgdmFsaWQgVVRGLTgsIHRoZSBzZXJ2ZXIgTUFZIGltbWVkaWF0ZWx5IHN0b3AgcHJvY2Vz c2luZyBhbmQNCj4gICAgICByZXR1cm4gYW4gZXJyb3IuICBUaGUgc2VydmVyIFNIT1VMRCBwZXJm b3JtIE5GQyBvbiB0aGUgc3RyaW5nOw0KPiAgICAgIGZhaWx1cmUgdG8gZG8gdGhpcyBpcyBsaWtl bHkgdG8gbGVhZCB0byB2YXJpYWJpbGl0eSBpbiBzZWFjaGVzDQo+ICAgICAgZGVwZW5kaW5nIG9u IHRoZSBvcmluZ2luYXRpbmcgc3lzdGVtLiAgVGhlIHNlcnZlciBjYW4gdGhlbg0KPiAgICAgIHBy b2Nlc3MgdGhlIHF1ZXJ5Lg0KDQpJJ20gc3RpbGwgbm90IHN1cmUgb2YgaG93IHdlIHdhbnQgdG8g YXBwcm9hY2ggdGhpcy4gVGhlcmUgYXJlIGEgc21hbGwgbnVtYmVyIG9mIHBlb3BsZSBzdWdnZXN0 aW5nIHNpbXBsZSBiaW5hcnkgY29tcGFyaXNvbiwgYW5kIGEgc21hbGxlciBudW1iZXIgc3VnZ2Vz dGluZyBzb21ldGhpbmcgYWtpbiB0byB0aGUgYWJvdmUuIEkgbWF5IGFzayBvdXIgY2hhaXJzIHRv IGNvbnNpZGVyIGEgY29uc2Vuc3VzIGNhbGwgZm9yIG9uZSBhcHByb2FjaCBvciB0aGUgb3RoZXIg c28gd2UgY2FuIHB1dCB0aGlzIHRvIGJlZC4NCg0KPiBJbiBTZWN0aW9uIDQsIHdlIGhhdmUgJ0Eg Y2hhcmFjdGVyIHN0cmluZyByZXByZXNlbnRpbmcgYSB0b3AtbGV2ZWwNCj4gZG9tYWluIE1BWSBi ZSBjb25jYXRlbmF0ZWQgdG8gdGhlIGVuZCBvZiB0aGUgc2VhcmNoIHBhdHRlcm4gdG8gbGltaXQN Cj4gdGhlIHNjb3BlIG9mIHRoZSBzZWFyY2guW+KApl0gVGhlIHNlYXJjaCBwYXR0ZXJuICJleGFt Ki5jb20iIHdpbGwgbWF0Y2gNCj4gImV4YW1wbGUuY29tIi4nICBXaHkgb25seSB0b3AtbGV2ZWwg ZG9tYWluPyAgV2hhdCdzIHdyb25nIHdpdGgNCj4gImV4YW0qLmNvLnVrIiwgZm9yIGluc3RhbmNl PyAgT3IgImV4YW0qLmNyYW5reWNhbnVjay5jYSIsIGZvciB0aGF0DQo+IG1hdHRlcj8NCg0KTm90 aGluZyBpcyB3cm9uZyB3aXRoIHRob3NlIG90aGVyIGV4YW1wbGVzLiBIb3cgZG9lcyB0aGlzIHRl eHQgd29yayBmb3IgeW91Pw0KDQoiQSBjaGFyYWN0ZXIgc3RyaW5nIHJlcHJlc2VudGluZyBtdWx0 aXBsZSBkb21haW4gbmFtZSBsYWJlbHMgTUFZIGJlIGNvbmNhdGVuYXRlZCB0byB0aGUgZW5kIG9m IHRoZSBzZWFyY2ggcGF0dGVybiB0byBsaW1pdCB0aGUgc2NvcGUgb2YgdGhlIHNlYXJjaC4iDQoN Cj4gSSBzdXNwZWN0IHRoYXQgdGhlIHBhcmFncmFwaCBiZWdpbm5pbmcgd2l0aCAiUGFydGlhbCBt YXRjaGluZyBpcyBub3QNCj4gZmVhc2libGUgYWNyb3NzIGNvbWJpbmF0aW9ucyBvZiBVbmljb2Rl 4oCmIiBpcyBnb2luZyB0byBsZWFkIHRvDQo+IGNvbmZ1c2lvbi4gIEkgX3RoaW5rXyB3aGF0IGl0 IG1lYW5zIGlzIHRoYXQgImUqIiBkb2VzIG5vdCBtYXRjaCDDqQ0KPiAoaS5lLiBVKzAzMDEgQ09N QklOSU5HIEFDVVRFIEFDQ0VOVCBwbHVzIFUrMDA2NSwgYnV0IGFsc28gVSswMEU5KS4NCj4gQnV0 IGluIG15IHJlYWRpbmcsIHRoZSBwYXJhZ3JhcGggYXBwZWFycyB0byBzYXkgdGhhdCAiw6kqIiBj YW4ndCBtYXRjaA0KPiAiw6ljb2xlIi4gIElzIHRoYXQgd2hhdCdzIGludGVuZGVkPyAgKEkgcHJl c3VtZSBub3Qgc2luY2UgdHdvDQo+IHBhcmFncmFwaHMgbGF0ZXIgZGVzY3JpYmVzIGhvdyB0byBk byB0aGF0LikNCg0KTm8sIHRoYXQncyBub3Qgd2hhdCdzIGludGVuZGVkLiBDYW4geW91IHN1Z2dl c3QgcmVwbGFjZW1lbnQgdGV4dD8NCg0KPiBUaGUgcGFyYWdyYXBoIHN0YXJ0aW5nICJTZXJ2ZXJz IGNhbiBleHBlY3QgdG8gcmVjZWl2ZSBzZWFyY2ggcGF0dGVybnMNCj4gZnJvbSBjbGllbnRzIHRo YXTigKYiIGFwcGVhcnMgdG8gc2F5IHRoYXQgeW91IGNhbiBzZW5kIHlvdXIgcXVlcnkgdGVybQ0K PiBpbiBXaW4tMTI1MiBhbmQgZXhwZWN0IGEgbWF0Y2guICBJZiB0aGF0J3MgdGhlIGludGVudGlv biwgSSBzdWdnZXN0DQo+IHRoYXQgdGhpcyBwcm90b2NvbCBpcyBnb2luZyB0byBiZSBjb21wbGV0 ZWx5IHVzZWxlc3MgZm9yIGFueSBub24tQVNDSUkNCj4gc2VhcmNoLg0KDQpJIGRvbid0IGtub3cg YWJvdXQgImV4cGVjdCBhIG1hdGNoIiwgYnV0IEkgZG8gYmVsaWV2ZSB0aGF0IHNlcnZlcnMgd2ls bCByZWNlaXZlIGFsbCBraW5kcyBvZiBjcnVkIGZyb20gY2xpZW50cyAtIGFuZCB0aGV5IG5lZWQg dG8gZG8gc29tZXRoaW5nIHJlYXNvbmFibGUgd2l0aCB3aGF0ZXZlciB0aGV5IHJlY2VpdmUuIFRo aXMgaXMgb25lIHJlYXNvbiBzb21lIG9mIHVzIGFyZSBjb252ZXJnaW5nIG9uIHRoZSAic2ltcGxl IGJpbmFyeSBjb21wYXJpc29uIiBhcHByb2FjaCB0byBtYXRjaGluZy4NCg0KPiBUaGUgdHdvIHBh cmFncmFwaHMgb24gbmFtZS1yZWNvcmRzIHdpdGggYXNzb2NpYXRpb25zIHdpbGwgcHJvYmFibHkg bm90DQo+IGJlIGNvbXByZWhlbnNpYmxlIHRvIGFueW9uZSB3aG8gZG9lc24ndCBrbm93IHdoYXQg YSB2YXJpYW50IGlzLCBidXQgSQ0KPiBjYW4gbGl2ZSB3aXRoIHRoZW0uICBJdCdzIG5vdCBjbGVh ciB0byBtZSwgZnJvbSB0aGlzIHRleHQsIHdoZXRoZXINCj4gdGhlc2UgYXJlIGp1c3QgYW5vdGhl ciBwYXJ0IG9mIHRoZSBkb21haW4gYXJyYXksIG9yIHdoZXRoZXIgd2hhdCdzDQo+IHJldHVybmVk IGlzIGEgcmVmZXJlbmNlIChhIGxpbms/KS4gIFRoaXMgY291bGQgYmUgYmVjYXVzZSBJIGhhdmVu J3QNCj4gcmVhZCBjYXJlZnVsbHkgZW5vdWdoIHlldCwgc28gdGhpcyBtaWdodCBjb21lIGNsZWFy IGFzIEkgcmUtcmVhZC4NCg0KVGhpcyBpcyBwYXJ0IG9mIHRoZSB0ZXh0IHByb3ZpZGVkIGJ5IEpv aG4gS2xlbnNpbi4gSSdtIG9wZW4gdG8gc3VnZ2VzdGlvbnMgZm9yIGNsYXJpZmljYXRpb24uDQoN Cj4gSSBob3BlIHRoZXNlIGNvbW1lbnRzIGFyZSB1c2VmdWwuDQoNClRoZXkgYXJlIC0gdGhhbmsg eW91IQ0KDQpTY290dA0K From shollenbeck@verisign.com Mon Dec 2 06:57:01 2013 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 837A31AE025 for ; Mon, 2 Dec 2013 06:57:01 -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 x3rxnw4Pyz4T for ; Mon, 2 Dec 2013 06:56:59 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0EB1AE016 for ; Mon, 2 Dec 2013 06:56:57 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUpyft7SQkaTY6fHTyZUvsppNoCrIAs97@postini.com; Mon, 02 Dec 2013 06:56:56 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rB2Eus78031487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 2 Dec 2013 09:56:54 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 2 Dec 2013 09:56:54 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet , "weirds@ietf.org Group" Thread-Topic: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-01.txt Thread-Index: AQHO67EtpivJ0yV3206js6xdk19RH5pBBVsQ Date: Mon, 2 Dec 2013 14:56:53 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492F30D5@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20131127203517.29333.66519.idtracker@ietfa.amsl.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_831693C2CDA2E849A7D7A712B24E257F492F30D5BRN1WNEXMBX01vc_" MIME-Version: 1.0 Subject: Re: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-01.txt 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, 02 Dec 2013 14:57:01 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F492F30D5BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support adoption of this document. I would like to see some more text add= ed to address the limitations of bootstrapping, particularly in the context= of searches and search patterns where needed authoritative bits are missin= g. I'm willing to help with text as needed. Scott From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Marc Blanchet Sent: Wednesday, November 27, 2013 3:42 PM To: weirds@ietf.org Group Subject: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-ianaregi= stries-01.txt Hello, please find an updated version of the bootstrap using IANA registries. I h= ave discussed with IANA about the various registries, their implementation = and deployment. The text in IANA Considerations hopefully reflect the discu= ssion with IANA. However, the text is mine and has not been verified by IAN= A yet. Chairs, I would like to call for wg adoption of this document. Good reading while cooking the turkey (for some of you...) ;-) Marc. D=E9but du message r=E9exp=E9di=E9 : De: internet-drafts@ietf.org Objet: I-D Action: draft-blanchet-weirds-bootstrap-ianaregistries-01.txt Date: 27 novembre 2013 15:35:17 HNE =C0: i-d-announce@ietf.org R=E9pondre =E0: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Finding the Authoritative Registration Data (RD= AP) Service Author(s) : Marc Blanchet Filename : draft-blanchet-weirds-bootstrap-ianaregistries-= 01.txt Pages : 7 Date : 2013-11-27 Abstract: This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer queries for a requested scope, such as domain names, IP addresses or Autonomous System numbers, using data available in IANA registries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-blanchet-weirds-bootstrap-ianaregist= ries There's also a htmlized version available at: http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ianaregistries-0= 1 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-blanchet-weirds-bootstrap-ianaregi= stries-01 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_831693C2CDA2E849A7D7A712B24E257F492F30D5BRN1WNEXMBX01vc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I support adoption of this document. I wou= ld like to see some more text added to address the limitations of bootstrap= ping, particularly in the context of searches and search patterns where needed authoritative bits are missing. I’m willing to= help with text as needed.

 

Scott

 

From: weirds [= mailto:weirds-bounces@ietf.org] On Behalf Of Marc Blanchet
Sent: Wednesday, November 27, 2013 3:42 PM
To: weirds@ietf.org Group
Subject: [weirds] Fwd: I-D Action: draft-blanchet-weirds-bootstrap-i= anaregistries-01.txt

 

Hello,

 please find an updated version of the bootstra= p using IANA registries. I have discussed with IANA about the various regis= tries, their implementation and deployment. The text in IANA Considerations= hopefully reflect the discussion with IANA. However, the text is mine and has not been verified by IANA yet.&nbs= p;

 

Chairs, I would like to call for wg adoption of this= document.

 

Good reading while cooking the turkey (for some of y= ou...) ;-)

 

Marc.

 

D=E9but du message r=E9exp=E9di=E9 :



Objet: I-D Action: draft-blanchet-weirds-bootstrap-= ianaregistries-01.txt

Date: 27 novembre 2013 15:35:17 HNE

R=E9pondre =E0: internet-drafts@ietf.o= rg

 


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


       &n= bsp;  Title         &nb= sp; : Finding the Authoritative Registration Data (RDAP) Service
       &n= bsp;  Author(s)       : Marc Blan= chet
       &n= bsp;  Filename        : draf= t-blanchet-weirds-bootstrap-ianaregistries-01.txt
       &n= bsp;  Pages         &nb= sp; : 7
       &n= bsp;  Date         &nbs= p;  : 2013-11-27

Abstract:
  This document specifies a method to find which Registration Dat= a
  Access Protocol (RDAP) server is authoritative to answer querie= s for
  a requested scope, such as domain names, IP addresses or Autono= mous
  System numbers, using data available in IANA registries.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-blanchet-weirds-boo= tstrap-ianaregistries

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-blanchet-weirds-bootstrap-ia= naregistries-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-blanchet-wei= rds-bootstrap-ianaregistries-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet= -drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: htt= p://www.ietf.org/shadow.html
or ftp://ftp.ietf.org= /ietf/1shadow-sites.txt

 

--_000_831693C2CDA2E849A7D7A712B24E257F492F30D5BRN1WNEXMBX01vc_-- From superuser@gmail.com Mon Dec 2 19:27:51 2013 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 243781ADBD0 for ; Mon, 2 Dec 2013 19:27:51 -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 i-MH5DsyFdYO for ; Mon, 2 Dec 2013 19:27:49 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id BCADC1ADBCB for ; Mon, 2 Dec 2013 19:27:48 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so5888531wib.15 for ; Mon, 02 Dec 2013 19:27:45 -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:cc:content-type; bh=TpzcedkQeozBJUK9JKD23lm8Emp3a8F8H/eyJaK62PE=; b=foKQA5kvzrEK+bd4DvJV3VRB/SFZPCZpjtbmIO0oI0v3cJDXaPc/KBbT2tC0+fzPbF 3JLsigoYpknWpmpV4fzkie0l+UO9XQ7MbYMapx7cuhBbJSia1HfJJGso37jevLqT2gWI b4IRV28kkkuBZbBbyCpUjQGEfitN79V/q9nsflo0yr7Feqkofefe1KB7sQnFeo6YsTbm WNRriP2UBmAXbZSviyKriWakyQHMpy6VtgY2fzEv72RNoIo2x2IBzeeshJ4ePYWdu5k8 djevlkrQDtCs/vaZCSNGpIRhNmTmlH8dT33KnFoGncQH2tW9mbAuPzETqcCaxM9KMtD6 xDpw== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr464288wic.26.1386041265759; Mon, 02 Dec 2013 19:27:45 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 2 Dec 2013 19:27:45 -0800 (PST) Date: Mon, 2 Dec 2013 19:27:45 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c2679c4a2b3704ec98e15d Cc: John C Klensin , Peter Saint-Andre , "weirds@ietf.org" Subject: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 03 Dec 2013 03:27:51 -0000 --001a11c2679c4a2b3704ec98e15d Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott wrote: > > Having read this section and section 6, I really think that 3.2.3 > > should either say that it only supports ASCII, or else that we should > > say something more about the on-the-wire behaviour particularly for > > entity name searches. I think just hoping that both ends will do the > > right thing is an excellent way to reduce interoperability. Here is > > what I think should happen. > > > > An RDAP client wishing to perform an entity search by name MUST > > convert the search term into Unicode in UTF-8 encoding using > > whatever local rules are in effect. It SHOULD map fullwidth and > > halfwidth characters to their decomposition equivalents. It MAY > > perform any local case mapping deemed necessary. It SHOULD > > normalize the string using NFC. I think this is all I'd want to > > put in a precis profile for clients; it'd be based on > > FreeFormClass. It'd be cleaner to put this all in a profile. > > Failure to map fullwidth and halfwidth characters are more likely > > to lead to false negatives in searches. Failure to perform NFC > > on the string increases the probability that the server will > > perform NFC and match on something different than what was sent. > > > > An RDAP server receiving a search term string MUST treat the > > input as Unicode in UTF-8 encoding. If the search term is not > > valid UTF-8, the server MAY immediately stop processing and > > return an error. The server SHOULD perform NFC on the string; > > failure to do this is likely to lead to variability in seaches > > depending on the oringinating system. The server can then > > process the query. > > I'm still not sure of how we want to approach this. There are a small > number of people suggesting simple binary comparison, and a smaller number > suggesting something akin to the above. I may ask our chairs to consider a > consensus call for one approach or the other so we can put this to bed. > I'd like to avoid a formal consensus call without more feedback on the record first, or at least a (i.e., this) request for some. Could people please weigh in on preferred paths here and some reason(s) for your choices? I'll Cc PSA and John Klensin directly, again at the risk of being constructive. :-) -MSK --001a11c2679c4a2b3704ec98e15d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
> Having read this sec= tion and section 6, I really think that 3.2.3
> should either say that it only supports ASCII, or else that we should<= br> > say something more about the on-the-wire behaviour particularly for > entity name searches. =A0I think just hoping that both ends will do th= e
> right thing is an excellent way to reduce interoperability. =A0Here is=
> what I think should happen.
>
> =A0 =A0 =A0An RDAP client wishing to perform an entity search by name = MUST
> =A0 =A0 =A0convert the search term into Unicode in UTF-8 encoding usin= g
> =A0 =A0 =A0whatever local rules are in effect. =A0It SHOULD map fullwi= dth and
> =A0 =A0 =A0halfwidth characters to their decomposition equivalents. = =A0It MAY
> =A0 =A0 =A0perform any local case mapping deemed necessary. =A0It SHOU= LD
> =A0 =A0 =A0normalize the string using NFC. =A0I think this is all I= 9;d want to
> =A0 =A0 =A0put in a precis profile for clients; it'd be based on > =A0 =A0 =A0FreeFormClass. =A0It'd be cleaner to put this all in a = profile.
> =A0 =A0 =A0Failure to map fullwidth and halfwidth characters are more = likely
> =A0 =A0 =A0to lead to false negatives in searches. =A0Failure to perfo= rm NFC
> =A0 =A0 =A0on the string increases the probability that the server wil= l
> =A0 =A0 =A0perform NFC and match on something different than what was = sent.
>
> =A0 =A0 =A0An RDAP server receiving a search term string MUST treat th= e
> =A0 =A0 =A0input as Unicode in UTF-8 encoding. =A0If the search term i= s not
> =A0 =A0 =A0valid UTF-8, the server MAY immediately stop processing and=
> =A0 =A0 =A0return an error. =A0The server SHOULD perform NFC on the st= ring;
> =A0 =A0 =A0failure to do this is likely to lead to variability in seac= hes
> =A0 =A0 =A0depending on the oringinating system. =A0The server can the= n
> =A0 =A0 =A0process the query.

I'm still not sure of how we want to approach this. There a= re a small number of people suggesting simple binary comparison, and a smal= ler number suggesting something akin to the above. I may ask our chairs to = consider a consensus call for one approach or the other so we can put this = to bed.

I'd like to avoid a formal consensus c= all without more feedback on the record first, or at least a (i.e., this) r= equest for some.=A0 Could people please weigh in on preferred paths here an= d some reason(s) for your choices?

I'll Cc PSA and John Klensin directly, again at the risk= of being constructive.=A0 :-)

-MSK
--001a11c2679c4a2b3704ec98e15d-- From shollenbeck@verisign.com Tue Dec 3 03:58:25 2013 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 1B03B1AE118 for ; Tue, 3 Dec 2013 03:58:25 -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 xuAFlc14Aw5T for ; Tue, 3 Dec 2013 03:58:22 -0800 (PST) Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id BADD01AE0FC for ; Tue, 3 Dec 2013 03:58:19 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUp3HVXqS5hRkKaA83zXk0Q17RlZ+Lvso@postini.com; Tue, 03 Dec 2013 03:58:19 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rB3BwBDx000398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 06:58:11 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 3 Dec 2013 06:58:11 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" Thread-Topic: Opinions please (was Re: [weirds] comments on draft-ietf-weirds-rdap-query-08) Thread-Index: AQHO79ekk+BWFUCCKUSwmjP1bBAjCppCXSpw Date: Tue, 3 Dec 2013 11:58:10 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492F3D10@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: 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_831693C2CDA2E849A7D7A712B24E257F492F3D10BRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: John C Klensin , Peter Saint-Andre , "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 03 Dec 2013 11:58:25 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F492F3D10BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Murray S. Kucherawy [mailto:superuser@gmail.com] Sent: Monday, December 02, 2013 10:28 PM To: Hollenbeck, Scott Cc: Andrew Sullivan; weirds@ietf.org; John C Klensin; Peter Saint-Andre Subject: Opinions please (was Re: [weirds] comments on draft-ietf-weirds-rd= ap-query-08) On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott > wrote: > Having read this section and section 6, I really think that 3.2.3 > should either say that it only supports ASCII, or else that we should > say something more about the on-the-wire behaviour particularly for > entity name searches. I think just hoping that both ends will do the > right thing is an excellent way to reduce interoperability. Here is > what I think should happen. > > An RDAP client wishing to perform an entity search by name MUST > convert the search term into Unicode in UTF-8 encoding using > whatever local rules are in effect. It SHOULD map fullwidth and > halfwidth characters to their decomposition equivalents. It MAY > perform any local case mapping deemed necessary. It SHOULD > normalize the string using NFC. I think this is all I'd want to > put in a precis profile for clients; it'd be based on > FreeFormClass. It'd be cleaner to put this all in a profile. > Failure to map fullwidth and halfwidth characters are more likely > to lead to false negatives in searches. Failure to perform NFC > on the string increases the probability that the server will > perform NFC and match on something different than what was sent. > > An RDAP server receiving a search term string MUST treat the > input as Unicode in UTF-8 encoding. If the search term is not > valid UTF-8, the server MAY immediately stop processing and > return an error. The server SHOULD perform NFC on the string; > failure to do this is likely to lead to variability in seaches > depending on the oringinating system. The server can then > process the query. I'm still not sure of how we want to approach this. There are a small numbe= r of people suggesting simple binary comparison, and a smaller number sugge= sting something akin to the above. I may ask our chairs to consider a conse= nsus call for one approach or the other so we can put this to bed. I'd like to avoid a formal consensus call without more feedback on the reco= rd first, or at least a (i.e., this) request for some. Could people please= weigh in on preferred paths here and some reason(s) for your choices? I'll Cc PSA and John Klensin directly, again at the risk of being construct= ive. :-) [SAH] While I value John's and Peter's opinions, what we really need are mo= re _implementer_ opinions. Thanks for asking, Murray. Scott --_000_831693C2CDA2E849A7D7A712B24E257F492F3D10BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Murray S= . Kucherawy [mailto:superuser@gmail.com]
Sent: Monday, December 02, 2013 10:28 PM
To: Hollenbeck, Scott
Cc: Andrew Sullivan; weirds@ietf.org; John C Klensin; Peter Saint-An= dre
Subject: Opinions please (was Re: [weirds] comments on draft-ietf-we= irds-rdap-query-08)

 

On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott &l= t;shollenbeck= @verisign.com> wrote:

> Having read this section and section 6, I reall= y think that 3.2.3

> should either sa= y that it only supports ASCII, or else that we should
> say something more about the on-the-wire behaviour particularly for > entity name searches.  I think just hoping that both ends will do= the
> right thing is an excellent way to reduce interoperability.  Here= is
> what I think should happen.
>
>      An RDAP client wishing to perform an entity search= by name MUST
>      convert the search term into Unicode in UTF-8 enco= ding using
>      whatever local rules are in effect.  It SHOUL= D map fullwidth and
>      halfwidth characters to their decomposition equiva= lents.  It MAY
>      perform any local case mapping deemed necessary. &= nbsp;It SHOULD
>      normalize the string using NFC.  I think this= is all I'd want to
>      put in a precis profile for clients; it'd be based= on
>      FreeFormClass.  It'd be cleaner to put this a= ll in a profile.
>      Failure to map fullwidth and halfwidth characters = are more likely
>      to lead to false negatives in searches.  Fail= ure to perform NFC
>      on the string increases the probability that the s= erver will
>      perform NFC and match on something different than = what was sent.
>
>      An RDAP server receiving a search term string MUST= treat the
>      input as Unicode in UTF-8 encoding.  If the s= earch term is not
>      valid UTF-8, the server MAY immediately stop proce= ssing and
>      return an error.  The server SHOULD perform N= FC on the string;
>      failure to do this is likely to lead to variabilit= y in seaches
>      depending on the oringinating system.  The se= rver can then
>      process the query.

I'm still not sure of how we want to approach this. = There are a small number of people suggesting simple binary comparison, and= a smaller number suggesting something akin to the above. I may ask our cha= irs to consider a consensus call for one approach or the other so we can put this to bed.

 

I'd like to avoid a f= ormal consensus call without more feedback on the record first, or at least= a (i.e., this) request for some.  Could people please weigh in on pre= ferred paths here and some reason(s) for your choices?

I'll Cc PSA and John Klensin directly, again at the = risk of being constructive.  :-)

[SAH] While I value John’s and Peter= 217;s opinions, what we really need are more _implementer_ opinions.= Thanks for asking, Murray.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F492F3D10BRN1WNEXMBX01vc_-- From zhoulinlin@cnnic.cn Tue Dec 3 18:16:22 2013 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 B62961ADF33 for ; Tue, 3 Dec 2013 18:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 eEAPYm0MnDkp for ; Tue, 3 Dec 2013 18:16:20 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 90B4A1AE01D for ; Tue, 3 Dec 2013 18:16:18 -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; Wed, 04 Dec 2013 10:16:13 +0800 From: "Linlin Zhou" To: "'John R Levine'" , "'Hollenbeck, Scott'" References: <831693C2CDA2E849A7D7A712B24E257F492EDEE6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131125180112.55423.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F492EF0B6@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <5294903A.8060609@gmail.com> <831693C2CDA2E849A7D7A712B24E257F492EF110@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F492F2C57@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: Date: Wed, 4 Dec 2013 10:25:09 +0800 Message-ID: <01da01cef098$0dc73f60$2955be20$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac7vaps3duy+Fi/tTMe9aexxH0++QQBLMzSA Content-Language: zh-cn Cc: weirds@ietf.org Subject: Re: [weirds] DNS Bootstrapping revisited 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, 04 Dec 2013 02:16:23 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of John R Levine > Sent: Monday, December 02, 2013 10:27 PM > To: Hollenbeck, Scott > Cc: weirds@ietf.org > Subject: Re: [weirds] DNS Bootstrapping revisited > > > Can you clarify "types of queries"? Are you talking about something other > than names queries vs. number queries? > > > > [SAH] No, I'm specifically referring to bootstrapping a search for a domain > pattern like "example*", or an entity search with no association to an earlier > query. There are some patterns for which it is impossible to determine a server > identity or a clue that can be used to associate a query with a server. Those > limitations need to be acknowledged. > > Completely agree. I understand (in general principle) how one might > bootstrap individual domain names at the TLD level, IP addresses, and ASNs. > I don't think there is any plausible way to bootstrap anything else. > +1 Domain name, IP and ASNs are 3 query types that could be possibly bootstrapped. > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From edainow@afilias.info Wed Dec 4 12:26:23 2013 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 3740A1AE0B8 for ; Wed, 4 Dec 2013 12:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 3jd5K2yglCpc for ; Wed, 4 Dec 2013 12:26:19 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3E1AD8F5 for ; Wed, 4 Dec 2013 12:26:18 -0800 (PST) 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 1VoJ1T-0001PZ-4U for weirds@ietf.org; Wed, 04 Dec 2013 20:26:15 +0000 Received: from mail-ie0-f178.google.com ([209.85.223.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VoJ1T-0001Yy-3u for weirds@ietf.org; Wed, 04 Dec 2013 20:26:15 +0000 Received: by mail-ie0-f178.google.com with SMTP id lx4so27044069iec.23 for ; Wed, 04 Dec 2013 12:26:09 -0800 (PST) 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=5uwAuLKqx1YRSQhJy/9czQHgAtPtdTYSL2OypqPy/o8=; b=e3V9JYJLHNKVlRnNjwEBK/v9NwL9cuvZXh0ji832eB0lAAEbtmj5yfd196g1WhPKJl ZHJeC6PAGKxb4XTFmImhhON3xuKDZKq2l9A6+vpW6NbbswnhTNHH1yw8dKoqpYJi5etm vr/MGbMeecv+4xOdbJTnNpx3+3gryvtsjDbELJkSTqPEJhg2KYG6orY1ZmXVYYoZ3Ews NHq/5GirvVuc2fF020DYQ9BW/31CzeuDJCZehk1LVgwFuf0X+JagHYHU8mAYiHimOSnu asrd1r/C2EbUD5kgrnZPCXK4JuYkvDUrwLhIArZtaFW7FHxWjjdiOGh/sXVmWLzgJOwA JSAA== X-Gm-Message-State: ALoCoQm7BEOD16rZMr+CM0l+7luyHkS9z9fZvpCNm3deP09mNOY0BxutC+51N3xp52kCl6Kts8dBISDif4f4YhVuAl4NXJXvJCs01wbA5BALpqdxOs9DK8ExD4Aqhb0N/gDqXotSECmB X-Received: by 10.50.117.3 with SMTP id ka3mr2709175igb.15.1386188769794; Wed, 04 Dec 2013 12:26:09 -0800 (PST) X-Received: by 10.50.117.3 with SMTP id ka3mr2709165igb.15.1386188769682; Wed, 04 Dec 2013 12:26:09 -0800 (PST) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id f5sm6107422igc.4.2013.12.04.12.26.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 04 Dec 2013 12:26:08 -0800 (PST) Message-ID: <529F8FDE.5060309@afilias.info> Date: Wed, 04 Dec 2013 15:26:06 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Hollenbeck, Scott" , "Murray S. Kucherawy" References: <831693C2CDA2E849A7D7A712B24E257F492F3D10@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492F3D10@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary="------------070003000503050401060007" Cc: John C Klensin , "weirds@ietf.org" , Peter Saint-Andre Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 04 Dec 2013 20:26:23 -0000 This is a multi-part message in MIME format. --------------070003000503050401060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/3/2013 6:58 AM, Hollenbeck, Scott wrote: > > *From:*Murray S. Kucherawy [mailto:superuser@gmail.com] > *Sent:* Monday, December 02, 2013 10:28 PM > *To:* Hollenbeck, Scott > *Cc:* Andrew Sullivan; weirds@ietf.org; John C Klensin; Peter Saint-Andre > *Subject:* Opinions please (was Re: [weirds] comments on > draft-ietf-weirds-rdap-query-08) > > On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott > > wrote: > > > Having read this section and section 6, I really think that 3.2.3 > > > should either say that it only supports ASCII, or else that we > should > > say something more about the on-the-wire behaviour particularly for > > entity name searches. I think just hoping that both ends will > do the > > right thing is an excellent way to reduce interoperability. Here is > > what I think should happen. > > > > An RDAP client wishing to perform an entity search by name MUST > > convert the search term into Unicode in UTF-8 encoding using > > whatever local rules are in effect. It SHOULD map > fullwidth and > > halfwidth characters to their decomposition equivalents. > It MAY > > perform any local case mapping deemed necessary. It SHOULD > > normalize the string using NFC. I think this is all I'd > want to > > put in a precis profile for clients; it'd be based on > > FreeFormClass. It'd be cleaner to put this all in a profile. > > Failure to map fullwidth and halfwidth characters are more > likely > > to lead to false negatives in searches. Failure to perform NFC > > on the string increases the probability that the server will > > perform NFC and match on something different than what was > sent. > > > > An RDAP server receiving a search term string MUST treat the > > input as Unicode in UTF-8 encoding. If the search term is not > > valid UTF-8, the server MAY immediately stop processing and > > return an error. The server SHOULD perform NFC on the string; > > failure to do this is likely to lead to variability in seaches > > depending on the oringinating system. The server can then > > process the query. > > I'm still not sure of how we want to approach this. There are a > small number of people suggesting simple binary comparison, and a > smaller number suggesting something akin to the above. I may ask > our chairs to consider a consensus call for one approach or the > other so we can put this to bed. > > I'd like to avoid a formal consensus call without more feedback on the > record first, or at least a (i.e., this) request for some. Could > people please weigh in on preferred paths here and some reason(s) for > your choices? > > I'll Cc PSA and John Klensin directly, again at the risk of being > constructive. :-) > > [SAH] While I value John's and Peter's opinions, what we really need > are more _/implementer/_ opinions. Thanks for asking, Murray. > > Scott > > I implemented Unicode search on the server side. I agree with Andrew's proposal, except for a few comments posted previously. Without a specification with sufficient precision such as this, there is no reliability in any search or lookup results. As per an earlier example, if you lookup a domain and get no result, you don't really know if the domain is not registered or if the lookup failed because of normalization differences between the lookup/search name and the data being searched. I have a few questions/comments about one other issue. The client SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Isn't what is needed here is to map fullwidth characters to their Compatibility equivalents, not Decomposition? For example, fullwidth A, which is Unicode u'\uff21', Hex UTF-8 '\xef\xbc\xa1' is normalized as: NFC A u'\uff21' '\xef\xbc\xa1' NFKC A u'A' 'A' NFD A u'\uff21' '\xef\xbc\xa1' NFKD A u'A' 'A' The Compatibility forms NFKC, NFKD map the fullwidth to halfwidth. So can we say the client should apply NFKC or NFKD to normalize fullwidth characters to Compatibility form. I'm not sure all clients know enough about their locale to determine that they should perform fullwidth mapping. This can be generalized and simplified for the client by shifting it to the server. The server rule would be to first normalize the search/lookup using NFKC or NFKD and then normalize the result to NFC before doing the lookup against data that is in NFC. -Ernie --------------070003000503050401060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 12/3/2013 6:58 AM, Hollenbeck, Scott wrote:

From: Murray S. Kucherawy [mailto:superuser@gmail.com]
Sent: Monday, December 02, 2013 10:28 PM
To: Hollenbeck, Scott
Cc: Andrew Sullivan; weirds@ietf.org; John C Klensin; Peter Saint-Andre
Subject: Opinions please (was Re: [weirds] comments on draft-ietf-weirds-rdap-query-08)

 

On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

> Having read this section and section 6, I really think that 3.2.3

> should either say that it only supports ASCII, or else that we should
> say something more about the on-the-wire behaviour particularly for
> entity name searches.  I think just hoping that both ends will do the
> right thing is an excellent way to reduce interoperability.  Here is
> what I think should happen.
>
>      An RDAP client wishing to perform an entity search by name MUST
>      convert the search term into Unicode in UTF-8 encoding using
>      whatever local rules are in effect.  It SHOULD map fullwidth and
>      halfwidth characters to their decomposition equivalents.  It MAY
>      perform any local case mapping deemed necessary.  It SHOULD
>      normalize the string using NFC.  I think this is all I'd want to
>      put in a precis profile for clients; it'd be based on
>      FreeFormClass.  It'd be cleaner to put this all in a profile.
>      Failure to map fullwidth and halfwidth characters are more likely
>      to lead to false negatives in searches.  Failure to perform NFC
>      on the string increases the probability that the server will
>      perform NFC and match on something different than what was sent.
>
>      An RDAP server receiving a search term string MUST treat the
>      input as Unicode in UTF-8 encoding.  If the search term is not
>      valid UTF-8, the server MAY immediately stop processing and
>      return an error.  The server SHOULD perform NFC on the string;
>      failure to do this is likely to lead to variability in seaches
>      depending on the oringinating system.  The server can then
>      process the query.

I'm still not sure of how we want to approach this. There are a small number of people suggesting simple binary comparison, and a smaller number suggesting something akin to the above. I may ask our chairs to consider a consensus call for one approach or the other so we can put this to bed.

 

I'd like to avoid a formal consensus call without more feedback on the record first, or at least a (i.e., this) request for some.  Could people please weigh in on preferred paths here and some reason(s) for your choices?

I'll Cc PSA and John Klensin directly, again at the risk of being constructive.  :-)

[SAH] While I value John’s and Peter’s opinions, what we really need are more _implementer_ opinions. Thanks for asking, Murray.

 

Scott


I implemented Unicode search on the server side. I agree with Andrew's proposal, except for a few comments posted previously. Without a specification with sufficient precision such as this, there is no reliability in any search or lookup results. As per an earlier example, if you lookup a domain and get no result, you don't really know if the domain is not registered or if the lookup failed because of normalization differences between the lookup/search name and the data being searched.

I have a few questions/comments about one other issue.
      The client SHOULD map fullwidth and halfwidth characters to their decomposition equivalents.

Isn't what is needed here is to map fullwidth characters to their Compatibility equivalents, not Decomposition?

For example, fullwidth A, which is Unicode u'\uff21', Hex UTF-8 '\xef\xbc\xa1' is normalized as:
   NFC  Ａ u'\uff21'  '\xef\xbc\xa1'
   NFKC A u'A'  'A'
   NFD  Ａ u'\uff21'  '\xef\xbc\xa1'
   NFKD A u'A'  'A'

The Compatibility forms NFKC, NFKD map the fullwidth to halfwidth. So can we say the client should apply NFKC or NFKD to normalize fullwidth characters to Compatibility form.

I'm not sure all clients know enough about their locale to determine that they should perform fullwidth mapping. This can be generalized and simplified for the client by shifting it to the server. The server rule would be to first normalize the search/lookup using NFKC or NFKD and then normalize the result to NFC before doing the lookup against data that is in NFC.

-Ernie



--------------070003000503050401060007-- From stpeter@stpeter.im Wed Dec 4 12:58:57 2013 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 A87931ACCDC for ; Wed, 4 Dec 2013 12:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 KhZKDkyRfUmX for ; Wed, 4 Dec 2013 12:58:55 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0D01ACC88 for ; Wed, 4 Dec 2013 12:58:55 -0800 (PST) Received: from sjc-vpn2-300.cisco.com (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95ACC40332; Wed, 4 Dec 2013 13:58:50 -0700 (MST) Message-ID: <529F9788.7090309@stpeter.im> Date: Wed, 04 Dec 2013 13:58:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ernie Dainow , "Hollenbeck, Scott" , "Murray S. Kucherawy" References: <831693C2CDA2E849A7D7A712B24E257F492F3D10@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <529F8FDE.5060309@afilias.info> In-Reply-To: <529F8FDE.5060309@afilias.info> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 04 Dec 2013 13:02:49 -0800 Cc: John C Klensin , "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 04 Dec 2013 20:58:57 -0000 On 12/4/13 1:26 PM, Ernie Dainow wrote: > > On 12/3/2013 6:58 AM, Hollenbeck, Scott wrote: >> >> *From:*Murray S. Kucherawy [mailto:superuser@gmail.com] >> *Sent:* Monday, December 02, 2013 10:28 PM >> *To:* Hollenbeck, Scott >> *Cc:* Andrew Sullivan; weirds@ietf.org; John C Klensin; Peter Saint-Andre >> *Subject:* Opinions please (was Re: [weirds] comments on >> draft-ietf-weirds-rdap-query-08) >> >> >> >> On Mon, Dec 2, 2013 at 6:40 AM, Hollenbeck, Scott >> > wrote: >> >> > Having read this section and section 6, I really think that 3.2.3 >> >> > should either say that it only supports ASCII, or else that we >> should >> > say something more about the on-the-wire behaviour particularly for >> > entity name searches. I think just hoping that both ends will >> do the >> > right thing is an excellent way to reduce interoperability. Here is >> > what I think should happen. >> > >> > An RDAP client wishing to perform an entity search by name MUST >> > convert the search term into Unicode in UTF-8 encoding using >> > whatever local rules are in effect. It SHOULD map >> fullwidth and >> > halfwidth characters to their decomposition equivalents. >> It MAY >> > perform any local case mapping deemed necessary. It SHOULD >> > normalize the string using NFC. I think this is all I'd >> want to >> > put in a precis profile for clients; it'd be based on >> > FreeFormClass. It'd be cleaner to put this all in a profile. >> > Failure to map fullwidth and halfwidth characters are more >> likely >> > to lead to false negatives in searches. Failure to perform NFC >> > on the string increases the probability that the server will >> > perform NFC and match on something different than what was >> sent. >> > >> > An RDAP server receiving a search term string MUST treat the >> > input as Unicode in UTF-8 encoding. If the search term is not >> > valid UTF-8, the server MAY immediately stop processing and >> > return an error. The server SHOULD perform NFC on the string; >> > failure to do this is likely to lead to variability in seaches >> > depending on the oringinating system. The server can then >> > process the query. >> >> I'm still not sure of how we want to approach this. There are a >> small number of people suggesting simple binary comparison, and a >> smaller number suggesting something akin to the above. I may ask >> our chairs to consider a consensus call for one approach or the >> other so we can put this to bed. >> >> >> >> I'd like to avoid a formal consensus call without more feedback on the >> record first, or at least a (i.e., this) request for some. Could >> people please weigh in on preferred paths here and some reason(s) for >> your choices? >> >> I'll Cc PSA and John Klensin directly, again at the risk of being >> constructive. :-) >> >> [SAH] While I value John’s and Peter’s opinions, what we really need >> are more _/implementer/_ opinions. Thanks for asking, Murray. >> >> >> >> Scott >> >> > I implemented Unicode search on the server side. I agree with Andrew's > proposal, except for a few comments posted previously. Without a > specification with sufficient precision such as this, there is no > reliability in any search or lookup results. As per an earlier example, > if you lookup a domain and get no result, you don't really know if the > domain is not registered or if the lookup failed because of > normalization differences between the lookup/search name and the data > being searched. > > I have a few questions/comments about one other issue. > The client SHOULD map fullwidth and halfwidth characters to their > decomposition equivalents. > > Isn't what is needed here is to map fullwidth characters to their > Compatibility equivalents, not Decomposition? RFC 5985 uses the term "decomposition mapping", for instance: Fullwidth and halfwidth characters (those defined with Decomposition Types and ) are mapped to their decomposition mappings as shown in the Unicode character database. > > For example, fullwidth A, which is Unicode u'\uff21', Hex UTF-8 > '\xef\xbc\xa1' is normalized as: > NFC Ａ u'\uff21' '\xef\xbc\xa1' > NFKC A u'A' 'A' > NFD Ａ u'\uff21' '\xef\xbc\xa1' > NFKD A u'A' 'A' > > The Compatibility forms NFKC, NFKD map the fullwidth to halfwidth. I think they map fullwidth (i.e., ) and halfwidth (i.e., ) to their decomposition mappings. For instance, in the Unicode Character Database we find: 3000;IDEOGRAPHIC SPACE;Zs;0;WS; 0020;;;;N;;;;; and FF61;HALFWIDTH IDEOGRAPHIC FULL STOP;Po;0;ON; 3002;;;;N;HALFWIDTH IDEOGRAPHIC PERIOD;;;; > So > can we say the client should apply NFKC or NFKD to normalize fullwidth > characters to Compatibility form. Maybe. > I'm not sure all clients know enough about their locale to determine > that they should perform fullwidth mapping. I'm not sure if fullwidth and halfwidth mapping is locale-specific. > This can be generalized and > simplified for the client by shifting it to the server. I think that's a good plan, especially if we think that some clients won't be very advanced about these matters anyway. > The server rule > would be to first normalize the search/lookup using NFKC or NFKD and > then normalize the result to NFC before doing the lookup against data > that is in NFC. To repeat Pete Resnick's question from Vancouver, are we more concerned about false positives or false negatives? That will help us determine what we think clients and servers need to do. Peter -- Peter Saint-Andre https://stpeter.im/ From prvs=0043092b15=johnl@iecc.com Wed Dec 4 13:59:07 2013 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 6F4031AD948 for ; Wed, 4 Dec 2013 13:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 HOTcQig0BS4M for ; Wed, 4 Dec 2013 13:59:05 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2611AD8F5 for ; Wed, 4 Dec 2013 13:59:04 -0800 (PST) Received: (qmail 15129 invoked from network); 4 Dec 2013 21:59:00 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 4 Dec 2013 21:59:00 -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=529fa5a4.xn--i8sz2z.k1310; i=johnl@user.iecc.com; bh=/d5SEaeLek7FQvq9ECofD7gJiX0/iRpSpI/ijHa4lEs=; b=1WVsdxlltlQRs+XZmn/9UfYnnq9YsUFggEM5JhIZ9m8QojGy8Og0OHCP2zJV6hPpRUMf8v3v/g3OpORvgezCg537Oi5hOasNgRwTZpjTBdytvRZQF1mSbSL/xwSJMJSDYcBl2qIpkjL1FBVQ2nE6panRCR2k1eKfeLoj98MWGpwjx+jNWMIlnHX1cFGv57qS+fkJA/Lle2cSThYs54r9DagJE6qxAmaJhhms6CaF8BqKwL8BVgP1IJXPPIFcQqQN 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=529fa5a4.xn--i8sz2z.k1310; olt=johnl@user.iecc.com; bh=/d5SEaeLek7FQvq9ECofD7gJiX0/iRpSpI/ijHa4lEs=; b=J8d0Et3THEmej/2DBVIFPZ77vXY+Lo0JiMiJlaT4kHALQJe5h8qOAPrz6MnD8+cif1mZb5LiYsqR1R3UEEqDN0wb8zo8uVYPD0ya4e2peTrylQ/yfrHKxCB2cXVAmZJHZT41fB7Ivt3WgJQnyx/gTIWyt9Bs7S6XW/t4qRbN+wOvmVYmLVHTFEcVC5OnYjEkPDxkRG7L5Gww8r5i306dSUpb2aQNCTn4BBkxlfvVcliTjN8q+KhVaAsS/zT94X9T Date: 4 Dec 2013 21:58:38 -0000 Message-ID: <20131204215838.14194.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <529F9788.7090309@stpeter.im> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: stpeter@stpeter.im Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 04 Dec 2013 21:59:08 -0000 >To repeat Pete Resnick's question from Vancouver, are we more concerned >about false positives or false negatives? That will help us determine >what we think clients and servers need to do. I would think false negatives. Given the extreme vagueness about exactly what a search does, it's most likely just to be displayed to people who will pick some of the answers and do something with them. It's certainly easier to skip an uninteresting answer you do see than to select an interesting answer you don't. -- Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From shollenbeck@verisign.com Thu Dec 5 06:50:33 2013 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 B88CA1AE037 for ; Thu, 5 Dec 2013 06:50:33 -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 xiWewsp3pHdz for ; Thu, 5 Dec 2013 06:50:32 -0800 (PST) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC2E1AE014 for ; Thu, 5 Dec 2013 06:50:29 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUqCSsIeH8yebnW4H067wjSzSqdDPZAGZ@postini.com; Thu, 05 Dec 2013 06:50:29 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 rB5EoNg1006066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Dec 2013 09:50:24 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 5 Dec 2013 09:50:23 -0500 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) Thread-Index: AQHO8TwRmTC12vPAAkunDfsJbtmA/ppFr07w Date: Thu, 5 Dec 2013 14:50:23 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492F70AC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <529F9788.7090309@stpeter.im> <20131204215838.14194.qmail@joyce.lan> In-Reply-To: <20131204215838.14194.qmail@joyce.lan> 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 Cc: "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 05 Dec 2013 14:50:33 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of John Levine > Sent: Wednesday, December 04, 2013 4:59 PM > To: weirds@ietf.org > Cc: stpeter@stpeter.im > Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf- > weirds-rdap-query-08) >=20 > >To repeat Pete Resnick's question from Vancouver, are we more > concerned > >about false positives or false negatives? That will help us determine > >what we think clients and servers need to do. >=20 > I would think false negatives. Given the extreme vagueness about > exactly what a search does, it's most likely just to be displayed to > people who will pick some of the answers and do something with them. > It's certainly easier to skip an uninteresting answer you do see than > to select an interesting answer you don't. I agree. I can skip over returned results that don't look interesting to me= . I can't do anything if I don't see them at all. Scott From edainow@afilias.info Thu Dec 5 07:30:11 2013 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 D051B1AE066 for ; Thu, 5 Dec 2013 07:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 0Ddmwer5of79 for ; Thu, 5 Dec 2013 07:30:10 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECC41AE059 for ; Thu, 5 Dec 2013 07:30:10 -0800 (PST) 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 1VoasQ-0001Ms-5F for weirds@ietf.org; Thu, 05 Dec 2013 15:30:06 +0000 Received: from mail-ee0-f41.google.com ([74.125.83.41]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VoasQ-0004sf-4m for weirds@ietf.org; Thu, 05 Dec 2013 15:30:06 +0000 Received: by mail-ee0-f41.google.com with SMTP id t10so3396741eei.14 for ; Thu, 05 Dec 2013 07:30:00 -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=iRLP4WU31GaOhHDq3MLVRDtGzviw/VAfuaEEvwE4Gio=; b=F3urNv4D9XOKBMcFh8j4iQPQwFNRb18BuQ6ZDvHeAuAjmVex1Ep9s8JAA4kpSEukCn v1ihlBqlaFgf6rIJkboV6Y3g1/gN6VvY/AfwROO2DKjTasQqRdP2h6axtrT5i4yrpoMm l+gkg4HZfkIQuFXZ7fs9cXfMrW5RFlwGDlv76cqLWW5KS5uWXZaA6Th7KJhls7cp9SQq ot7vuFCITil2Kxx3xDilZa150HZvcx8iGy+8JqRL8nC09QZ3/78mnqo2OQwDMfPGqzOx NesHYmcri6o1YNRRCaESZ9PrLH7NRBxFIqIC03+9Ir4/Wmga/Nqg3X01RYpeCdmsLx4Z M7mw== X-Gm-Message-State: ALoCoQmjuz62XIM/Z27QAW8B17wbJS0GEu9hMQgqBUOi6dxJeDIhshs7Y58oyr2nPRZGQ/eBYpccit5SUKEy1F0V14MG6GUnUZrdGeNE/Z8D+EBdiHbRlDX3pzPrf9EdVw3W7/F7knLP X-Received: by 10.14.108.6 with SMTP id p6mr21761018eeg.31.1386257400460; Thu, 05 Dec 2013 07:30:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.108.6 with SMTP id p6mr21761012eeg.31.1386257400356; Thu, 05 Dec 2013 07:30:00 -0800 (PST) Received: by 10.14.201.8 with HTTP; Thu, 5 Dec 2013 07:29:59 -0800 (PST) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492F70AC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <529F9788.7090309@stpeter.im> <20131204215838.14194.qmail@joyce.lan> <831693C2CDA2E849A7D7A712B24E257F492F70AC@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Thu, 5 Dec 2013 10:29:59 -0500 Message-ID: From: Ernie Dainow To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=001a11c2926eea71ff04eccb3312 Cc: John Levine , "weirds@ietf.org" , "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 05 Dec 2013 15:30:12 -0000 --001a11c2926eea71ff04eccb3312 Content-Type: text/plain; charset=ISO-8859-1 If the server is required to do normalization as proposed, then there should be no false positives and no false negatives. That's kind of the point of normalization. This is certainly true for a name lookup (or else IDNA has a major fault), I am pretty sure it is also true for a search of the form XXX*. Does anyone have a counter case of a false positive or a false negative for either lookup or search? -Ernie On Thu, Dec 5, 2013 at 9:50 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of John Levine > > Sent: Wednesday, December 04, 2013 4:59 PM > > To: weirds@ietf.org > > Cc: stpeter@stpeter.im > > Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf- > > weirds-rdap-query-08) > > > > >To repeat Pete Resnick's question from Vancouver, are we more > > concerned > > >about false positives or false negatives? That will help us determine > > >what we think clients and servers need to do. > > > > I would think false negatives. Given the extreme vagueness about > > exactly what a search does, it's most likely just to be displayed to > > people who will pick some of the answers and do something with them. > > It's certainly easier to skip an uninteresting answer you do see than > > to select an interesting answer you don't. > > I agree. I can skip over returned results that don't look interesting to > me. I can't do anything if I don't see them at all. > > Scott > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --001a11c2926eea71ff04eccb3312 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If the server is required to do normalization as prop= osed, then there should be no false positives and no false negatives. That&= #39;s kind of the point of normalization. This is certainly true for a name= lookup (or else IDNA has a major fault), I am pretty sure it is also true = for a search of the form XXX*. Does anyone have a counter case of a=A0false= positive or a false negative=A0for either lookup or search?

-Ernie


On Thu, Dec 5, 2013 at 9:50 AM, Hollenbeck, Scott = <shollenbeck@verisign.com> wrote:
> -----Original Message= -----
> From: weirds [mailto:weirds= -bounces@ietf.org] On Behalf Of John Levine
> Sent: Wednesday, December 04, 2013 4:59 PM
> To: weirds@ietf.org
> Cc: stpeter@stpeter.im
> Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-=
> weirds-rdap-query-08)
>
> >To repeat Pete Resnick's question from Vancouver, are we more<= br> > concerned
> >about false positives or false negatives? That will help us determ= ine
> >what we think clients and servers need to do.
>
> I would think false negatives. =A0Given the extreme vagueness about > exactly what a search does, it's most likely just to be displayed = to
> people who will pick some of the answers and do something with them. > It's certainly easier to skip an uninteresting answer you do see t= han
> to select an interesting answer you don't.

I agree. I can skip over returned results that don't look interes= ting to me. I can't do anything if I don't see them at all.

Scott
_____________________= __________________________
weirds mailing list
weirds@ietf.org
= https://www.ietf.org/mailman/listinfo/weirds

--001a11c2926eea71ff04eccb3312-- From superuser@gmail.com Thu Dec 5 12:12:02 2013 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 20C001AE135 for ; Thu, 5 Dec 2013 12:12:02 -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 qs6ZzA5hmowC for ; Thu, 5 Dec 2013 12:11:56 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1F21AD947 for ; Thu, 5 Dec 2013 12:11:56 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id ca18so243077wib.4 for ; Thu, 05 Dec 2013 12:11:52 -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=Y3WCxIzxTSFvqE5BskH/6k4VSnvjcLV8erVXI/L0azc=; b=vnSFEkAWv9uH1mXNYunGenIKKzUEuv3pOMr4b3IkjYbo/yIOs/xljrnCcwqULJs+ae kgXSpn2Xwv0rQilx6KPnxvIWxY6uy0k9vi2x741b6n4QUCOoYHP9HfUPHI2GsC5T+REG qcbiUo2Mm/tgw8s3BG6MLm7UBNO2F3WHnEOCcR7hKKDdkfc9U8pWkcIsc5L8l7fOGt56 8B3lxtJAHTO1U61XJpSYvjvwRkdAmpN/fbegfB6GCco9MOrzRcNOtbWrkHEeIlMh7qRq +488RNQSGXW+LLkI9T4upTu5xeRWCiaspF74sAbSC7niINlkkMYTy8sVE3PXKZRIXwKn NzGg== MIME-Version: 1.0 X-Received: by 10.194.94.167 with SMTP id dd7mr19148626wjb.43.1386274312449; Thu, 05 Dec 2013 12:11:52 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 5 Dec 2013 12:11:52 -0800 (PST) Date: Thu, 5 Dec 2013 12:11:52 -0800 Message-ID: From: "Murray S. Kucherawy" To: "weirds@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb03c46f473ec04eccf2339 Subject: [weirds] Call for adoption: draft-blanchet-weirds-bootstrap-ianaregistries 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, 05 Dec 2013 20:12:02 -0000 --047d7bb03c46f473ec04eccf2339 Content-Type: text/plain; charset=ISO-8859-1 This note starts a two-week call for adoption of the above draft. If there are no sustained objections, this will be our document to satisfy the bootstrapping milestone. If you have already expressed support on that other thread, you don't need to do so here. Otherwise, or if you object, please say so in reply to this message prior to December 20th. -MSK, WEIRDS co-chair --047d7bb03c46f473ec04eccf2339 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This note starts a two-week call for adoption of= the above draft.=A0 If there are no sustained objections, this will be our= document to satisfy the bootstrapping milestone.

If you have = already expressed support on that other thread, you don't need to do so= here.=A0 Otherwise, or if you object, please say so in reply to this messa= ge prior to December 20th.

-MSK, WEIRDS co-chair

--047d7bb03c46f473ec04eccf2339-- From prvs=0046476b60=johnl@iecc.com Sat Dec 7 15:18:22 2013 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 52DCA1AE44F for ; Sat, 7 Dec 2013 15:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.106 X-Spam-Level: X-Spam-Status: No, score=0.106 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 yq7lXDmHmJ5j for ; Sat, 7 Dec 2013 15:18:21 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E9D841AE0DD for ; Sat, 7 Dec 2013 15:18:20 -0800 (PST) Received: (qmail 4697 invoked from network); 7 Dec 2013 23:18:16 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 7 Dec 2013 23:18:16 -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=52a3acb8.xn--3zv.k1310; i=johnl@user.iecc.com; bh=9Osgp8+BOUiPuzaPWH/rOfuhpRcpSwxfawZer8YCbHY=; b=Ovu63T5smOLt9eXcOVubO1doM/1+NL0Ur5282vVYnn1Zb9Jkn8tn8ugZE2l0QpELJBz4xgCXtDUHgUUt/6sFOVsb8/9JHP3xqOvFrnbQyYV3cXGL/YgRuhP0U/9hKr9HbmIxhwO+L/iGfue4hWPbH2+lDs9UgRQwjJ6Dwe4nBjZflWg+1UbIdZ2bvcHMotmvsG3+tahMGzDSob1uX4d43cQkZ6qXR6jBIQynUUwFwF4ItsiQJrU39Inq0vx59K3P 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=52a3acb8.xn--3zv.k1310; olt=johnl@user.iecc.com; bh=9Osgp8+BOUiPuzaPWH/rOfuhpRcpSwxfawZer8YCbHY=; b=P4SgqfmXzYrFL22RBBJarysorziLF61RxvFDmttFv7ULpS3wME5hflJgn1BM4dUMoFOuZgBGFGafBDe0VxWyt2ewuo9J4hehxHHm+PyYvBkXyRKheMhYQ3V5qgZhrcxQVt2IZSnorbk7yqOhrhZTUXwD1LtsViiokIJN8DjApwvLJKYb3kDQOxytQg152qG2mQpCLej8A47yv63ZvNvNFS7I7VAWBDtrQ67JlaAJmiMVFBMFxpvVm6ffTDRcrQt2 Date: 7 Dec 2013 23:17:54 -0000 Message-ID: <20131207231754.82862.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 Subject: Re: [weirds] Call for adoption: draft-blanchet-weirds-bootstrap-ianaregistries 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: Sat, 07 Dec 2013 23:18:22 -0000 >This note starts a two-week call for adoption of the above draft. If there >are no sustained objections, this will be our document to satisfy the >bootstrapping milestone. I think we should adopt it, keeping in mind that adopting it doesn't necessarily mean that we will publish it in anything like its current form. We still have some big open questions, like whether name bootstrap only handles TLDs or is intended to handle arbitrary domain names. R's, John From andy@arin.net Mon Dec 9 04:57:14 2013 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 8F5871AE2BD for ; Mon, 9 Dec 2013 04:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 QhL_JydN98i9 for ; Mon, 9 Dec 2013 04:57:13 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id F04871AE2C1 for ; Mon, 9 Dec 2013 04:57:12 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 3C9C8165110; Mon, 9 Dec 2013 07:57:08 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 68D9E16510A; Mon, 9 Dec 2013 07:57:07 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 9 Dec 2013 07:57:07 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Mon, 9 Dec 2013 07:57:05 -0500 From: Andy Newton To: Ernie Dainow , "Hollenbeck, Scott" Thread-Topic: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) Thread-Index: AQHO9N4oYmJX4zPYfEWUrqN0Cz++XA== Date: Mon, 9 Dec 2013 12:57:04 +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: text/plain; charset="iso-8859-1" Content-ID: <8291C2E4514EB64193D1CB422E6DFBDE@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: John Levine , "weirds@ietf.org" , "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 09 Dec 2013 12:57:14 -0000 From: Ernie Dainow Date: Thursday, December 5, 2013 10:29 AM To: Scott Hollenbeck Cc: John Levine , "weirds@ietf.org" , "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) >If the server is required to do normalization as proposed, then there >should be no false positives and no false negatives. That's kind of the >point of normalization. This is certainly true for a name lookup (or else >IDNA has a major fault), I am pretty > sure it is also true for a search of the form XXX*. Does anyone have a >counter case of a false positive or a false negative for either lookup or >search? > >-Ernie > > > At least for me I find this thread confusing because it seems we are conflating four use cases: 1. Domain lookups 2. Domain searches 3. Entity lookups 4. Entity searches It is my hope we can throw out #3. That would be a lookup on an identifier such as a handle or email address and not a Jcard FN. Is there any disagreement? The text above regarding IDNA seems to apply to #1 and #2 but not #4. #4 would require profiles from Precis. Is that correct? As for #1, are there cases where IDNA normalization rules do not strictly apply with regards to domain name variants. For instance, if a registry had rules that specified Goethe.example and G=F6the.example are variants wouldn't the mandatory normative language to do normalization and then do a binary comparison forbid a server from returning one or the other as a variant of the domain being queried? -andy From andy@arin.net Mon Dec 9 05:07:32 2013 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 E1D3C1AE25C for ; Mon, 9 Dec 2013 05:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8hhvI6SjI-NR for ; Mon, 9 Dec 2013 05:07:31 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 195AD1ADF72 for ; Mon, 9 Dec 2013 05:07:31 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 592671651F8; Mon, 9 Dec 2013 08:07:26 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 90C4D1651FE; Mon, 9 Dec 2013 08:07:23 -0500 (EST) 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; Mon, 9 Dec 2013 08:07:17 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Mon, 9 Dec 2013 08:07:16 -0500 From: Andy Newton To: Ernie Dainow , "Hollenbeck, Scott" , "Murray S. Kucherawy" Thread-Topic: using a preprocessing query parameter (was Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9N+V479pA4w/30yV7cEIAHLm4Q== Date: Mon, 9 Dec 2013 13:07:16 +0000 Message-ID: In-Reply-To: <529F8FDE.5060309@afilias.info> 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: text/plain; charset="us-ascii" Content-ID: <556042EAF1768C4EBA10B81A5718A1D1@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , Peter Saint-Andre Subject: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 09 Dec 2013 13:07:33 -0000 From: Ernie Dainow Date: Wednesday, December 4, 2013 3:26 PM To: Scott Hollenbeck , "Murray S. Kucherawy" Cc: John C Klensin , "weirds@ietf.org" , Peter Saint-Andre Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) >I'm not sure all clients know enough about their locale to determine that >they should perform fullwidth mapping. This can be generalized and >simplified for the client by shifting it to the server. The server rule >would be to first normalize the search/lookup using NFKC or NFKD and then >normalize the result to NFC before doing the lookup against data that is >in NFC. I'm supportive of shifting the burden to the server for clients that do not or cannot know to do normalization. If there are to be cases where the client is more informed, we could add an optional HTTP query parameter indicating the type of preprocessing performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query string preprocessing'). -andy From ajs@anvilwalrusden.com Mon Dec 9 07:09:55 2013 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 98DD61ADF92 for ; Mon, 9 Dec 2013 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 nVBXy_prZRJJ for ; Mon, 9 Dec 2013 07:09:54 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 708E41ADF50 for ; Mon, 9 Dec 2013 07:09:54 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1E6318A031 for ; Mon, 9 Dec 2013 15:09:49 +0000 (UTC) Date: Mon, 9 Dec 2013 10:09:49 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131209150948.GB32716@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 09 Dec 2013 15:09:55 -0000 On Mon, Dec 09, 2013 at 12:57:04PM +0000, Andy Newton wrote: > > As for #1, are there cases where IDNA normalization rules do not strictly > apply with regards to domain name variants. Either they do, or the term "normalization" is not being used in the strict sense that Unicode uses it. I think it's the latter, because of this: > For instance, if a registry > had rules that specified Goethe.example and Göthe.example are variants > wouldn't the mandatory normative language to do normalization and then do > a binary comparison forbid a server from returning one or the other as a > variant of the domain being queried? Well, "Göthe.example" is not legal under IDNA, so the registry can have all the policy it wants. That name is never an IDNA name: in IDNA2003 it's mapped away and in IDNA2008 it's DISALLOWED. This is because of normalization. Specifically, in IDNA2008 it's because Göthe is not stable under NFKC and case folding (göthe is). But I don't think the variant issue has anything to do with it. More generally, the variant stuff is unrelated to normalization, as near as I can tell. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From edainow@afilias.info Mon Dec 9 10:33:21 2013 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 426E91AE448 for ; Mon, 9 Dec 2013 10:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 h1qpfx_OjnSK for ; Mon, 9 Dec 2013 10:33:19 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9787D1AE443 for ; Mon, 9 Dec 2013 10:33:19 -0800 (PST) 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 1Vq5dq-0000Uw-5O for weirds@ietf.org; Mon, 09 Dec 2013 18:33:14 +0000 Received: from mail-ie0-f179.google.com ([209.85.223.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Vq5dq-0000Tk-51 for weirds@ietf.org; Mon, 09 Dec 2013 18:33:14 +0000 Received: by mail-ie0-f179.google.com with SMTP id x13so6550205ief.24 for ; Mon, 09 Dec 2013 10:33:09 -0800 (PST) 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 :content-transfer-encoding; bh=evLUTrp4kjU0746NyJf2EFtmCn7NHQ5AIXTVXPEknz0=; b=SJnQpm0LKAlAqbWibAuHW0FmeBjevhIN6ozJq7CFzKoCATV1CC/SUxtDGhbhE1rUSP aTtGfsQkAWMitEUePDXWPKkg6NSWKdBPmwhs8vYZrusWt9X33IE68wBhkW5Yt8/PQ4SE 6+1ETGI5b4yl1biIpfYYR2jGQhL5X0Y4sTz9NVLc/iUlDbAcRQdmbppwcuOcJGoMlwRi AXFJwf7Rhyk6rSGDr245B6id9YuLXPGmcoDgqRC8x1VUMb+4Q2wfEcd78++WK1O+l79r GnxkqupW4f0AtclhE7oN7PTeFiJt3nlDQ7RTK84jwJCuv23niF8fs+jVMbD/FuMZa9rQ cRKw== X-Gm-Message-State: ALoCoQmCTbWDjKe/h4mKb5A+JiG2et77BxJQLL2RLJKJ4ry0ScpsGNz6jDy+7S8FdDSqk5y9L1Hmm8hhFmzc55nO4ohrReJcCmpFKbc3ORhSiy3h7K9DZ25P+w4blKSW1gjcnvFkJHzu X-Received: by 10.50.254.165 with SMTP id aj5mr16781525igd.0.1386613989105; Mon, 09 Dec 2013 10:33:09 -0800 (PST) X-Received: by 10.50.254.165 with SMTP id aj5mr16781517igd.0.1386613989011; Mon, 09 Dec 2013 10:33:09 -0800 (PST) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id hv5sm15759707igb.9.2013.12.09.10.33.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Dec 2013 10:33:08 -0800 (PST) Message-ID: <52A60CE1.6040806@afilias.info> Date: Mon, 09 Dec 2013 13:33:05 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andy Newton , "Hollenbeck, Scott" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" , "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 09 Dec 2013 18:33:21 -0000 On 12/9/2013 7:57 AM, Andy Newton wrote: > From: Ernie Dainow > Date: Thursday, December 5, 2013 10:29 AM > To: Scott Hollenbeck > Cc: John Levine , "weirds@ietf.org" , > "stpeter@stpeter.im" > Subject: Re: [weirds] Opinions please (was Re: comments > on draft-ietf-weirds-rdap-query-08) > > >> If the server is required to do normalization as proposed, then there >> should be no false positives and no false negatives. That's kind of the >> point of normalization. This is certainly true for a name lookup (or else >> IDNA has a major fault), I am pretty >> sure it is also true for a search of the form XXX*. Does anyone have a >> counter case of a false positive or a false negative for either lookup or >> search? >> >> -Ernie >> >> >> > At least for me I find this thread confusing because it seems we are > conflating four use cases: > > 1. Domain lookups > 2. Domain searches > 3. Entity lookups > 4. Entity searches > > It is my hope we can throw out #3. That would be a lookup on an identifier > such as a handle or email address and not a Jcard FN. Is there any > disagreement? > > The text above regarding IDNA seems to apply to #1 and #2 but not #4. #4 > would require profiles from Precis. Is that correct? #3,4 I don't think there is any restriction on a handle, it could be Unicode. #1,2 There is nothing that is specific to IDNA. The special rules for IDNA (such as allowing only certain code points) don't come into play. These are important if you need to establish validity of a domain name before allowing it to be registered. If you are just doing lookup or search against a data base of registered names, then it is just Unicode strings being compared. For Unicode lookup and search to return consistent results, normalization is required. I don't see any differences between 1,2,3,4 in this regard. Unless there is a very specific reason or case, we should try to specify one general rule for all Unicode lookup and search. > > As for #1, are there cases where IDNA normalization rules do not strictly > apply with regards to domain name variants. For instance, if a registry > had rules that specified Goethe.example and Göthe.example are variants > wouldn't the mandatory normative language to do normalization and then do > a binary comparison forbid a server from returning one or the other as a > variant of the domain being queried? Yes, the rule would prevent returning such variant names as a search result. But the language incorported from John K suggests that the way to handle variants, or any other links between database records, would be to indicate it in the search results. If a search for abl* returns "able" and "ab1e" is a variant, it could be returned in the search result as a variant element, which is already defined in json-response-06. "domainSearchResults" : [ { "handle" : "1-XXXX", "ldhName" : "able.example.com", "variants": [ { "relation": [ "restricted registration" ], "variantNames": [ { "unicodeName": "ab1e.example.com" "ldhName": "ab1e.example.com", }, ... Perhaps we should define the variant relationship, or generalize it to any database linked records in search results, for those providers who are able to return such information. -Ernie From simon.perreault@viagenie.ca Mon Dec 9 12:54:47 2013 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 0E8611AE0A7 for ; Mon, 9 Dec 2013 12:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 gsLWNpz5myxO for ; Mon, 9 Dec 2013 12:54:46 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D26D71AE312 for ; Mon, 9 Dec 2013 12:54:45 -0800 (PST) Received: from balaise.nomis80.org (unknown [IPv6:2620:0:230:2001::100d]) by jazz.viagenie.ca (Postfix) with ESMTPSA id B62A7400A8 for ; Mon, 9 Dec 2013 15:54:40 -0500 (EST) Message-ID: <52A62E10.7070705@viagenie.ca> Date: Mon, 09 Dec 2013 15:54:40 -0500 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: weirds@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 09 Dec 2013 20:54:47 -0000 Le 09/12/2013 08:07, Andy Newton a écrit : >> I'm not sure all clients know enough about their locale to determine that >> they should perform fullwidth mapping. This can be generalized and >> simplified for the client by shifting it to the server. The server rule >> would be to first normalize the search/lookup using NFKC or NFKD and then >> normalize the result to NFC before doing the lookup against data that is >> in NFC. > > > I'm supportive of shifting the burden to the server for clients that do > not or cannot know to do normalization. > > If there are to be cases where the client is more informed, we could add > an optional HTTP query parameter indicating the type of preprocessing > performed by the client. Such as ?qspp=NFKC (where qspp means 'query > string preprocessing'). A robust server would never trust the client and would normalize the query, or at least check that it is normalized, no matter what the client says. So assuming servers always normalize, I don't see the point in mandating client-side normalization. Simon From carlosm3011@gmail.com Mon Dec 9 13:20:21 2013 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 0AE941AE0E7 for ; Mon, 9 Dec 2013 13:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, 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 4Dh2a1djZoHa for ; Mon, 9 Dec 2013 13:20:18 -0800 (PST) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 25D1D1AE0E1 for ; Mon, 9 Dec 2013 13:20:18 -0800 (PST) Received: by mail-qe0-f45.google.com with SMTP id 6so3354894qea.18 for ; Mon, 09 Dec 2013 13:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0Y1iEBDE2ai3HuF6ezEG4uUEOTEn2Sjw0TJ0q3P9FKE=; b=QNIsZqIxjaJkphqbyGLKBun8QzO0s6QEg3HvkXW9T+GZUnl4diKr/+pL6k13Cz3Usk cKPfw4IwtwAcuFsVg76XrC72Fx66rkhanzoV/m+E3Q263V37j6l1roavbYdQ5WlLsxxv QI+S6iTi/lSL5HP7GOiFcNMcKT31PubBuxThx5WxJ7ikwNaxCf9/1eRw6zyxVs19IFhS nRd/RJKemzawGnJch5VW9Jt0lCxUd7q/7vJIAPskXTCIg/TTjI9bJSsBj6LaYLrfGST8 xBrBb1fTD0YEOs6oobA/qd9Ru1iMZF0di4MkPqo/gsar7/Thdhr/lAqktEhIPBzG+M8v YoUA== MIME-Version: 1.0 X-Received: by 10.224.34.71 with SMTP id k7mr37917548qad.15.1386624012978; Mon, 09 Dec 2013 13:20:12 -0800 (PST) Received: by 10.229.99.69 with HTTP; Mon, 9 Dec 2013 13:20:12 -0800 (PST) In-Reply-To: <52A62E10.7070705@viagenie.ca> References: <52A62E10.7070705@viagenie.ca> Date: Mon, 9 Dec 2013 19:20:12 -0200 Message-ID: From: Carlos Martinez-Cagnazzo To: Simon Perreault Content-Type: multipart/alternative; boundary=001a11c291e6bb115c04ed208f9d Cc: "" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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: Mon, 09 Dec 2013 21:20:21 -0000 --001a11c291e6bb115c04ed208f9d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm not fully familiar with what normalization involves. However, as a design principle I would never, ever trust the client with anything. On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault wrote: > Le 09/12/2013 08:07, Andy Newton a =E9crit : > > I'm not sure all clients know enough about their locale to determine tha= t >>> they should perform fullwidth mapping. This can be generalized and >>> simplified for the client by shifting it to the server. The server rule >>> would be to first normalize the search/lookup using NFKC or NFKD and th= en >>> normalize the result to NFC before doing the lookup against data that i= s >>> in NFC. >>> >> >> >> I'm supportive of shifting the burden to the server for clients that do >> not or cannot know to do normalization. >> >> If there are to be cases where the client is more informed, we could add >> an optional HTTP query parameter indicating the type of preprocessing >> performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query >> string preprocessing'). >> > > A robust server would never trust the client and would normalize the > query, or at least check that it is normalized, no matter what the client > says. > > So assuming servers always normalize, I don't see the point in mandating > client-side normalization. > > Simon > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > --=20 -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo h ttp://cagnazzo.me =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --001a11c291e6bb115c04ed208f9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm not fully familiar with what normalization involve= s. However, as a design principle I would never, ever trust the client with= anything.


On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault <simon.perreault= @viagenie.ca> wrote:
Le 09/12/2013 08:07, Andy Newton a =E9crit :

I'm not sure all clients know enough about their locale to determine th= at
they should perform fullwidth mapping. This can be generalized and
simplified for the client by shifting it to the server. The server rule
would be to first normalize the search/lookup using NFKC or NFKD and then normalize the result to NFC before doing the lookup against data that is in NFC.


I'm supportive of shifting the burden to the server for clients that do=
not or cannot know to do normalization.

If there are to be cases where the client is more informed, we could add an optional HTTP query parameter indicating the type of preprocessing
performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query<= br> string preprocessing').

A robust server would never trust the client and would normalize the query,= or at least check that it is normalized, no matter what the client says.
So assuming servers always normalize, I don't see the point in mandatin= g client-side normalization.=

Simon

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



--
=
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
--001a11c291e6bb115c04ed208f9d-- From marc.blanchet@viagenie.ca Mon Dec 9 16:12:27 2013 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 B92401AD9B8 for ; Mon, 9 Dec 2013 16:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 uco4e5N4wICF for ; Mon, 9 Dec 2013 16:12: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 8C20A1A1F3F for ; Mon, 9 Dec 2013 16:12:23 -0800 (PST) Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 4FAD8403E7; Mon, 9 Dec 2013 19:12:15 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_87C4A10B-7DC8-4F26-A6B4-66C160A6821D" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Marc Blanchet In-Reply-To: Date: Mon, 9 Dec 2013 19:12:13 -0500 Message-Id: <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> References: <52A62E10.7070705@viagenie.ca> To: Carlos Martinez-Cagnazzo X-Mailer: Apple Mail (2.1822) Cc: "" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 00:12:27 -0000 --Apple-Mail=_87C4A10B-7DC8-4F26-A6B4-66C160A6821D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-12-09 =E0 16:20, Carlos Martinez-Cagnazzo = a =E9crit : > I'm not fully familiar with what normalization involves. - converting a string of codepoint(s) into another string of codepoints, = based on some rules.=20 - simple example: converting e ' into =E9. > However, as a design principle I would never, ever trust the client = with anything. that is what I was trying to say at the mike during vancouver meeting. = Given that we could expect clients (especially the javascript ones done = by typical web programmer) to not do any normalization nor any string = preparation before sending to the server, then we shall at least say = something about that fact to server implementors in the spec. We could = also point them to ways to mitigate that problem. The best would be to = specify the server side behavior, but there was resistance on doing so. = I'm more than happy if we specify a default server side behavior, = because it will provide better results and better interoperability. Marc. >=20 >=20 > On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault = wrote: > Le 09/12/2013 08:07, Andy Newton a =E9crit : >=20 > I'm not sure all clients know enough about their locale to determine = that > they should perform fullwidth mapping. This can be generalized and > simplified for the client by shifting it to the server. The server = rule > would be to first normalize the search/lookup using NFKC or NFKD and = then > normalize the result to NFC before doing the lookup against data that = is > in NFC. >=20 >=20 > I'm supportive of shifting the burden to the server for clients that = do > not or cannot know to do normalization. >=20 > If there are to be cases where the client is more informed, we could = add > an optional HTTP query parameter indicating the type of preprocessing > performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query > string preprocessing'). >=20 > A robust server would never trust the client and would normalize the = query, or at least check that it is normalized, no matter what the = client says. >=20 > So assuming servers always normalize, I don't see the point in = mandating client-side normalization. >=20 > Simon >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds >=20 >=20 >=20 > --=20 > -- > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > Carlos M. Martinez-Cagnazzo > http://cagnazzo.me > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_87C4A10B-7DC8-4F26-A6B4-66C160A6821D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Le = 2013-12-09 =E0 16:20, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> a = =E9crit :

I'm not fully familiar with what = normalization involves.

- = converting a string of codepoint(s) into another string of codepoints, = based on some rules. 
- simple example: converting e ' = into =E9.

However, = as a design principle I would never, ever trust the client with = anything.

that is what I was = trying to say at the mike during vancouver meeting. Given that we could = expect clients (especially the javascript ones done by typical web = programmer) to not do any normalization nor any string preparation = before sending to the server, then we shall at least say something about = that fact to server implementors in the spec. We could also point them = to ways to mitigate that problem. The best would be to specify the = server side behavior, but there was resistance on doing so. I'm more = than happy if we specify a default server side behavior, because it will = provide better results and better = interoperability.

Marc.



On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault <simon.perreault@viagenie.ca> = wrote:
Le 09/12/2013 08:07, Andy Newton a =E9crit :

I'm not sure all clients know enough about their locale to determine = that
they should perform fullwidth mapping. This can be generalized and
simplified for the client by shifting it to the server. The server = rule
would be to first normalize the search/lookup using NFKC or NFKD and = then
normalize the result to NFC before doing the lookup against data that = is
in NFC.


I'm supportive of shifting the burden to the server for clients that = do
not or cannot know to do normalization.

If there are to be cases where the client is more informed, we could = add
an optional HTTP query parameter indicating the type of = preprocessing
performed by the client. Such as ?qspp=3DNFKC (where qspp means = 'query
string preprocessing').

A robust server would never trust the client and would normalize the = query, or at least check that it is normalized, no matter what the = client says.

So assuming servers always normalize, I don't see the point in mandating = client-side normalization.

Simon

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



-- =
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
_______________________________________________
weirds mailing = list
weirds@ietf.org
https://www.ietf.or= g/mailman/listinfo/weirds

= --Apple-Mail=_87C4A10B-7DC8-4F26-A6B4-66C160A6821D-- From arturo.servin@gmail.com Mon Dec 9 17:34:25 2013 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 053A01ADF38 for ; Mon, 9 Dec 2013 17:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 CTkBFd7156nR for ; Mon, 9 Dec 2013 17:34:23 -0800 (PST) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8182D1AC829 for ; Mon, 9 Dec 2013 17:34:23 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so3428641qcy.12 for ; Mon, 09 Dec 2013 17:34:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rqB6zRbP2lye2n+EQftqoQRCwxVcCeAROEKcy/bP6+c=; b=pcX3feWxtn5DYl7D6QCENeGuS3YRp64g0BwXBSEjvIQGbUg5SF+GOXK2PDg5fsYA/Q vdr3EQdh3uHPhnjPv733Nzn9CBcNNnnbHnrrNeBDEElQHmjqqXO9UzPVFdfRhdhQE+0h R+Nm9aszWDczi2y8/04hhWRmkYyzzZ1wJeigCCW4Z6+cfpPFQvuI0l6g4j4yXhZONX8A eNnOwqctLTBYBVct7N2mwcFdvwUpFkyNfcVyJsWWZstbG3HXFY7riZmomCuFZ8LPa8bI CJDxeE/nYhB3d+TFus7U3Fx8oSYzlG316+QXZuKkY+mK03/gAvj/lbmFczq/KuMmqw+z bT5g== X-Received: by 10.49.73.135 with SMTP id l7mr39099267qev.28.1386639258389; Mon, 09 Dec 2013 17:34:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.18.134 with HTTP; Mon, 9 Dec 2013 17:33:58 -0800 (PST) In-Reply-To: <20131207231754.82862.qmail@joyce.lan> References: <20131207231754.82862.qmail@joyce.lan> From: Arturo Servin Date: Mon, 9 Dec 2013 23:33:58 -0200 Message-ID: To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Cc: "weirds@ietf.org Group" Subject: Re: [weirds] Call for adoption: draft-blanchet-weirds-bootstrap-ianaregistries 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, 10 Dec 2013 01:34:25 -0000 Adopt, under the same comments mentioned by John Levin. .as On Sat, Dec 7, 2013 at 9:17 PM, John Levine wrote: >>This note starts a two-week call for adoption of the above draft. If there >>are no sustained objections, this will be our document to satisfy the >>bootstrapping milestone. > > I think we should adopt it, keeping in mind that adopting it doesn't > necessarily mean that we will publish it in anything like its current > form. > > We still have some big open questions, like whether name bootstrap > only handles TLDs or is intended to handle arbitrary domain names. > > R's, > John > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From andy@arin.net Tue Dec 10 06:34:34 2013 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 980B31A1F65 for ; Tue, 10 Dec 2013 06:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 s7CQZYvx_i1M for ; Tue, 10 Dec 2013 06:34:32 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 998AD1ADFA2 for ; Tue, 10 Dec 2013 06:34:32 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 83EC8165156; Tue, 10 Dec 2013 09:34:27 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id B636E1650D5; Tue, 10 Dec 2013 09:34:26 -0500 (EST) 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, 10 Dec 2013 09:34:26 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 10 Dec 2013 09:34:24 -0500 From: Andy Newton To: Ernie Dainow , "Hollenbeck, Scott" Thread-Topic: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) Thread-Index: AQHO9N4oYmJX4zPYfEWUrqN0Cz++XJpMhEiAgAD724A= Date: Tue, 10 Dec 2013 14:34:24 +0000 Message-ID: In-Reply-To: <52A60CE1.6040806@afilias.info> 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: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" , "stpeter@stpeter.im" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 14:34:34 -0000 On 12/9/13 1:33 PM, "Ernie Dainow" wrote: >>At least for me I find this thread confusing because it seems we are >> conflating four use cases: >> >> 1. Domain lookups >> 2. Domain searches >> 3. Entity lookups >> 4. Entity searches >> >> It is my hope we can throw out #3. That would be a lookup on an >>identifier >> such as a handle or email address and not a Jcard FN. Is there any >> disagreement? >> >> The text above regarding IDNA seems to apply to #1 and #2 but not #4. #4 >> would require profiles from Precis. Is that correct? >#3,4 I don't think there is any restriction on a handle, it could be >Unicode. Ok. Agreed. If a registry issues Unicode handles, they get what they ask for I suppose. :) >#1,2 There is nothing that is specific to IDNA. The special rules for >IDNA (such as allowing only certain code points) don't come into play. >These are important if you need to establish validity of a domain name >before allowing it to be registered. If you are just doing lookup or >search against a data base of registered names, then it is just Unicode >strings being compared. > >For Unicode lookup and search to return consistent results, >normalization is required. I don't see any differences between 1,2,3,4 >in this regard. Unless there is a very specific reason or case, we >should try to specify one general rule for all Unicode lookup and search. >> >> As for #1, are there cases where IDNA normalization rules do not >>strictly >> apply with regards to domain name variants. For instance, if a registry >> had rules that specified Goethe.example and G=F6the.example are variants >> wouldn't the mandatory normative language to do normalization and then >>do >> a binary comparison forbid a server from returning one or the other as a >> variant of the domain being queried? >Yes, the rule would prevent returning such variant names as a search >result. But the language incorported from John K suggests that the way >to handle variants, or any other links between database records, would >be to indicate it in the search results. If a search for abl* returns >"able" and "ab1e" is a variant, it could be returned in the search >result as a variant element, which is already defined in json-response-06. > > "domainSearchResults" : > [ > { > "handle" : "1-XXXX", > "ldhName" : "able.example.com", > "variants": [ > { > "relation": [ > "restricted registration" > ], > "variantNames": [ > { > "unicodeName": "ab1e.example.com" > "ldhName": "ab1e.example.com", > }, > ... For searches, I'm in agreement. But for lookups I am questioning the normative language of requiring the server to normalize and then do a strict binary comparison. Given the example above and the rules of binary comparison, a lookup of "ab1e" would disallow the server from returning "able" even if just to note it as a domain variant of "ab1e". Are we ok with that? >Perhaps we should define the variant relationship, or generalize it to >any database linked records in search results, for those providers who >are able to return such information. I don't understand this. By declaring the variant under "variantNames", the relationship is established. We could also suggest servers return a canonical rel in the "links" array. Is anything more than that needed? -andy From andy@arin.net Tue Dec 10 06:38:50 2013 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 114361ADDD2 for ; Tue, 10 Dec 2013 06:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_BACKHAIR_13=1, RP_MATCHES_RCVD=-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 gxWDKjvEROu6 for ; Tue, 10 Dec 2013 06:38:48 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id EE33F1ADBD1 for ; Tue, 10 Dec 2013 06:38:47 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id DB531165335; Tue, 10 Dec 2013 09:38:42 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id DE66616524A; Tue, 10 Dec 2013 09:38:41 -0500 (EST) 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, 10 Dec 2013 09:38:41 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 10 Dec 2013 09:38:40 -0500 From: Andy Newton To: Marc Blanchet , Carlos Martinez-Cagnazzo Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bWEg+d8jH7jG06Q2J59XuS/3g== Date: Tue, 10 Dec 2013 14:38:40 +0000 Message-ID: In-Reply-To: <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> 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_CECC90C12AAE0andyarinnet_" MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 14:38:50 -0000 --_000_CECC90C12AAE0andyarinnet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with what has been stated here. However, deep down in one of these = threads it was mentioned that a client MIGHT normalize based on specific lo= cale rules of which the server would have no knowledge. In such cases, does= the server need to know about it? -andy From: Marc Blanchet > Date: Monday, December 9, 2013 7:12 PM To: Carlos Martinez > Cc: "weirds@ietf.org" > Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Le 2013-12-09 =E0 16:20, Carlos Martinez-Cagnazzo > a =E9crit : I'm not fully familiar with what normalization involves. - converting a string of codepoint(s) into another string of codepoints, ba= sed on some rules. - simple example: converting e ' into =E9. However, as a design principle I would never, ever trust the client with an= ything. that is what I was trying to say at the mike during vancouver meeting. Give= n that we could expect clients (especially the javascript ones done by typi= cal web programmer) to not do any normalization nor any string preparation = before sending to the server, then we shall at least say something about th= at fact to server implementors in the spec. We could also point them to way= s to mitigate that problem. The best would be to specify the server side be= havior, but there was resistance on doing so. I'm more than happy if we spe= cify a default server side behavior, because it will provide better results= and better interoperability. Marc. On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault > wrote: Le 09/12/2013 08:07, Andy Newton a =E9crit : I'm not sure all clients know enough about their locale to determine that they should perform fullwidth mapping. This can be generalized and simplified for the client by shifting it to the server. The server rule would be to first normalize the search/lookup using NFKC or NFKD and then normalize the result to NFC before doing the lookup against data that is in NFC. I'm supportive of shifting the burden to the server for clients that do not or cannot know to do normalization. If there are to be cases where the client is more informed, we could add an optional HTTP query parameter indicating the type of preprocessing performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query string preprocessing'). A robust server would never trust the client and would normalize the query,= or at least check that it is normalized, no matter what the client says. So assuming servers always normalize, I don't see the point in mandating cl= ient-side normalization. Simon _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds -- -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Carlos M. Martinez-Cagnazzo http://cagnazzo.me =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ weirds mailing list weirds@ietf.org https://www.ietf.org/mailman/listinfo/weirds --_000_CECC90C12AAE0andyarinnet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <6E9B95EF211AB645AF64B54D210970E5@corp.arin.net> Content-Transfer-Encoding: quoted-printable
I agree with what has been stated here. However, deep down in one of t= hese threads it was mentioned that a client MIGHT normalize based on specif= ic locale rules of which the server would have no knowledge. In such cases,= does the server need to know about it?

-andy

From: Marc Blanchet <marc.blanchet@viagenie.ca>
Date: Monday, December 9, 2013 7:12= PM
To: Carlos Martinez <carlos@lacnic.net>
Cc: "weirds@ietf.org" <= weirds@ietf.org>
Subject: Re: [weirds] using a prepr= ocessing query parameter (was Re: Opinions please (was Re: comments on draf= t-ietf-weirds-rdap-query-08))

Le 2013-12-09 =E0 16:20, Carlos Martinez-Cagnazzo <carlosm3011@gmail.com> a =E9crit :

I'm not fully familiar with what normalization involves.

- converting a string of codepoint(s) into another string of codepoint= s, based on some rules. 
- simple example: converting e ' into =E9.

However, as a design principle I would never, ever trust t= he client with anything.

that is what I was trying to say at the mike during vancouver meeting.= Given that we could expect clients (especially the javascript ones done by= typical web programmer) to not do any normalization nor any string prepara= tion before sending to the server, then we shall at least say something about that fact to server implementor= s in the spec. We could also point them to ways to mitigate that problem. T= he best would be to specify the server side behavior, but there was resista= nce on doing so. I'm more than happy if we specify a default server side behavior, because it will provide bett= er results and better interoperability.

Marc.



On Mon, Dec 9, 2013 at 6:54 PM, Simon Perreault = <simon.= perreault@viagenie.ca> wrote:
Le 09/12/2013 08:07, Andy Newton a =E9crit :

I'm not sure all clients know enough about their locale to determine that they should perform fullwidth mapping. This can be generalized and
simplified for the client by shifting it to the server. The server rule
would be to first normalize the search/lookup using NFKC or NFKD and then normalize the result to NFC before doing the lookup against data that is in NFC.


I'm supportive of shifting the burden to the server for clients that do
not or cannot know to do normalization.

If there are to be cases where the client is more informed, we could add an optional HTTP query parameter indicating the type of preprocessing
performed by the client. Such as ?qspp=3DNFKC (where qspp means 'query
string preprocessing').

A robust server would never trust the client and would normalize the query,= or at least check that it is normalized, no matter what the client says.
So assuming servers always normalize, I don't see the point in mandating cl= ient-side normalization.

Simon

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



--
--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Carlos M. Martinez-Cagnazzo
http://cagnazzo.me
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
_______________________________________________
weirds mailing list
weirds@ietf.org
https://www.ietf.o= rg/mailman/listinfo/weirds


--_000_CECC90C12AAE0andyarinnet_-- From ajs@anvilwalrusden.com Tue Dec 10 07:05:27 2013 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 AD96C1AE0D6 for ; Tue, 10 Dec 2013 07:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 t9Z4MlIT-RkG for ; Tue, 10 Dec 2013 07:05:26 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 323B91AE04C for ; Tue, 10 Dec 2013 07:05:26 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 906A18A031 for ; Tue, 10 Dec 2013 15:05:20 +0000 (UTC) Date: Tue, 10 Dec 2013 10:05:23 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131210150523.GE34669@mx1.yitter.info> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 15:05:28 -0000 On Mon, Dec 09, 2013 at 07:12:13PM -0500, Marc Blanchet wrote: > > meeting. Given that we could expect clients (especially the > javascript ones done by typical web programmer) to not do any > normalization nor any string preparation before sending to the > server, then we shall at least say something about that fact to > server implementors in the spec. There are a couple of issues here. First, IDNA2008 does say that the client side MUST reject labels not in NFC. Now, this is partly because it's the client side doing the U-label/A-label conversion (because the DNS server talks only A-labels). But really, to maximize the liklihood of something working, the client ought to normalize, and ought to send only UTF-8 in NFC. So my suggestion is that the client SHOULD send UTF-8 in NFC, with an explicit acknowledgement that the client may not be able to do this reliably; that the server in any case MUST convert to a single coded character set and normalization for the purposes of matching; and that server matching using UTF-8 in NFC is RECOMMENDED for maximal predictability and interoperation. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Tue Dec 10 07:06:26 2013 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 BAA611AE0D6 for ; Tue, 10 Dec 2013 07:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 RiVrAf1dYApg for ; Tue, 10 Dec 2013 07:06:25 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9A91ADF34 for ; Tue, 10 Dec 2013 07:06:25 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 4069D8A031 for ; Tue, 10 Dec 2013 15:06:10 +0000 (UTC) Date: Tue, 10 Dec 2013 10:06:13 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131210150613.GF34669@mx1.yitter.info> References: <52A60CE1.6040806@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 15:06:26 -0000 > Ok. Agreed. If a registry issues Unicode handles, they get what they ask > for I suppose. :) Surely we could put text to that effect in the document? A -- Andrew Sullivan ajs@anvilwalrusden.com From marc.blanchet@viagenie.ca Tue Dec 10 07:11:52 2013 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 EF0661AD7C5 for ; Tue, 10 Dec 2013 07:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ehgikYJd4jPx for ; Tue, 10 Dec 2013 07:11:49 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD571A1F77 for ; Tue, 10 Dec 2013 07:11:49 -0800 (PST) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8BE78400A8; Tue, 10 Dec 2013 10:11:43 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Marc Blanchet In-Reply-To: <20131210150523.GE34669@mx1.yitter.info> Date: Tue, 10 Dec 2013 10:11:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3DF5913F-4A53-4612-95FB-A1DA5F160994@viagenie.ca> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1822) Cc: "" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 15:11:52 -0000 Le 2013-12-10 =E0 10:05, Andrew Sullivan a = =E9crit : > On Mon, Dec 09, 2013 at 07:12:13PM -0500, Marc Blanchet wrote: >>=20 >> meeting. Given that we could expect clients (especially the >> javascript ones done by typical web programmer) to not do any >> normalization nor any string preparation before sending to the >> server, then we shall at least say something about that fact to >> server implementors in the spec. >=20 > There are a couple of issues here. >=20 > First, IDNA2008 does say that the client side MUST reject labels not > in NFC. Now, this is partly because it's the client side doing the > U-label/A-label conversion (because the DNS server talks only > A-labels). But really, to maximize the liklihood of something > working, the client ought to normalize, and ought to send only UTF-8 > in NFC. >=20 > So my suggestion is that the client SHOULD send UTF-8 in NFC, with an > explicit acknowledgement that the client may not be able to do this > reliably; that the server in any case MUST convert to a single > coded character set and normalization for the purposes of matching; > and that server matching using UTF-8 in NFC is RECOMMENDED for maximal > predictability and interoperation. I agree. marc. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From shollenbeck@verisign.com Tue Dec 10 07:26:00 2013 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 D7E001AE18A for ; Tue, 10 Dec 2013 07:26:00 -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 Sy5jbvtJ-lR9 for ; Tue, 10 Dec 2013 07:25:59 -0800 (PST) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 5D76D1AE158 for ; Tue, 10 Dec 2013 07:25:56 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUqcyfxz484YP37Lbgb7SGsV0fv0c2SdD@postini.com; Tue, 10 Dec 2013 07:25:53 PST 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 rBAFPovC008586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 10:25:50 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 10 Dec 2013 10:25:50 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet , Andrew Sullivan Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bonX/URTANujU+ZMm4h39L7cppNjIdQ Date: Tue, 10 Dec 2013 15:25:49 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492FCF0E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <3DF5913F-4A53-4612-95FB-A1DA5F160994@viagenie.ca> In-Reply-To: <3DF5913F-4A53-4612-95FB-A1DA5F160994@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 15:26:01 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Marc > Blanchet > Sent: Tuesday, December 10, 2013 10:12 AM > To: Andrew Sullivan > Cc: > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >=20 >=20 > Le 2013-12-10 =E0 10:05, Andrew Sullivan a =E9cr= it > : >=20 > > On Mon, Dec 09, 2013 at 07:12:13PM -0500, Marc Blanchet wrote: > >> > >> meeting. Given that we could expect clients (especially the > >> javascript ones done by typical web programmer) to not do any > >> normalization nor any string preparation before sending to the > >> server, then we shall at least say something about that fact to > >> server implementors in the spec. > > > > There are a couple of issues here. > > > > First, IDNA2008 does say that the client side MUST reject labels not > > in NFC. Now, this is partly because it's the client side doing the > > U-label/A-label conversion (because the DNS server talks only > > A-labels). But really, to maximize the liklihood of something > > working, the client ought to normalize, and ought to send only UTF-8 > > in NFC. > > > > So my suggestion is that the client SHOULD send UTF-8 in NFC, with an > > explicit acknowledgement that the client may not be able to do this > > reliably; that the server in any case MUST convert to a single > > coded character set and normalization for the purposes of matching; > > and that server matching using UTF-8 in NFC is RECOMMENDED for > maximal > > predictability and interoperation. >=20 > I agree. >=20 > marc. Andrew, could you put this in the form of text that could be incorporated i= nto the document? Scott From edainow@afilias.info Tue Dec 10 09:16:41 2013 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 B4E141ADF74 for ; Tue, 10 Dec 2013 09:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 oYATYaOr7CbW for ; Tue, 10 Dec 2013 09:16:39 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id AFAAD1ADF73 for ; Tue, 10 Dec 2013 09:16:39 -0800 (PST) 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 1VqQvC-0000Vb-4a for weirds@ietf.org; Tue, 10 Dec 2013 17:16:34 +0000 Received: from mail-ie0-f178.google.com ([209.85.223.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VqQvC-0007Le-4L for weirds@ietf.org; Tue, 10 Dec 2013 17:16:34 +0000 Received: by mail-ie0-f178.google.com with SMTP id lx4so8758423iec.23 for ; Tue, 10 Dec 2013 09:16:28 -0800 (PST) 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 :content-transfer-encoding; bh=sFyCEs513SFBqlqAnVzTGthy6JJDwe1cg7aU2RKdqN8=; b=IgsYKe2RFbkfzZTfl44eVkeng7oGIHY51mXbRD5CUkvMTau4RJRFn8pzbYd5pLC9mG epkXdJSXOCZ10Vu5YIuKSp4Zqlj0EPX83viO9yKfw2L/+2EPqKcE/3f5QGDeiT4KcFhH zKCIeL2vnBFiBmBy7WJdk5hQtNczIm7HgG4WdqqJsdcMEG3qFCFzhD2K9Rd2rA1Yvz9r SieWRJ8V+1EAfPmP+aOUniVmQba7ZEeUCN7od8KFyenAiMf0rcXnpGgWJv5oNRpk7nsX teSa1KIQ6sgznDazrGNxxXBh5zuBs33y8RQK0DcJ2Jc6eAspiuD5Mp6N6e7/obmbZ7Yw mXQg== X-Gm-Message-State: ALoCoQlGWnEkyT90CTG4wo72/R640HQru23/1WwK7uc/GfRdu6alL85R4pFxf/oCmEUNOzTyCtuzkkbMKhcSewjeAo6bFynLZJX98DD9Fk58LF3UHQhM8IRKPyBzPTq2XR7bVah2cMw0 X-Received: by 10.50.16.68 with SMTP id e4mr20821095igd.12.1386695788910; Tue, 10 Dec 2013 09:16:28 -0800 (PST) X-Received: by 10.50.16.68 with SMTP id e4mr20821081igd.12.1386695788745; Tue, 10 Dec 2013 09:16:28 -0800 (PST) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id f5sm4080399igc.4.2013.12.10.09.16.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Dec 2013 09:16:27 -0800 (PST) Message-ID: <52A74C5F.2070008@afilias.info> Date: Tue, 10 Dec 2013 12:16:15 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 17:16:41 -0000 On 12/10/2013 9:34 AM, Andy Newton wrote: > On 12/9/13 1:33 PM, "Ernie Dainow" wrote: > ... >> #1,2 There is nothing that is specific to IDNA. The special rules for >> IDNA (such as allowing only certain code points) don't come into play. >> These are important if you need to establish validity of a domain name >> before allowing it to be registered. If you are just doing lookup or >> search against a data base of registered names, then it is just Unicode >> strings being compared. >> >> For Unicode lookup and search to return consistent results, >> normalization is required. I don't see any differences between 1,2,3,4 >> in this regard. Unless there is a very specific reason or case, we >> should try to specify one general rule for all Unicode lookup and search. >>> As for #1, are there cases where IDNA normalization rules do not >>> strictly >>> apply with regards to domain name variants. For instance, if a registry >>> had rules that specified Goethe.example and Göthe.example are variants >>> wouldn't the mandatory normative language to do normalization and then >>> do >>> a binary comparison forbid a server from returning one or the other as a >>> variant of the domain being queried? >> Yes, the rule would prevent returning such variant names as a search >> result. But the language incorported from John K suggests that the way >> to handle variants, or any other links between database records, would >> be to indicate it in the search results. If a search for abl* returns >> "able" and "ab1e" is a variant, it could be returned in the search >> result as a variant element, which is already defined in json-response-06. >> >> "domainSearchResults" : >> [ >> { >> "handle" : "1-XXXX", >> "ldhName" : "able.example.com", >> "variants": [ >> { >> "relation": [ >> "restricted registration" >> ], >> "variantNames": [ >> { >> "unicodeName": "ab1e.example.com" >> "ldhName": "ab1e.example.com", >> }, >> ... > For searches, I'm in agreement. But for lookups I am questioning the > normative language of requiring the server to normalize and then do a > strict binary comparison. There is no fundamental difference between lookup and search. They are both a binary comparison between a query string and target data, where query and target are Unicode, represented as UTF-8. The only difference between the two is length. In lookup you compare the whole strings, in search (of the form XXX*) you just compare the first N characters. To ensure reliable results for both lookup and search, you need to normalize the query string and the target data to the same normalization form. This generalization applies to any Unicode search/lookup -- names, nameservers, entities or thingamabobs. > > Given the example above and the rules of binary comparison, a lookup of > "ab1e" would disallow the server from returning "able" even if just to > note it as a domain variant of "ab1e". Are we ok with that? > >> Perhaps we should define the variant relationship, or generalize it to >> any database linked records in search results, for those providers who >> are able to return such information. > I don't understand this. By declaring the variant under "variantNames", > the relationship is established. We could also suggest servers return a > canonical rel in the "links" array. Is anything more than that needed? Search results as currently defined return only handle and name. If we are to have a standard way to return variants or any other database linked records, those elements need to be specified. A more general way to do this than using the "variants" element above would be to say something like, Each name returned in a search result can optionally contain information about associated data (database linked records), for example "domainSearchResults": [ { "ldhName" : "ablest.example.com", "handle" : "45986w45" }, { "ldhName" : "able.example.com", "handle" : "34598w28", "associatedData": [ { "type": "variant", "names": [ "ab1e.example.com", ... ] } ] }, ... ] -Ernie From prvs=004919cf23=johnl@iecc.com Tue Dec 10 11:30:34 2013 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 ECA631AE1E9 for ; Tue, 10 Dec 2013 11:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 zUvFMnBCikXa for ; Tue, 10 Dec 2013 11:30:33 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 99D791AE17A for ; Tue, 10 Dec 2013 11:30:33 -0800 (PST) Received: (qmail 17603 invoked from network); 10 Dec 2013 19:30:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Dec 2013 19:30:27 -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=52a76bd3.xn--btvx9d.k1310; i=johnl@user.iecc.com; bh=+DbONKH0WRLBkQ0queI8jw2EVq9hqsyztv5EIQ9gjms=; b=0YhAJOx35gML+IdqBxfkEmVFKiC4FvMsAGWY3KAZ1RSx7Ltu+tTAKCpWlihhGjIayxeCTSnQSi9Z6pUDzV8iYtavwr3DGuO7ticHOBhqQF2cV03Cxq1DErZMzp4vJAsy6vTWLXvz3Tgi/tIw8jXmSRLZ1zzv113P8Iif/yx7eiJnTQbUpGEbcVK+M6VtZroKOu8WcjrrWh7RGIE/lF5I9ziVsdfWT9VI8DJZhGLG+fTYjxyi0wjZGer4Eq8BUSY2 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=52a76bd3.xn--btvx9d.k1310; olt=johnl@user.iecc.com; bh=+DbONKH0WRLBkQ0queI8jw2EVq9hqsyztv5EIQ9gjms=; b=IBENOTph10fXGnN5esV1Qa/36Z/SBR7MxrmQjluPbofatSU7PNStD8VB27+24ke/1bkYvYgu0ZVCfR7FXiZfdB/sOEOQdH2m42Cq/6segAEtnmcKt/PvxsWmI/vcIn6ljjBOJTbXf99M8yXhHnk71sY2wP+PNBelkRwTfbINeeXwHfsp3p7v0oCMswXYtjTh1V6rWAm/jnq8pjLyMu38hla6Jbed+eC6UTAOW1Hw6UP0TOlBcTvH8sCFMm4TFZZw Date: 10 Dec 2013 19:30:04 -0000 Message-ID: <20131210193004.12634.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 Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 19:30:35 -0000 >For searches, I'm in agreement. But for lookups I am questioning the >normative language of requiring the server to normalize and then do a >strict binary comparison. I'm with you here, this is overspecified. Servers will in fact do whatever they do, and if their internal design turns oe into ö they will do that no matter what we say. I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD normalize non-NFC if they can, and leave it at that. From prvs=004919cf23=johnl@iecc.com Tue Dec 10 11:35:36 2013 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 438971AE1E7 for ; Tue, 10 Dec 2013 11:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 5i0UZaJeyMKY for ; Tue, 10 Dec 2013 11:35:35 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C61AE1BA for ; Tue, 10 Dec 2013 11:35:35 -0800 (PST) Received: (qmail 18609 invoked from network); 10 Dec 2013 19:35:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Dec 2013 19:35:29 -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=52a76d01.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=3lJmKUONmx2wTsHVo3ClG5rVHFKOLopirquVNxQnyWk=; b=2dF6Cl6FgHsZN/oXfjUwM2iUAt7jhMvz65lQ6+Dq0jW3O+t1DjS9l6bZJAnt8YsMblANC4duP3HyRC8y+OTkeCYfA67KHudJzOxoJb4i0jDgEq6RHIUi1LAg7U8IOE5ugPYo8XTT1C9Pn5jUgVUhbQhyYfHfkrOF1U0YObnZHgjNOyOHiK+cigpxq0Dn7/CLDrYQ0P6awHxBJdaSeZ6UoRvCWf3gAXzi/BzveGJ8Rvnau65ClJKgZEKE1wcTkqBv 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=52a76d01.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=3lJmKUONmx2wTsHVo3ClG5rVHFKOLopirquVNxQnyWk=; b=vJWKH0dmW0eCJd3dZZ6Xs1CjXcGUwxQ+29XXkIG6bDmAzaxnbXxuUR3tTcg93K2GQBXOBpp7YX7M4alu5qxOnxOq4YUsBr71U0MX2xmnOYCskCQC/F4uRI9jYEb26g5U+j9bFWEX6vk13ANhAbnuDm/bwprH4Z+YtlJF6UK5sE3v58OBtkaFpx5fqM4oGeH28gImTsUlPKPSbFUvaISjz+YXLIA6xqLUeKZD18CJCF8h5zDPAMqFUOySTXirQJf0 Date: 10 Dec 2013 19:35:07 -0000 Message-ID: <20131210193507.12678.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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 19:35:36 -0000 >I agree with what has been stated here. However, deep down in one of these threads it was mentioned that a client MIGHT >normalize based on specific locale rules of which the server would have no knowledge. In such cases, does the server need to >know about it? Clients MIGHT do a lot of things. Absent specific examples which we understand well enough to describe, and volunteers who say they will write server and client code that implements it in an interoperable way, I'd prefer not to guess about extensions and edge cases. >From what I've seen, if clients send UTF-8, in NFC form where possible, that will maximize their chances of interoperating with most servers. R's, John From andy@arin.net Tue Dec 10 13:07:33 2013 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 E98FB1AE08F for ; Tue, 10 Dec 2013 13:07:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 vmAqpdrpT3w0 for ; Tue, 10 Dec 2013 13:07:31 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD4E1AE07A for ; Tue, 10 Dec 2013 13:07:31 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id D188521365F; Tue, 10 Dec 2013 16:07:25 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id D019B21363F; Tue, 10 Dec 2013 16:07:24 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 10 Dec 2013 16:07:18 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Tue, 10 Dec 2013 16:07:18 -0500 From: Andy Newton To: Ernie Dainow Thread-Topic: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) Thread-Index: AQHO9N4oYmJX4zPYfEWUrqN0Cz++XJpMhEiAgAD724CAAIECgP//7LoA Date: Tue, 10 Dec 2013 21:07:17 +0000 Message-ID: In-Reply-To: <52A74C5F.2070008@afilias.info> 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: text/plain; charset="iso-8859-1" Content-ID: <52F9E2C5F960064DB93F63080DC38ADC@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 21:07:33 -0000 On 12/10/13 12:16 PM, "Ernie Dainow" wrote: > >On 12/10/2013 9:34 AM, Andy Newton wrote: >> On 12/9/13 1:33 PM, "Ernie Dainow" wrote: >> >... >>> #1,2 There is nothing that is specific to IDNA. The special rules for >>> IDNA (such as allowing only certain code points) don't come into play. >>> These are important if you need to establish validity of a domain name >>> before allowing it to be registered. If you are just doing lookup or >>> search against a data base of registered names, then it is just Unicode >>> strings being compared. >>> >>> For Unicode lookup and search to return consistent results, >>> normalization is required. I don't see any differences between 1,2,3,4 >>> in this regard. Unless there is a very specific reason or case, we >>> should try to specify one general rule for all Unicode lookup and >>>search. >>>> As for #1, are there cases where IDNA normalization rules do not >>>> strictly >>>> apply with regards to domain name variants. For instance, if a >>>>registry >>>> had rules that specified Goethe.example and G=F6the.example are varian= ts >>>> wouldn't the mandatory normative language to do normalization and then >>>> do >>>> a binary comparison forbid a server from returning one or the other >>>>as a >>>> variant of the domain being queried? >>> Yes, the rule would prevent returning such variant names as a search >>> result. But the language incorported from John K suggests that the way >>> to handle variants, or any other links between database records, would >>> be to indicate it in the search results. If a search for abl* returns >>> "able" and "ab1e" is a variant, it could be returned in the search >>> result as a variant element, which is already defined in >>>json-response-06. >>> >>> "domainSearchResults" : >>> [ >>> { >>> "handle" : "1-XXXX", >>> "ldhName" : "able.example.com", >>> "variants": [ >>> { >>> "relation": [ >>> "restricted registration" >>> ], >>> "variantNames": [ >>> { >>> "unicodeName": "ab1e.example.com" >>> "ldhName": "ab1e.example.com", >>> }, >>> ... >> For searches, I'm in agreement. But for lookups I am questioning the >> normative language of requiring the server to normalize and then do a >> strict binary comparison. >There is no fundamental difference between lookup and search. They are >both a binary comparison between a query string and target data, where >query and target are Unicode, represented as UTF-8. The only difference >between the two is length. In lookup you compare the whole strings, in >search (of the form XXX*) you just compare the first N characters. > >To ensure reliable results for both lookup and search, you need to >normalize the query string and the target data to the same normalization >form. > >This generalization applies to any Unicode search/lookup -- names, >nameservers, entities or thingamabobs. Fair enough. This applies to searches and lookups. However, I'm focusing not on the need for normalization but the second step specified in one of the earlier threads -- strict comparison of the normalized strings. This, I think, will disallow servers from returning domain variants as a direct result. > >> >> Given the example above and the rules of binary comparison, a lookup of >> "ab1e" would disallow the server from returning "able" even if just to >> note it as a domain variant of "ab1e". Are we ok with that? >> >>> Perhaps we should define the variant relationship, or generalize it to >>> any database linked records in search results, for those providers who >>> are able to return such information. >> I don't understand this. By declaring the variant under "variantNames", >> the relationship is established. We could also suggest servers return a >> canonical rel in the "links" array. Is anything more than that needed? > >Search results as currently defined return only handle and name. If we >are to have a standard way to return variants or any other database >linked records, those elements need to be specified. A more general way >to do this than using the "variants" element above would be to say >something like, The current draft does not limit searches to only returning handles and names. That's just an elided example. >Each name returned in a search result can optionally contain information >about associated data (database linked records), for example > >"domainSearchResults": [ > { > "ldhName" : "ablest.example.com", > "handle" : "45986w45" > }, > { > "ldhName" : "able.example.com", > "handle" : "34598w28", > "associatedData": [ > { > "type": "variant", > "names": [ > "ab1e.example.com", > ... > ] > } > ] > }, > ... >] I think the current draft supports what JCK was talking about. I don't think there is any need to modify the current data model. -andy From andy@arin.net Tue Dec 10 13:08:42 2013 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 1FD1D1AE18A for ; Tue, 10 Dec 2013 13:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 GWpYMzagQS-x for ; Tue, 10 Dec 2013 13:08:40 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id C98C51AE07A for ; Tue, 10 Dec 2013 13:08:40 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 9BD951653CD; Tue, 10 Dec 2013 16:08:35 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp1.arin.net (Postfix) with ESMTP id 06797165360; Tue, 10 Dec 2013 16:08:35 -0500 (EST) 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; Tue, 10 Dec 2013 16:08:34 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Tue, 10 Dec 2013 16:08:34 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bWEg+d8jH7jG06Q2J59XuS/3ppOJkOA///GQwA= Date: Tue, 10 Dec 2013 21:08:33 +0000 Message-ID: In-Reply-To: <20131210193507.12678.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: [10.1.30.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <7FB24976AC40A547A2D6AAB941D8F4E8@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 21:08:42 -0000 On 12/10/13 2:35 PM, "John Levine" wrote: >>I agree with what has been stated here. However, deep down in one of >>these threads it was mentioned that a client MIGHT >>normalize based on specific locale rules of which the server would have >>no knowledge. In such cases, does the server need to >>know about it? > >Clients MIGHT do a lot of things. Absent specific examples which we >understand well enough to describe, and volunteers who say they will >write server and client code that implements it in an interoperable >way, I'd prefer not to guess about extensions and edge cases. > >From what I've seen, if clients send UTF-8, in NFC form where >possible, that will maximize their chances of interoperating with most >servers. This works for me. Just wanted to make sure we are all in agreement. -andy From shollenbeck@verisign.com Tue Dec 10 13:21:47 2013 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 32D2A1AE18A for ; Tue, 10 Dec 2013 13:21:47 -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 EUtmsOV7Jmgy for ; Tue, 10 Dec 2013 13:21:45 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCAB1AE1A1 for ; Tue, 10 Dec 2013 13:21:39 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUqeF3rOGnkZMuMwS8yqqErWoDSykRaRd@postini.com; Tue, 10 Dec 2013 13:21:38 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 rBALLXvB014802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Dec 2013 16:21:33 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 10 Dec 2013 16:21:33 -0500 From: "Hollenbeck, Scott" To: Andy Newton , John Levine , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9ewBgO1Y2PN2cEqublJ29WOnappN74aQ Date: Tue, 10 Dec 2013 21:21:33 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492FD3AE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20131210193507.12678.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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 10 Dec 2013 21:21:47 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andy Newton > Sent: Tuesday, December 10, 2013 4:09 PM > To: John Levine; weirds@ietf.org > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >=20 > On 12/10/13 2:35 PM, "John Levine" wrote: >=20 > >>I agree with what has been stated here. However, deep down in one of > >>these threads it was mentioned that a client MIGHT > >>normalize based on specific locale rules of which the server would > have > >>no knowledge. In such cases, does the server need to > >>know about it? > > > >Clients MIGHT do a lot of things. Absent specific examples which we > >understand well enough to describe, and volunteers who say they will > >write server and client code that implements it in an interoperable > >way, I'd prefer not to guess about extensions and edge cases. > > > >From what I've seen, if clients send UTF-8, in NFC form where > >possible, that will maximize their chances of interoperating with most > >servers. >=20 > This works for me. Just wanted to make sure we are all in agreement. Me, too, and it's consistent with sentiment expressed in an earlier note fr= om Andrew in which I asked for some suggested text. Scott From edainow@afilias.info Tue Dec 10 13:43:14 2013 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 9D3AF1AE04B for ; Tue, 10 Dec 2013 13:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 lH7Czqs81dJx for ; Tue, 10 Dec 2013 13:43:13 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id DFB0D1AE03C for ; Tue, 10 Dec 2013 13:43:12 -0800 (PST) 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 1VqV59-0004I6-4M for weirds@ietf.org; Tue, 10 Dec 2013 21:43:07 +0000 Received: from mail-ea0-f171.google.com ([209.85.215.171]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VqV59-0008NK-3s for weirds@ietf.org; Tue, 10 Dec 2013 21:43:07 +0000 Received: by mail-ea0-f171.google.com with SMTP id h10so2522592eak.2 for ; Tue, 10 Dec 2013 13:43:01 -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=AFrFAB5qbeEuFrvrNqqCw+zEp4mCR9TBnod6v+jopME=; b=bDc8ryZko98Dm9Ff3LlEitvk+HM0ny5uTyklBzc8tKTrEwP4G6sZ9SerTXuvmlbs1Q 6kL8gOgYShszCFoPPzgAZRW1iNr9BS+pY5/BUtovYIfJdp+VZI085gNKHy71rccICqih eVP9mrF/afJUyOwHmAJ7kyTilCTc1AUDZVPj/4d6fiKTbhwyTM11HryByJYUqaM0Cm6J 9KhA+X7uEll+r36vRfleyza6j/INCIy8cRH0SbDhDsfN+nC6Xe7mEiIrztvS8ccquK/8 jdOzJJahFmocxC1QhJxJ2GYFKL7BBl/Vd2RJXj6wBxCPXxdXMP+5HKSdR3BmucyFU8mb YhYA== X-Gm-Message-State: ALoCoQnIUUYCskvAMQBZUdbHFn87m0oR5wB1nWH0Ym15bbOlVfrWhYIYKLMW8yOn8ycNgc0n6ZHzVu9DgFFyq5ozp1rCblffly8UqKuDK3y4yaqvAjF+MG4kBsRWevHynfYkJLzkOdZf X-Received: by 10.14.207.194 with SMTP id n42mr14882793eeo.76.1386711781162; Tue, 10 Dec 2013 13:43:01 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.207.194 with SMTP id n42mr14882787eeo.76.1386711781106; Tue, 10 Dec 2013 13:43:01 -0800 (PST) Received: by 10.14.201.8 with HTTP; Tue, 10 Dec 2013 13:43:00 -0800 (PST) In-Reply-To: <20131210193004.12634.qmail@joyce.lan> References: <20131210193004.12634.qmail@joyce.lan> Date: Tue, 10 Dec 2013 16:43:00 -0500 Message-ID: From: Ernie Dainow To: John Levine Content-Type: multipart/alternative; boundary=047d7b33db8a1e734e04ed34ff76 Cc: "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 21:43:14 -0000 --047d7b33db8a1e734e04ed34ff76 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If servers are just going to do what they do, what is the point in trying to develop a standard. Imagine the havoc if the DNS standards were this loose and DNS lookups worked sometimes but not at other times. The Internet is much better off with a standard that strives for interoperability. If a provider does not do normalization as per spec, then they should document that (along with any other limitations) on their Help page. That way, a user can be forewarned that some queries against certain servers may not succeed. A spec that only specifies SHOULD will lead to inconsistent results with no indication of when or why. -Ernie On Tue, Dec 10, 2013 at 2:30 PM, John Levine wrote: > >For searches, I'm in agreement. But for lookups I am questioning the > >normative language of requiring the server to normalize and then do a > >strict binary comparison. > > I'm with you here, this is overspecified. Servers will in fact do > whatever they do, and if their internal design turns oe into =F6 they > will do that no matter what we say. > > I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD > normalize non-NFC if they can, and leave it at that. > > > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds > > --047d7b33db8a1e734e04ed34ff76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If servers are just going to do what they do, what is the = point in trying to develop a standard. Imagine the havoc if the DNS standar= ds were this loose and DNS lookups worked sometimes but not at other times.=

The Internet is much better off with a standard that strives= for interoperability. If a provider does not do normalization as per spec,= then they should document that (along with any other limitations) on their= Help page. That way, a user can be forewarned that some queries against ce= rtain servers may not succeed. A spec that only specifies SHOULD will lead = to inconsistent results with no indication of when or why.

-Ernie



On Tue, Dec 10, 2013 at 2:30 PM= , John Levine <johnl@taugh.com> wrote:
>For searches, I'm = in agreement. But for lookups I am questioning the
>normative language of requiring the server to normalize and then do a >strict binary comparison.

I'm with you here, this is overspecified. =A0Servers will in fact= do
whatever they do, and if their internal design turns oe into =F6 they
will do that no matter what we say.

I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD
normalize non-NFC if they can, and leave it at that.


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


--047d7b33db8a1e734e04ed34ff76-- From marc.blanchet@viagenie.ca Tue Dec 10 13:47:45 2013 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 113D71AE04B for ; Tue, 10 Dec 2013 13:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 oZqjSpw8nshs for ; Tue, 10 Dec 2013 13:47:42 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3E1AE0B4 for ; Tue, 10 Dec 2013 13:47:42 -0800 (PST) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id D0224403F8; Tue, 10 Dec 2013 16:47:35 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_63C14190-CB28-4184-BDFA-33D85EBFC27A" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Marc Blanchet In-Reply-To: Date: Tue, 10 Dec 2013 16:47:34 -0500 Message-Id: <96F345A4-4616-4D80-8200-261CF0319D03@viagenie.ca> References: <20131210193004.12634.qmail@joyce.lan> To: Ernie Dainow X-Mailer: Apple Mail (2.1822) Cc: John Levine , "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 21:47:45 -0000 --Apple-Mail=_63C14190-CB28-4184-BDFA-33D85EBFC27A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 2013-12-10 =E0 16:43, Ernie Dainow a =E9crit : > If servers are just going to do what they do, what is the point in = trying to develop a standard. Imagine the havoc if the DNS standards = were this loose and DNS lookups worked sometimes but not at other times. >=20 > The Internet is much better off with a standard that strives for = interoperability. If a provider does not do normalization as per spec, = then they should document that (along with any other limitations) on = their Help page. That way, a user can be forewarned that some queries = against certain servers may not succeed. A spec that only specifies = SHOULD will lead to inconsistent results with no indication of when or = why. - agree. - we shall be strive for maximum interoperability and best likely = results of lookup/search for users,=20 - while knowing that a) implementations in the field may not fully = conform b) i18n searching is difficult and the solution won't be = perfect. Marc. >=20 > -Ernie >=20 >=20 >=20 > On Tue, Dec 10, 2013 at 2:30 PM, John Levine wrote: > >For searches, I'm in agreement. But for lookups I am questioning the > >normative language of requiring the server to normalize and then do a > >strict binary comparison. >=20 > I'm with you here, this is overspecified. Servers will in fact do > whatever they do, and if their internal design turns oe into =F6 they > will do that no matter what we say. >=20 > I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD > normalize non-NFC if they can, and leave it at that. >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds --Apple-Mail=_63C14190-CB28-4184-BDFA-33D85EBFC27A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Le = 2013-12-10 =E0 16:43, Ernie Dainow <edainow@afilias.info> a = =E9crit :

If servers are just going to do what they = do, what is the point in trying to develop a standard. Imagine the havoc = if the DNS standards were this loose and DNS lookups worked sometimes = but not at other times.

The Internet is much better off with a standard that = strives for interoperability. If a provider does not do normalization as = per spec, then they should document that (along with any other = limitations) on their Help page. That way, a user can be forewarned that = some queries against certain servers may not succeed. A spec that only = specifies SHOULD will lead to inconsistent results with no indication of = when or why.

- = agree.
- we shall be strive for maximum interoperability and = best likely results of lookup/search for users, 
- while = knowing that a) implementations in the field may not fully conform =  b) i18n searching is difficult and the solution won't be = perfect.

Marc.


-Ernie



On Tue, Dec 10, = 2013 at 2:30 PM, John Levine <johnl@taugh.com> wrote:
>For searches, I'm in agreement. But for lookups I am = questioning the
>normative language of requiring the server to normalize and then do = a
>strict binary comparison.

I'm with you here, this is overspecified.  Servers will in = fact do
whatever they do, and if their internal design turns oe into =F6 = they
will do that no matter what we say.

I'd stick with clients SHOULD send UTF-8 NFC, and servers SHOULD
normalize non-NFC if they can, and leave it at that.


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


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

= --Apple-Mail=_63C14190-CB28-4184-BDFA-33D85EBFC27A-- From prvs=0049baed04=johnl@taugh.com Tue Dec 10 13:57:21 2013 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 2B88B1AE1CD for ; Tue, 10 Dec 2013 13:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 4Ji1OYTM3qPg for ; Tue, 10 Dec 2013 13:57:19 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 37BDC1AE203 for ; Tue, 10 Dec 2013 13:57:18 -0800 (PST) Received: (qmail 43383 invoked from network); 10 Dec 2013 21:57:13 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Dec 2013 21:57:13 -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=9da6.52a78e39.k1312; i=johnl%iecc.com@submit.iecc.com; bh=1NRBktxSydq30YEnZnNWrnyxFFYLqUrGpd+GG2kPBhk=; b=MDiMX9W9R2SCtcM6U/zUcMBxpf32WbZ/t4bbPvB4RDou75q3m6YB0QjR/Dduy+eW5sGnodAyIJJmPrWFi71xgKRDpsDAujfkAwmQj8hPhAuPDO7/lhyKhkZ5IRSVuPMg32WSrk2ggj2ce9Jp/0gZfchOlq+KwTNg4NuYNl5+E4aPrIzWoqyRp0Qwpnmr8BqNg81LUOkTFTihhEjsQ4OmGTcoBpfCEt4lBJvMWkwXgVo7K5IkYam7zGDLXXmvfyxW 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=9da6.52a78e39.k1312; olt=johnl%iecc.com@submit.iecc.com; bh=1NRBktxSydq30YEnZnNWrnyxFFYLqUrGpd+GG2kPBhk=; b=ruhjj/rRgeKxVdnxJq2c3kS9TlBRbxjIqylk/a6YKPQgpROpyqN5tAL0jyG+aTcsgHWVYxBJCxSbGjUScwOGdh9PiPV6pDDnKR9PWbRyoKYZBk5oDiXu9lMKh4IQCe9BYxdL2ft55TINOtJNTQTKTEGRElF4s0ve2K7M+/wVCN1wy+7akNleSONwvxAlX85YY16NQy+oB0m14lxbMyqE7nWHYWBiDfGHHATuitrcwd9rq+sYz7vNbne5+ylsYb8N Received: from joyce.lan ([24.58.62.56]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 10 Dec 2013 21:57:13 -0000 Date: 10 Dec 2013 16:57:11 -0500 Message-ID: From: "John R Levine" To: "Ernie Dainow" In-Reply-To: References: <20131210193004.12634.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 Cc: "weirds@ietf.org" Subject: Re: [weirds] Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08) 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, 10 Dec 2013 21:57:21 -0000 > If servers are just going to do what they do, what is the point in trying > to develop a standard. Imagine the havoc if the DNS standards were this > loose and DNS lookups worked sometimes but not at other times. We have a large installed base of registry software. Search is a marginal feature, and it is utterly implausible that anyone will do anything for search that involves much more than a lookup that does whatever their database does now. I'm all in favor of making things as interoperable as we can, but I'm also in favor of not making promises we can't keep. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From shollenbeck@verisign.com Wed Dec 11 04:51:52 2013 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 253C81AD8F7 for ; Wed, 11 Dec 2013 04:51:52 -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 tnUu7r5pL6QD for ; Wed, 11 Dec 2013 04:51:50 -0800 (PST) Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3ED1AD8F2 for ; Wed, 11 Dec 2013 04:51:48 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUqhf3jiJKqMPJKDeyGHT3pKn8p0TOjT/@postini.com; Wed, 11 Dec 2013 04:51:45 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rBBCpfZq011523 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 07:51:41 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 11 Dec 2013 07:51:41 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSg Date: Wed, 11 Dec 2013 12:51:40 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> In-Reply-To: <20131210150523.GE34669@mx1.yitter.info> 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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 12:51:52 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > Sullivan > Sent: Tuesday, December 10, 2013 10:05 AM > To: weirds@ietf.org > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) [snip] > So my suggestion is that the client SHOULD send UTF-8 in NFC, with an > explicit acknowledgement that the client may not be able to do this > reliably; that the server in any case MUST convert to a single > coded character set and normalization for the purposes of matching; > and that server matching using UTF-8 in NFC is RECOMMENDED for maximal > predictability and interoperation. I'm going to try to speed this along by suggesting text. Here's what rdap-q= uery-08 currently says: "Servers SHOULD thus accept any search pattern that is otherwise properly e= ncoded. If the pattern consists entirely of ASCII characters, servers SHOU= LD use case-insensitive prefix matching against ASCII labels to determine p= artial matches. If the text in the pattern is or can be converted to a U-l= abel, servers SHOULD use prefix matching against U-labels to determine part= ial matches." Suggested new text: "Clients SHOULD send UTF-8 queries encoded using Normalization Form C (NFC,= [Unicode-UAX15]); note that clients might not be able to do this reliably.= Servers MUST convert to a single coded character set and normalization for= the purposes of matching. Server matching using UTF-8 in NFC is RECOMMENDE= D to maximize predictability and interoperability. If the query pattern con= sists entirely of ASCII characters, servers SHOULD use case-insensitive pre= fix matching against ASCII labels to determine partial matches." Does this work? Please suggest specific changes if not. Scott From andy@arin.net Wed Dec 11 07:47:32 2013 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 A1F531ADF5E for ; Wed, 11 Dec 2013 07:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 xJPB5f8tMApe for ; Wed, 11 Dec 2013 07:47:31 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7881ADF6E for ; Wed, 11 Dec 2013 07:47:31 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id DBBDB1653FB; Wed, 11 Dec 2013 10:47:25 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id E28181653EA; Wed, 11 Dec 2013 10:47:24 -0500 (EST) 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; Wed, 11 Dec 2013 10:47:24 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 11 Dec 2013 10:47:24 -0500 From: Andy Newton To: "Hollenbeck, Scott" , Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9blCd+hQSwqw9EqvqqS9C1Tm7JpPR9cA///dQoA= Date: Wed, 11 Dec 2013 15:47:23 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 15:47:32 -0000 On 12/11/13 7:51 AM, "Hollenbeck, Scott" wrote: >> >Suggested new text: > >"Clients SHOULD send UTF-8 queries encoded using Normalization Form C >(NFC, [Unicode-UAX15]); note that clients might not be able to do this >reliably. Servers MUST convert to a single coded character set and >normalization for the purposes of matching. Server matching using UTF-8 >in NFC is RECOMMENDED to maximize predictability and interoperability. If >the query pattern consists entirely of ASCII characters, servers SHOULD >use case-insensitive prefix matching against ASCII labels to determine >partial matches." > >Does this work? Please suggest specific changes if not. In the very last sentence I would replace "ASCII labels" with "ASCII characters", but this works for me. -andy From prvs=0050d13e24=johnl@iecc.com Wed Dec 11 08:27:49 2013 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 260431AE0B5 for ; Wed, 11 Dec 2013 08:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 otWnuP3f2QWB for ; Wed, 11 Dec 2013 08:27:48 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id E951D1ADFCA for ; Wed, 11 Dec 2013 08:27:47 -0800 (PST) Received: (qmail 40096 invoked from network); 11 Dec 2013 16:27:41 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Dec 2013 16:27:41 -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=52a8927d.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=rKx835J+v0A/3h1BMEfByuHuh05gGJAf1Zxgod9ymDw=; b=yMunvQLj1jIS8D9PuZdys9pT0qKQvwTR0WvEKnO+2fFpDaAH3Ls+vVKCLTu0MUgFAIoQZRTnpmVz1OUiPSY5hSEuTEeFF2GjJ4SVtIw2Gy6bjlqJmmN08ur5W+bxZiYhf0ikObhlDOKMDJzM74yb/qf9kLtMZn3xnImv0c2P8qpMLxQ+MmEqR5whg+8dVajwwE7bs7jGOmx+noK/NGhjIV86HnzbXT8T3yS/lMyjtOaNP36P09bxaOudydlVNdPe 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=52a8927d.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=rKx835J+v0A/3h1BMEfByuHuh05gGJAf1Zxgod9ymDw=; b=OLED4YNZEHAgLwHFo2+L7nqlCjq35CEirXmS/BlrK4c0KWoYfegFT+nrmC2OP4/CuZTUjRfcmgRBe/Z5Qh00oGy6s/JUF2+Xs54tV05UsxHkc1Dq0B/NibxYWBIsiPv/4uzFkDX8OEeG2topiMHMCLfEvtNawAdBHKtPOBB5fsqh3A3GfeCdoIq8HirFCKbcYGEw4LWYcMBSbkwfosAfRn1vHkUlbVN0/8gTzKcQ7UdHvDzdpbBI3ojr2/P4DKUc Date: 11 Dec 2013 16:27:17 -0000 Message-ID: <20131211162717.22541.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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 16:27:49 -0000 >>"Clients SHOULD send UTF-8 queries encoded using Normalization Form C >>(NFC, [Unicode-UAX15]); note that clients might not be able to do this >>reliably. Servers MUST convert to a single coded character set and >>normalization for the purposes of matching. Server matching using UTF-8 >>in NFC is RECOMMENDED to maximize predictability and interoperability. If >>the query pattern consists entirely of ASCII characters, servers SHOULD >>use case-insensitive prefix matching against ASCII labels to determine >>partial matches." >> >>Does this work? Please suggest specific changes if not. > > >In the very last sentence I would replace "ASCII labels" with "ASCII >characters", but this works for me. I prefer ASCII labels, contrasted to A-labels or U-labels, but I don't feel very strongly. Otherwise fine. From andy@arin.net Wed Dec 11 09:22:38 2013 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 C54F41ADF12 for ; Wed, 11 Dec 2013 09:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 uYumFbuxKvZq for ; Wed, 11 Dec 2013 09:22:37 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [192.149.252.32]) by ietfa.amsl.com (Postfix) with ESMTP id EF9041ACB4E for ; Wed, 11 Dec 2013 09:22:36 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 7131721365F; Wed, 11 Dec 2013 12:21:59 -0500 (EST) Received: from CHAXCH05.corp.arin.net (chaxch05.corp.arin.net [192.149.252.94]) by smtp2.arin.net (Postfix) with ESMTP id CC21321365F; Wed, 11 Dec 2013 12:21:58 -0500 (EST) Received: from CHAXCH03.corp.arin.net (10.1.30.17) by CHAXCH05.corp.arin.net (192.149.252.94) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 11 Dec 2013 12:21:58 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Wed, 11 Dec 2013 12:21:58 -0500 From: Andy Newton To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9blCd+hQSwqw9EqvqqS9C1Tm7JpPR9cA///dQoCAAF78gP//u3MA Date: Wed, 11 Dec 2013 17:21:57 +0000 Message-ID: In-Reply-To: <20131211162717.22541.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: [10.1.30.36] Content-Type: text/plain; charset="us-ascii" Content-ID: <616966291F2FFC4893890C8EA5E1E85D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 17:22:38 -0000 On 12/11/13 11:27 AM, "John Levine" wrote: >>>"Clients SHOULD send UTF-8 queries encoded using Normalization Form C >>>(NFC, [Unicode-UAX15]); note that clients might not be able to do this >>>reliably. Servers MUST convert to a single coded character set and >>>normalization for the purposes of matching. Server matching using UTF-8 >>>in NFC is RECOMMENDED to maximize predictability and interoperability. >>>If >>>the query pattern consists entirely of ASCII characters, servers SHOULD >>>use case-insensitive prefix matching against ASCII labels to determine >>>partial matches." >>> >>>Does this work? Please suggest specific changes if not. >> >> >>In the very last sentence I would replace "ASCII labels" with "ASCII >>characters", but this works for me. > >I prefer ASCII labels, contrasted to A-labels or U-labels, but I don't >feel very strongly. Otherwise fine. > > I don't feel strongly either. My reasoning for ASCII characters is to be consistent (the term is used in the first part of the sentence) and because "labels" seems specific to DNS whereas characters covers the ground for other uses. -andy From shollenbeck@verisign.com Wed Dec 11 09:27:38 2013 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 885C61AD7C0 for ; Wed, 11 Dec 2013 09:27:38 -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 P431Ry4hDRuB for ; Wed, 11 Dec 2013 09:27:36 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id A0A8E1ACB4E for ; Wed, 11 Dec 2013 09:27:32 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUqigf8jGeK0w+YUTMDFQseRvga2gUi7Z@postini.com; Wed, 11 Dec 2013 09:27:31 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rBBHRQJv006559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Dec 2013 12:27:26 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 11 Dec 2013 12:27:26 -0500 From: "Hollenbeck, Scott" To: Andy Newton , John Levine , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9pWXTuNBpmteTU2dm54umoFP7JpPPyBw Date: Wed, 11 Dec 2013 17:27:26 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F492FE143@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20131211162717.22541.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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 17:27:38 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andy Newton > Sent: Wednesday, December 11, 2013 12:22 PM > To: John Levine; weirds@ietf.org > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >=20 > On 12/11/13 11:27 AM, "John Levine" wrote: >=20 > >>>"Clients SHOULD send UTF-8 queries encoded using Normalization Form > C > >>>(NFC, [Unicode-UAX15]); note that clients might not be able to do > this > >>>reliably. Servers MUST convert to a single coded character set and > >>>normalization for the purposes of matching. Server matching using > UTF-8 > >>>in NFC is RECOMMENDED to maximize predictability and > interoperability. > >>>If > >>>the query pattern consists entirely of ASCII characters, servers > SHOULD > >>>use case-insensitive prefix matching against ASCII labels to > determine > >>>partial matches." > >>> > >>>Does this work? Please suggest specific changes if not. > >> > >> > >>In the very last sentence I would replace "ASCII labels" with "ASCII > >>characters", but this works for me. > > > >I prefer ASCII labels, contrasted to A-labels or U-labels, but I don't > >feel very strongly. Otherwise fine. > > > > >=20 > I don't feel strongly either. My reasoning for ASCII characters is to > be > consistent (the term is used in the first part of the sentence) and > because "labels" seems specific to DNS whereas characters covers the > ground for other uses. I agree, "characters" is better. Scott From edainow@afilias.info Wed Dec 11 13:58:48 2013 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 056B61AE19C for ; Wed, 11 Dec 2013 13:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 R1km6exjfWbR for ; Wed, 11 Dec 2013 13:58:46 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2531AE01E for ; Wed, 11 Dec 2013 13:58:46 -0800 (PST) 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 1Vqrnk-0000Ie-5W for weirds@ietf.org; Wed, 11 Dec 2013 21:58:40 +0000 Received: from mail-ie0-f170.google.com ([209.85.223.170]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Vqrnk-0000kI-58 for weirds@ietf.org; Wed, 11 Dec 2013 21:58:40 +0000 Received: by mail-ie0-f170.google.com with SMTP id qd12so12137997ieb.15 for ; Wed, 11 Dec 2013 13:58:35 -0800 (PST) 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=i3QpbDhWcotO000rmgM0jYFZYLvDnbfEbaZy6BsJb/o=; b=gB5G8zhZ9JbuQvZUysxgvGZF+4K7mcwdq1b5q0BxUqsQ3ESsj3+2Wopd1MDBAR8sAI 0kWczHDPO2invbtI6fUcjwqQkyZ5WPgsjJdpybW2afPDAAp1+xMrr8c4pAQwQcRkwx7B FW8rHYszqkHWATo8RwzhSvAmqclD8yptcTYb1IW31qDxZyYsKKjmMRcywiYK7c8rXDNC cap4PhswnhLvRseWS2l3V/t2R17NJvq2GZctgecXOkX3JfM8jtg6SwhMeqTHY+PAiK2Y Rix15ICRGC0UjFdWTP3qf/L/P5HrvnWmbyWH284xN+hNcH0EQ8fvEpTRHgrCQpyF71vN bRXQ== X-Gm-Message-State: ALoCoQk7XbcI+sHFYPg4LKX3LFmuxibZzxnwbkgtiS6t+JPiaX0k05KhkeYuUDHrF5RD32IG/zB+Pa9T5zisEs1m+J0jJ/YbsIYuWKd488Y8aXKjTOfr0CXURzG94hmD35SXEtibNzY3 X-Received: by 10.42.214.202 with SMTP id hb10mr2702400icb.76.1386799115192; Wed, 11 Dec 2013 13:58:35 -0800 (PST) X-Received: by 10.42.214.202 with SMTP id hb10mr2702393icb.76.1386799115054; Wed, 11 Dec 2013 13:58:35 -0800 (PST) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id hv5sm11322845igb.9.2013.12.11.13.58.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Dec 2013 13:58:34 -0800 (PST) Message-ID: <52A8E008.4060405@afilias.info> Date: Wed, 11 Dec 2013 16:58:32 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Hollenbeck, Scott" , Andrew Sullivan , "weirds@ietf.org" References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 11 Dec 2013 21:58:48 -0000 On 12/11/2013 7:51 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew >> Sullivan >> Sent: Tuesday, December 10, 2013 10:05 AM >> To: weirds@ietf.org >> Subject: Re: [weirds] using a preprocessing query parameter (was Re: >> Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) > [snip] > >> So my suggestion is that the client SHOULD send UTF-8 in NFC, with an >> explicit acknowledgement that the client may not be able to do this >> reliably; that the server in any case MUST convert to a single >> coded character set and normalization for the purposes of matching; >> and that server matching using UTF-8 in NFC is RECOMMENDED for maximal >> predictability and interoperation. > I'm going to try to speed this along by suggesting text. Here's what rdap-query-08 currently says: > > "Servers SHOULD thus accept any search pattern that is otherwise properly encoded. If the pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive prefix matching against ASCII labels to determine partial matches. If the text in the pattern is or can be converted to a U-label, servers SHOULD use prefix matching against U-labels to determine partial matches." > > Suggested new text: > > "Clients SHOULD send UTF-8 queries encoded using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably. Servers MUST convert to a single coded character set and normalization for the purposes of matching. Server matching using UTF-8 in NFC is RECOMMENDED to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive prefix matching against ASCII labels to determine partial matches." > > Does this work? Please suggest specific changes if not. > > Andrew S. also submitted an earlier comment that was more explicit and covered a few more things. I have generalized it to cover all queries (it was submitted in the context of entity searches) and merged it with the above. An RDAP client submitting a query containing one or more strings of characters that are not US-ASCII MUST convert such strings into Unicode in UTF-8 encoding. It MAY perform any local case mapping deemed necessary. It SHOULD normalize the strings using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably. An RDAP server receiving a query containing one or more strings of characters MUST treat each string as Unicode in UTF-8 encoding. If any string is not valid UTF-8, the server MAY immediately stop processing the query and return an error. Servers SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Servers MUST convert strings to the same coded character set of the target data that is to be looked up or searched and each string MUST be normalized using the same normalization that was used on the target data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximize predictability and interoperability. For domain names or nameserver lookups or searches, servers SHOULD use case-insensitive matching on US-ASCII characters. -Ernie From shollenbeck@verisign.com Thu Dec 12 06:45:35 2013 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 E13681ADF23 for ; Thu, 12 Dec 2013 06:45:35 -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 eMuGioOizDD0 for ; Thu, 12 Dec 2013 06:45:33 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id CECE91AE2F4 for ; Thu, 12 Dec 2013 06:45:12 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUqnL8rbQuxFoj2S9rOApzvVprRzjgoVi@postini.com; Thu, 12 Dec 2013 06:45:28 PST Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id rBCEj69s028150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 09:45:06 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 12 Dec 2013 09:45:05 -0500 From: "Hollenbeck, Scott" To: Ernie Dainow , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAAMS1EA== Date: Thu, 12 Dec 2013 14:45:05 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4930032C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52A8E008.4060405@afilias.info> In-Reply-To: <52A8E008.4060405@afilias.info> 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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 14:45:36 -0000 > -----Original Message----- > From: Ernie Dainow [mailto:edainow@afilias.info] > Sent: Wednesday, December 11, 2013 4:59 PM > To: Hollenbeck, Scott; Andrew Sullivan; weirds@ietf.org > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >=20 >=20 > On 12/11/2013 7:51 AM, Hollenbeck, Scott wrote: > >> -----Original Message----- > >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > >> Sullivan > >> Sent: Tuesday, December 10, 2013 10:05 AM > >> To: weirds@ietf.org > >> Subject: Re: [weirds] using a preprocessing query parameter (was Re: > >> Opinions please (was Re: comments on draft-ietf-weirds-rdap-query- > 08)) > > [snip] > > > >> So my suggestion is that the client SHOULD send UTF-8 in NFC, with > an > >> explicit acknowledgement that the client may not be able to do this > >> reliably; that the server in any case MUST convert to a single > >> coded character set and normalization for the purposes of matching; > >> and that server matching using UTF-8 in NFC is RECOMMENDED for > maximal > >> predictability and interoperation. > > I'm going to try to speed this along by suggesting text. Here's what > rdap-query-08 currently says: > > > > "Servers SHOULD thus accept any search pattern that is otherwise > properly encoded. If the pattern consists entirely of ASCII > characters, servers SHOULD use case-insensitive prefix matching against > ASCII labels to determine partial matches. If the text in the pattern > is or can be converted to a U-label, servers SHOULD use prefix matching > against U-labels to determine partial matches." > > > > Suggested new text: > > > > "Clients SHOULD send UTF-8 queries encoded using Normalization Form C > (NFC, [Unicode-UAX15]); note that clients might not be able to do this > reliably. Servers MUST convert to a single coded character set and > normalization for the purposes of matching. Server matching using UTF-8 > in NFC is RECOMMENDED to maximize predictability and interoperability. > If the query pattern consists entirely of ASCII characters, servers > SHOULD use case-insensitive prefix matching against ASCII labels to > determine partial matches." > > > > Does this work? Please suggest specific changes if not. > > > > > Andrew S. also submitted an earlier comment that was more explicit and > covered a few more things. I have generalized it to cover all queries > (it was submitted in the context of entity searches) and merged it with > the above. >=20 > An RDAP client submitting a query containing one or more strings of > characters that are not US-ASCII MUST convert such strings into Unicode > in UTF-8 encoding. It MAY perform any local case mapping deemed > necessary. It SHOULD normalize the strings using Normalization Form C > (NFC, [Unicode-UAX15]); note that clients might not be able to do this > reliably. >=20 > An RDAP server receiving a query containing one or more strings of > characters MUST treat each string as Unicode in UTF-8 encoding. If any > string is not valid UTF-8, the server MAY immediately stop processing > the query and return an error. Servers SHOULD map fullwidth and > halfwidth characters to their decomposition equivalents. Servers MUST > convert strings to the same coded character set of the target data that > is to be looked up or searched and each string MUST be normalized using > the same normalization that was used on the target data. Normalization > Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA > [RFC5891] and to maximize predictability and interoperability. >=20 > For domain names or nameserver lookups or searches, servers SHOULD use > case-insensitive matching on US-ASCII characters. I can live with this version, too, though it's much more prescriptive. One = question, though: what exactly does "a query containing one or more strings= of characters" look like? Scott From edainow@afilias.info Thu Dec 12 07:16:21 2013 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 39EEF1ADF47 for ; Thu, 12 Dec 2013 07:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 UWhDVwHS1o44 for ; Thu, 12 Dec 2013 07:16:18 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA4B1AD34C for ; Thu, 12 Dec 2013 07:16:18 -0800 (PST) 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 1Vr7zo-0000Lr-4b for weirds@ietf.org; Thu, 12 Dec 2013 15:16:12 +0000 Received: from mail-ie0-f176.google.com ([209.85.223.176]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Vr7zo-0000g2-49 for weirds@ietf.org; Thu, 12 Dec 2013 15:16:12 +0000 Received: by mail-ie0-f176.google.com with SMTP id at1so766997iec.35 for ; Thu, 12 Dec 2013 07:16:06 -0800 (PST) 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=v3i3fN9iT7DSP2E3wYzOI9yGuNZfhQLZODmvn5DZ5pA=; b=cETyFd4LFOJPdGOmPbM2ce8T3v+n4ogEjx9H/ZzOxP5qqjPrFOpKL4Z4bwPacbpvVs 5zwM/vFvZ5hAj9TBxaSZYjm20w45/5kMGrK9+TJmxisYWzl8uxh56qIEBIwhwJT0YV5t P51bxh4I4czrR5p/L1jLCj1jADYPGdoESY25mDThIc6mt04K/JekXZJ1DVdpiqXQG8Qr /6NiJEy1CNeISyUzAbIocr3mg82RA7JOOWvO9+YjkqcuvsJDUNYw3R0Fc57V1uQydU9B O9sMYWwi2z35jtEOQ9snApb1kjMp8wOwHNNiJRAEdQdHxDXfNq7IL+/7bH8R3RRSrwfO RWag== X-Gm-Message-State: ALoCoQmkfu/JBUpoGBZForuYNv8S0skrvTeDxT86d0NolXZIZLsia1659SwiC4sxPiAS/CB8Qd2vtnDMVzqKWRiWMF3YBPcqZE0BpkKGpVQkHy+ErLTYSNBUskkcY60ixpgy1RNM6i8H X-Received: by 10.43.170.130 with SMTP id nq2mr6076114icc.69.1386861366780; Thu, 12 Dec 2013 07:16:06 -0800 (PST) X-Received: by 10.43.170.130 with SMTP id nq2mr6076096icc.69.1386861366611; Thu, 12 Dec 2013 07:16:06 -0800 (PST) Received: from [10.10.68.31] (tor-gateway.afilias.info. [199.15.87.4]) by mx.google.com with ESMTPSA id f5sm15445440igc.4.2013.12.12.07.16.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Dec 2013 07:16:05 -0800 (PST) Message-ID: <52A9D333.1040003@afilias.info> Date: Thu, 12 Dec 2013 10:16:03 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Hollenbeck, Scott" , "weirds@ietf.org" References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F4930032C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4930032C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 15:16:21 -0000 On 12/12/2013 9:45 AM, Hollenbeck, Scott wrote: >> -----Original Message----- >> From: Ernie Dainow [mailto:edainow@afilias.info] >> Sent: Wednesday, December 11, 2013 4:59 PM >> To: Hollenbeck, Scott; Andrew Sullivan; weirds@ietf.org >> Subject: Re: [weirds] using a preprocessing query parameter (was Re: >> Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >> >> >> On 12/11/2013 7:51 AM, Hollenbeck, Scott wrote: >>>> -----Original Message----- >>>> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew >>>> Sullivan >>>> Sent: Tuesday, December 10, 2013 10:05 AM >>>> To: weirds@ietf.org >>>> Subject: Re: [weirds] using a preprocessing query parameter (was Re: >>>> Opinions please (was Re: comments on draft-ietf-weirds-rdap-query- >> 08)) >>> [snip] >>> >>>> So my suggestion is that the client SHOULD send UTF-8 in NFC, with >> an >>>> explicit acknowledgement that the client may not be able to do this >>>> reliably; that the server in any case MUST convert to a single >>>> coded character set and normalization for the purposes of matching; >>>> and that server matching using UTF-8 in NFC is RECOMMENDED for >> maximal >>>> predictability and interoperation. >>> I'm going to try to speed this along by suggesting text. Here's what >> rdap-query-08 currently says: >>> "Servers SHOULD thus accept any search pattern that is otherwise >> properly encoded. If the pattern consists entirely of ASCII >> characters, servers SHOULD use case-insensitive prefix matching against >> ASCII labels to determine partial matches. If the text in the pattern >> is or can be converted to a U-label, servers SHOULD use prefix matching >> against U-labels to determine partial matches." >>> Suggested new text: >>> >>> "Clients SHOULD send UTF-8 queries encoded using Normalization Form C >> (NFC, [Unicode-UAX15]); note that clients might not be able to do this >> reliably. Servers MUST convert to a single coded character set and >> normalization for the purposes of matching. Server matching using UTF-8 >> in NFC is RECOMMENDED to maximize predictability and interoperability. >> If the query pattern consists entirely of ASCII characters, servers >> SHOULD use case-insensitive prefix matching against ASCII labels to >> determine partial matches." >>> Does this work? Please suggest specific changes if not. >>> >>> >> Andrew S. also submitted an earlier comment that was more explicit and >> covered a few more things. I have generalized it to cover all queries >> (it was submitted in the context of entity searches) and merged it with >> the above. >> >> An RDAP client submitting a query containing one or more strings of >> characters that are not US-ASCII MUST convert such strings into Unicode >> in UTF-8 encoding. It MAY perform any local case mapping deemed >> necessary. It SHOULD normalize the strings using Normalization Form C >> (NFC, [Unicode-UAX15]); note that clients might not be able to do this >> reliably. >> >> An RDAP server receiving a query containing one or more strings of >> characters MUST treat each string as Unicode in UTF-8 encoding. If any >> string is not valid UTF-8, the server MAY immediately stop processing >> the query and return an error. Servers SHOULD map fullwidth and >> halfwidth characters to their decomposition equivalents. Servers MUST >> convert strings to the same coded character set of the target data that >> is to be looked up or searched and each string MUST be normalized using >> the same normalization that was used on the target data. Normalization >> Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA >> [RFC5891] and to maximize predictability and interoperability. >> >> For domain names or nameserver lookups or searches, servers SHOULD use >> case-insensitive matching on US-ASCII characters. > I can live with this version, too, though it's much more prescriptive. One question, though: what exactly does "a query containing one or more strings of characters" look like? In the case of search the query is domains?name= I was trying to separate out the query "string" in angle brackets from the whole query as defined. In the case of a future boolean search, there would be more than one string. If this is confusing and too general for our purposes now, then this can be simplified by simply dropping the phrase "one or more strings of characters" and just use "query". -Ernie From andy@arin.net Thu Dec 12 07:48:08 2013 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 71D0A1AE31C for ; Thu, 12 Dec 2013 07:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 6Ke9pbSeSZji for ; Thu, 12 Dec 2013 07:48:02 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 039901ADF64 for ; Thu, 12 Dec 2013 07:48:02 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 295DD165520; Thu, 12 Dec 2013 10:47:56 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id 6FAE51654ED; Thu, 12 Dec 2013 10:47:54 -0500 (EST) Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 12 Dec 2013 10:47:54 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 10:47:51 -0500 From: Andy Newton To: Ernie Dainow , "Hollenbeck, Scott" , Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9blCd+hQSwqw9EqvqqS9C1Tm7JpPR9cAgACYywCAANbygA== Date: Thu, 12 Dec 2013 15:47:51 +0000 Message-ID: In-Reply-To: <52A8E008.4060405@afilias.info> 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: text/plain; charset="us-ascii" Content-ID: <2E2F4B703EF92143B4F4B2C5AF26F91E@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 15:48:08 -0000 On 12/11/13 4:58 PM, "Ernie Dainow" wrote: >An RDAP client submitting a query containing one or more strings of >characters that are not US-ASCII MUST convert such strings into Unicode >in UTF-8 encoding. The MUST here is inconsistent with the direction of these threads regarding what a client may and may not do. I believe the MUST should be a SHOULD. > It MAY perform any local case mapping deemed >necessary. It SHOULD normalize the strings using Normalization Form C >(NFC, [Unicode-UAX15]); note that clients might not be able to do this >reliably. > >An RDAP server receiving a query containing one or more strings of >characters MUST treat each string as Unicode in UTF-8 encoding. If any >string is not valid UTF-8, the server MAY immediately stop processing >the query and return an error. Servers SHOULD map fullwidth and >halfwidth characters to their decomposition equivalents. Servers MUST >convert strings to the same coded character set of the target data that >is to be looked up or searched and each string MUST be normalized using >the same normalization that was used on the target data. Normalization >Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA >[RFC5891] and to maximize predictability and interoperability. > >For domain names or nameserver lookups or searches, servers SHOULD use >case-insensitive matching on US-ASCII characters. Given that this last sentence is a SHOULD and not a MUST, I fail to see why any of the normalizations are MUST instead of SHOULD. These behaviors are recommended (I.e SHOULD) because there is a potential for non-interoperability if the recommendation is not followed but non-interoperability is not a guarantee. On this, I don't care strongly though. -andy From ajs@anvilwalrusden.com Thu Dec 12 10:56:36 2013 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 9ABDF1AE3CD for ; Thu, 12 Dec 2013 10:56:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 y8HoxQV1oter for ; Thu, 12 Dec 2013 10:56:35 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 572361AE073 for ; Thu, 12 Dec 2013 10:56:35 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D4BA68A036 for ; Thu, 12 Dec 2013 18:56:28 +0000 (UTC) Date: Thu, 12 Dec 2013 13:56:27 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131212185627.GE37156@mx1.yitter.info> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 18:56:36 -0000 On Wed, Dec 11, 2013 at 12:51:40PM +0000, Hollenbeck, Scott wrote: > Suggested new text: > > "Clients SHOULD send UTF-8 queries encoded using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably. Servers MUST convert to a single coded character set and normalization for the purposes of matching. Server matching using UTF-8 in NFC is RECOMMENDED to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive prefix matching against ASCII labels to determine partial matches." > > Does this work? Please suggest specific changes if not. Sorry I didn't get to this first (it's all-hands week at Dyn). I think that looks reasonable, yes. Thanks. -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Dec 12 10:58:39 2013 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 8E5911AE3B3 for ; Thu, 12 Dec 2013 10:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 p0EL6qb2Za-b for ; Thu, 12 Dec 2013 10:58:38 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id BD4F21AE170 for ; Thu, 12 Dec 2013 10:58:38 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 257F28A036 for ; Thu, 12 Dec 2013 18:58:32 +0000 (UTC) Date: Thu, 12 Dec 2013 13:58:31 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131212185830.GF37156@mx1.yitter.info> References: <20131211162717.22541.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131211162717.22541.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 18:58:39 -0000 On Wed, Dec 11, 2013 at 04:27:17PM -0000, John Levine wrote: > > I prefer ASCII labels, contrasted to A-labels or U-labels, but I don't > feel very strongly. Otherwise fine. If the goal is to draw the distinction with A-labels and U-labels, IDNA2008 has the (awkward) term "NR-LDH label". The precision might be helpful, because of course an A-label is always an all-ASCII label, but string matching in it is not what we want I presume. A -- Andrew Sullivan ajs@anvilwalrusden.com From ajs@anvilwalrusden.com Thu Dec 12 11:02:19 2013 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 77BF71AE159 for ; Thu, 12 Dec 2013 11:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Yz2-sB6XJM_z for ; Thu, 12 Dec 2013 11:02:17 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFC11AE138 for ; Thu, 12 Dec 2013 11:02:17 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D37578A031 for ; Thu, 12 Dec 2013 19:02:10 +0000 (UTC) Date: Thu, 12 Dec 2013 14:02:09 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131212190209.GG37156@mx1.yitter.info> References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52A8E008.4060405@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52A8E008.4060405@afilias.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 19:02:19 -0000 On Wed, Dec 11, 2013 at 04:58:32PM -0500, Ernie Dainow wrote: > An RDAP server receiving a query containing one or more strings of > characters MUST treat each string as Unicode in UTF-8 encoding. I originally thought that, but of course the client can use the Content-Type to set the character set explicitly, I guess, no? > processing the query and return an error. Servers SHOULD map > fullwidth and halfwidth characters to their decomposition > equivalents. Servers MUST convert strings to the same coded > character set of the target data that is to be looked up or searched > and each string MUST be normalized using the same normalization that > was used on the target data. Normalization Form C (NFC, > [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] > and to maximize predictability and interoperability. This stuff was intended basically to make a precis profile in mini. I do think that's a better idea, but I got the impression that the WG didn't agree. These additions are my preference, however. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Thu Dec 12 11:21:23 2013 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 A78691AE3F2 for ; Thu, 12 Dec 2013 11:21:23 -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 LOOFyDceYMah for ; Thu, 12 Dec 2013 11:21:22 -0800 (PST) Received: from exprod6og125.obsmtp.com (exprod6og125.obsmtp.com [64.18.1.218]) by ietfa.amsl.com (Postfix) with ESMTP id 49BA91AE3EB for ; Thu, 12 Dec 2013 11:20:59 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob125.postini.com ([64.18.5.12]) with SMTP ID DSNKUqoMlfEUsDFEI08Ed+KsIwGdZ/LSiDg/@postini.com; Thu, 12 Dec 2013 11:21:16 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 rBCJKqSK004080 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 14:20:52 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 12 Dec 2013 14:20:51 -0500 From: "Hollenbeck, Scott" To: Andy Newton , Ernie Dainow , "Andrew Sullivan" , "weirds@ietf.org" Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAASrEgP//5Cnw Date: Thu, 12 Dec 2013 19:20:50 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A8E008.4060405@afilias.info> 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 Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 12 Dec 2013 19:21:23 -0000 > -----Original Message----- > From: Andy Newton [mailto:andy@arin.net] > Sent: Thursday, December 12, 2013 10:48 AM > To: Ernie Dainow; Hollenbeck, Scott; Andrew Sullivan; weirds@ietf.org > Subject: Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) >=20 > On 12/11/13 4:58 PM, "Ernie Dainow" wrote: >=20 > >An RDAP client submitting a query containing one or more strings of > >characters that are not US-ASCII MUST convert such strings into > Unicode > >in UTF-8 encoding. >=20 > The MUST here is inconsistent with the direction of these threads > regarding what a client may and may not do. I believe the MUST should > be a > SHOULD. >=20 > > It MAY perform any local case mapping deemed > >necessary. It SHOULD normalize the strings using Normalization Form C > >(NFC, [Unicode-UAX15]); note that clients might not be able to do this > >reliably. > > > >An RDAP server receiving a query containing one or more strings of > >characters MUST treat each string as Unicode in UTF-8 encoding. If any > >string is not valid UTF-8, the server MAY immediately stop processing > >the query and return an error. Servers SHOULD map fullwidth and > >halfwidth characters to their decomposition equivalents. Servers MUST > >convert strings to the same coded character set of the target data > that > >is to be looked up or searched and each string MUST be normalized > using > >the same normalization that was used on the target data. Normalization > >Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with > IDNA > >[RFC5891] and to maximize predictability and interoperability. > > > >For domain names or nameserver lookups or searches, servers SHOULD use > >case-insensitive matching on US-ASCII characters. >=20 > Given that this last sentence is a SHOULD and not a MUST, I fail to see > why any of the normalizations are MUST instead of SHOULD. These > behaviors > are recommended (I.e SHOULD) because there is a potential for > non-interoperability if the recommendation is not followed but > non-interoperability is not a guarantee. On this, I don't care strongly > though. I care strongly about coming to agreement on text ;), so how do we all feel= about Andy's suggestion to use SHOULD instead of MUST? That is: An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not = be able to do this reliably. An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error. Servers SHOULD map fullwidth and halfwidth= characters to their decomposition equivalents. Servers SHOULD convert stri= ngs to the same coded character set of the target data that is to be looked= up or searched and each string SHOULD be normalized using the same normali= zation that was used on the target data. Normalization Form C (NFC, [Unicod= e-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximi= ze predictability and interoperability. If the query pattern consists entir= ely of ASCII characters, servers SHOULD use case-insensitive matching again= st ASCII characters to determine matches. I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer? Scott From edainow@afilias.info Fri Dec 13 08:08:07 2013 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 8AF7C1ADFC6 for ; Fri, 13 Dec 2013 08:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 nlugqCNy12Vs for ; Fri, 13 Dec 2013 08:08:05 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id C59841AD9AC for ; Fri, 13 Dec 2013 08:08:05 -0800 (PST) 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 1VrVHT-0004wQ-3w for weirds@ietf.org; Fri, 13 Dec 2013 16:07:59 +0000 Received: from mail-ie0-f179.google.com ([209.85.223.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VrVHT-0000Rz-3g for weirds@ietf.org; Fri, 13 Dec 2013 16:07:59 +0000 Received: by mail-ie0-f179.google.com with SMTP id x13so3092444ief.38 for ; Fri, 13 Dec 2013 08:07:53 -0800 (PST) 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=qrvcNdCQYQIYkZm0XNEW8dCtqr0+WRxjGJLLleett0A=; b=RtVh+C9Nt4/YOeMv69CShqd9qJTmok6KvM+2SeMS8jMRS/joDvTlBdWwVD5hPOJiqY TChOWffUjJqv1L//R4Ev2X5c3sZbW5CmIAqxVYwXyX/k4AZmfsJpnB0amObyQ3Q0GbpA LVV+ABLJlk4me6DoB+J+8PTsIXdvpNmyRFnsOGzZcIkYcTVcjQC4tLA30HedjrTR/fqZ 9zeZgr5FMg/Sz5QuvWzkL5xhydkDRv+0hkbgPtUPJknZuO2Rq4r16VXsUSVkIJ24vg6t 4H2KH78Lfc2n8u/Zv/mB4C5MddfD1XfgR7bejrLfo/0uHEg10jBAxiG+reKvSjYuXtzC N/vw== X-Gm-Message-State: ALoCoQmZkOv3uR1GhC/QeMQy7KdBx1TxZNINcdj/k2YB1fXTjFEiZabGkErvPJB44Jt0BPi5yohQ72J/rvWLsuF3AOq6dtPNOr72gxT0ygHuYnnTZLIU3DH23BLpAcwsQx9mqie5t0g5 X-Received: by 10.43.137.71 with SMTP id in7mr481318icc.97.1386950873712; Fri, 13 Dec 2013 08:07:53 -0800 (PST) X-Received: by 10.43.137.71 with SMTP id in7mr481306icc.97.1386950873588; Fri, 13 Dec 2013 08:07:53 -0800 (PST) Received: from [192.168.2.21] (bas5-toronto47-845522795.dsl.bell.ca. [50.101.167.107]) by mx.google.com with ESMTPSA id p5sm4950629igj.10.2013.12.13.08.07.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 08:07:52 -0800 (PST) Message-ID: <52AB30C4.50100@afilias.info> Date: Fri, 13 Dec 2013 11:07:32 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Sullivan , weirds@ietf.org References: <52A62E10.7070705@viagenie.ca> <713F2E94-A9CB-4069-8530-8C1260A36536@viagenie.ca> <20131210150523.GE34669@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F492FDB1C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52A8E008.4060405@afilias.info> <20131212190209.GG37156@mx1.yitter.info> In-Reply-To: <20131212190209.GG37156@mx1.yitter.info> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 16:08:07 -0000 On 2013-12-12 2:02 PM, Andrew Sullivan wrote: > On Wed, Dec 11, 2013 at 04:58:32PM -0500, Ernie Dainow wrote: >> An RDAP server receiving a query containing one or more strings of >> characters MUST treat each string as Unicode in UTF-8 encoding. > I originally thought that, but of course the client can use the > Content-Type to set the character set explicitly, I guess, no? Content-Type is only for the body. All RDAP queries defined so far contain the query string in the URI and no body. Does a client have any options of how to encode the URI? -Ernie From edainow@afilias.info Fri Dec 13 08:25:31 2013 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 C6A381AE6C5 for ; Fri, 13 Dec 2013 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 7Dvk1HcxyFGr for ; Fri, 13 Dec 2013 08:25:30 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC561AE22D for ; Fri, 13 Dec 2013 08:25:30 -0800 (PST) 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 1VrVYJ-0006f9-5m for weirds@ietf.org; Fri, 13 Dec 2013 16:25:23 +0000 Received: from mail-ea0-f179.google.com ([209.85.215.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VrVYJ-0001XS-4x for weirds@ietf.org; Fri, 13 Dec 2013 16:25:23 +0000 Received: by mail-ea0-f179.google.com with SMTP id r15so988892ead.38 for ; Fri, 13 Dec 2013 08:25:17 -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=t6yITzO07G2cHJQProsXeN+bELERRmQ+VdFPz/wSiVI=; b=MOMUSCs7eSexorSgHJLpnulUTw4OMNBeZsABTv6r0XiG3DO6oHS31gN2dtw91D9nOF tf75VNvY47t37mrYbK9yLhQ0hg4nvJyknKAzvkeicONpIOtdAyY73PxJKDSx2V1AXKaH P5p/31qdzOfveHaD9p/pmfFrpVoxKYmNoQVGPsBt8y2klhEP2F6VcigGutaN5PCvQV6G eeZ0biPcDhYKrcWTjvgZsaCUhqxQ3cdAyqQpIrnvVIdrc16KsPlFes3S08QKmbwCUJWQ uw8yv+afpSzWAOBVcj1tFCIxi2dP/UBzUtbLbwg322xF5J4oAuTg3ww3ZcSx6XlbzF8x VEiA== X-Gm-Message-State: ALoCoQkQYaKsrhIuhInC7UYgoeTXGn8S0ofSdakwRKg12cDQh0DPL1S8wtluvvaXCaHXEogjapim6ZMgE45Aw1Jue2zFsbI1Z6tm8Emsu+LujdyVNmM3SBky6L4YOfas+eeGgUE0bnJl X-Received: by 10.14.205.201 with SMTP id j49mr3760660eeo.85.1386951917517; Fri, 13 Dec 2013 08:25:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.14.205.201 with SMTP id j49mr3760647eeo.85.1386951917342; Fri, 13 Dec 2013 08:25:17 -0800 (PST) Received: by 10.14.201.8 with HTTP; Fri, 13 Dec 2013 08:25:17 -0800 (PST) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Fri, 13 Dec 2013 11:25:17 -0500 Message-ID: From: Ernie Dainow To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=047d7b34387c5aa13604ed6ce80d Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 16:25:32 -0000 --047d7b34387c5aa13604ed6ce80d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott wrote: > > I care strongly about coming to agreement on text ;), so how do we all > feel about Andy's suggestion to use SHOULD instead of MUST? That is: > > An RDAP client submitting a query string containing non-ASCII characters > SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform > any local case mapping deemed necessary. It SHOULD normalize the strings > using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might > not be able to do this reliably. > > An RDAP server SHOULD treat each query string as Unicode in UTF-8 > encoding. If a string is not valid UTF-8, the server MAY immediately stop > processing the query and return an error. Servers SHOULD map fullwidth and > halfwidth characters to their decomposition equivalents. Servers SHOULD > convert strings to the same coded character set of the target data that is > to be looked up or searched and each string SHOULD be normalized using the > same normalization that was used on the target data. Normalization Form C > (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] > and to maximize predictability and interoperability. If the query pattern > consists entirely of ASCII characters, servers SHOULD use case-insensitive > matching against ASCII characters to determine matches. > > I'm going to have to see which error is appropriate to return in this > context, but is this getting closer? > > Scott > In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies: uuuu.aaa does not match uuu.AAA aaa-uuu.aaa does not match AAA-uuu.aaa (where u is Unicode, a is ASCII character) -Ernie --047d7b34387c5aa13604ed6ce80d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott <<= a href=3D"mailto:shollenbeck@verisign.com" target=3D"_blank">shollenbeck@ve= risign.com> wrote:

I care strongly about coming t= o agreement on text ;), so how do we all feel about Andy's suggestion t= o use SHOULD instead of MUST? That is:

An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not = be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error. =A0Servers SHOULD map fullwidth and halfwid= th characters to their decomposition equivalents. Servers SHOULD convert st= rings to the same coded character set of the target data that is to be look= ed up or searched and each string SHOULD be normalized using the same norma= lization that was used on the target data. Normalization Form C (NFC, [Unic= ode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maxi= mize predictability and interoperability. If the query pattern consists ent= irely of ASCII characters, servers SHOULD use case-insensitive matching aga= inst ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this c= ontext, but is this getting closer?

Scott

In the last sentence, is there a particular reason that ASCII case insensi= tive matching is done only when the whole string is ASCII rather than chara= cter by character? This results in a number of inconsistencies:

uuuu.aaa = =A0 =A0 =A0 does not match =A0uuu.AAA
aaa-u= uu.aaa =A0does not match =A0AAA-uuu.aaa
(where u is Unicode, a is ASCII character)
=
-Ernie
--047d7b34387c5aa13604ed6ce80d-- From shollenbeck@verisign.com Fri Dec 13 08:53:56 2013 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 20E9A1ADEB7 for ; Fri, 13 Dec 2013 08:53:56 -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 8uj_uo1W3OfD for ; Fri, 13 Dec 2013 08:53:52 -0800 (PST) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 942001AE047 for ; Fri, 13 Dec 2013 08:53:31 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKUqs7hKYsNM0KmojBv2KdFmDpJILOGTVS@postini.com; Fri, 13 Dec 2013 08:53:46 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 rBDGrOED013244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 11:53:24 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Dec 2013 11:53:24 -0500 From: "Hollenbeck, Scott" To: Ernie Dainow Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAASrEgP//5CnwgAG4oYD//6700A== Date: Fri, 13 Dec 2013 16:53:23 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.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_831693C2CDA2E849A7D7A712B24E257F4930294EBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 16:53:56 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F4930294EBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 11:25 AM To: Hollenbeck, Scott Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott > wrote: I care strongly about coming to agreement on text ;), so how do we all feel= about Andy's suggestion to use SHOULD instead of MUST? That is: An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not = be able to do this reliably. An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error. Servers SHOULD map fullwidth and halfwidth= characters to their decomposition equivalents. Servers SHOULD convert stri= ngs to the same coded character set of the target data that is to be looked= up or searched and each string SHOULD be normalized using the same normali= zation that was used on the target data. Normalization Form C (NFC, [Unicod= e-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximi= ze predictability and interoperability. If the query pattern consists entir= ely of ASCII characters, servers SHOULD use case-insensitive matching again= st ASCII characters to determine matches. I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer? Scott In the last sentence, is there a particular reason that ASCII case insensit= ive matching is done only when the whole string is ASCII rather than charac= ter by character? This results in a number of inconsistencies: uuuu.aaa does not match uuu.AAA aaa-uuu.aaa does not match AAA-uuu.aaa (where u is Unicode, a is ASCII character) ASCII characters are also UTF-8-encoded Unicode characters. You could just = as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the U= nicode processing text applies, right? The point I'm trying to get across i= s that a query pattern that contains only ASCII characters does not need to= be subjected to the normalization processing used for patterns that contai= n non-ASCII characters. Is this better? "A query pattern that contains only ASCII characters does not need to be no= rmalized. Case-insensitive character comparison SHOULD be used to determine= matches for these patterns." Please suggest text if I'm still missing your point. Scott --_000_831693C2CDA2E849A7D7A712B24E257F4930294EBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Ernie Da= inow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

 

I care strongly about coming to agreement on text ;)= , so how do we all feel about Andy's suggestion to use SHOULD instead of MU= ST? That is:

An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error.  Servers SHOULD map fullwidth and half= width characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character se= t of the target data that is to be looked up or searched and each string SH= OULD be normalized using the same normalization that was used on the target= data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and t= o maximize predictability and interoperability. If the query pattern consis= ts entirely of ASCII characters, servers SHOULD use case-insensitive matchi= ng against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer?

Scott

 

In the last sentence, is there a particular reason t= hat ASCII case insensitive matching is done only when the whole string is A= SCII rather than character by character? This results in a number of incons= istencies:

 

uuuu.aaa       does not match  u= uu.AAA

aaa-uuu.aaa  does not match  AAA-uuu.aaa

 

(where u is Unicode, a is ASCII character)

 

ASCII characters are also UTF-8-encoded Un= icode characters. You could just as well re-write those patterns as uuuu.uu= u and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I’m trying to get across is that a query p= attern that contains only ASCII characters does not need to be subjected to= the normalization processing used for patterns that contain non-ASCII char= acters. Is this better?

 

“A query pattern that contains only = ASCII characters does not need to be normalized. Case-insensitive character= comparison SHOULD be used to determine matches for these patterns.”<= o:p>

 

Please suggest text if I’m still mis= sing your point.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F4930294EBRN1WNEXMBX01vc_-- From edainow@afilias.info Fri Dec 13 10:14:12 2013 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 31AA51ADF5C for ; Fri, 13 Dec 2013 10:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 0LN-Fyx1MDh3 for ; Fri, 13 Dec 2013 10:14:08 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9F61AD939 for ; Fri, 13 Dec 2013 10:14:07 -0800 (PST) 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 1VrXFR-0001kD-46 for weirds@ietf.org; Fri, 13 Dec 2013 18:14:01 +0000 Received: from mail-ie0-f171.google.com ([209.85.223.171]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VrXFR-0000XR-3g for weirds@ietf.org; Fri, 13 Dec 2013 18:14:01 +0000 Received: by mail-ie0-f171.google.com with SMTP id ar20so3342125iec.16 for ; Fri, 13 Dec 2013 10:13:55 -0800 (PST) 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=qTktwN0pvv+/j6KUvv7oPZaYgtgoaMd9h0yp0+773Jk=; b=a7d0lWxUFM/w1S5SJ29sqT2MTKqj1pBfkmNJXhygu6SR1PEeClhOOf+tpzb9G0J4Zu QFM6EMDylcVCOKTHqy3arCN1jsSg1UrB9OdhLTUWRG/KUhPs5vrbZi+h1w3J/ip0fEIL vKE1xSID1SEDTabYRy/C8XEr4vTiX9Mxp+IhEpna3HT6I0nVVpdsPkuImGmxNXzPGjUR eY/q21N15NKfUEO1AbnBRVmfmggnngPm5KTQ5Y2YBtJtRBfl1PGdy1FeE1SsC9A/rZ/S 98JF/W54hES1snOwZFDMCJhT9Da7gHSKKisRHWX3FMuBRpVu11GeqfVzahZuxOYJnv1B 4w/w== X-Gm-Message-State: ALoCoQn+QCN/r4PaFmwJ80dhA1Ae95FqswQJnHluYnK95Cx+J5wGGuZW0xZfjwOzJPnVcEckwhbfK/EhAJvBOVU4S3bvmZt48YEG5+Yfab8dTQmvgSg6fq4Y6rRJZitHPlebr+3k087i X-Received: by 10.50.50.70 with SMTP id a6mr3942673igo.1.1386958435670; Fri, 13 Dec 2013 10:13:55 -0800 (PST) X-Received: by 10.50.50.70 with SMTP id a6mr3942658igo.1.1386958435418; Fri, 13 Dec 2013 10:13:55 -0800 (PST) Received: from [192.168.2.21] (bas5-toronto47-845522795.dsl.bell.ca. [50.101.167.107]) by mx.google.com with ESMTPSA id o1sm5721972igh.9.2013.12.13.10.13.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 10:13:53 -0800 (PST) Message-ID: <52AB4E60.8060205@afilias.info> Date: Fri, 13 Dec 2013 13:13:52 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary="------------010208010003070904000802" Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 18:14:12 -0000 This is a multi-part message in MIME format. --------------010208010003070904000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote: > > *From:*Ernie Dainow [mailto:edainow@afilias.info] > *Sent:* Friday, December 13, 2013 11:25 AM > *To:* Hollenbeck, Scott > *Cc:* Andy Newton; Andrew Sullivan; weirds@ietf.org > *Subject:* Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) > > On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott > > wrote: > > I care strongly about coming to agreement on text ;), so how do we all > feel about Andy's suggestion to use SHOULD instead of MUST? That is: > > An RDAP client submitting a query string containing non-ASCII > characters SHOULD convert such strings into Unicode in UTF-8 encoding. > It MAY perform any local case mapping deemed necessary. It SHOULD > normalize the strings using Normalization Form C (NFC, > [Unicode-UAX15]); note that clients might not be able to do this reliably. > > An RDAP server SHOULD treat each query string as Unicode in UTF-8 > encoding. If a string is not valid UTF-8, the server MAY immediately > stop processing the query and return an error. Servers SHOULD map > fullwidth and halfwidth characters to their decomposition equivalents. > Servers SHOULD convert strings to the same coded character set of the > target data that is to be looked up or searched and each string SHOULD > be normalized using the same normalization that was used on the target > data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be > consistent with IDNA [RFC5891] and to maximize predictability and > interoperability. If the query pattern consists entirely of ASCII > characters, servers SHOULD use case-insensitive matching against ASCII > characters to determine matches. > > I'm going to have to see which error is appropriate to return in this > context, but is this getting closer? > > Scott > > In the last sentence, is there a particular reason that ASCII case > insensitive matching is done only when the whole string is ASCII > rather than character by character? This results in a number of > inconsistencies: > > uuuu.aaa does not match uuu.AAA > > aaa-uuu.aaa does not match AAA-uuu.aaa > > (where u is Unicode, a is ASCII character) > > ASCII characters are also UTF-8-encoded Unicode characters. You could > just as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and > then the Unicode processing text applies, right? The point I'm trying > to get across is that a query pattern that contains only ASCII > characters does not need to be subjected to the normalization > processing used for patterns that contain non-ASCII characters. Is > this better? > > "A query pattern that contains only ASCII characters does not need to > be normalized. Case-insensitive character comparison SHOULD be used to > determine matches for these patterns." > > Please suggest text if I'm still missing your point. > > Scott > Normalization does not do any case folding, so this results in the inconsistencies above. ASCII case insensitive matching should be done on all strings, not just those that are entirely ASCII. Excluding handles which are case sensitive. Suggested text to replace last sentence: For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters. "US-ASCII" seems to be preferred in standards to "ASCII", http://www.iana.org/assignments/character-sets/character-sets.xhtml -Ernie --------------010208010003070904000802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote:

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

 

I care strongly about coming to agreement on text ;), so how do we all feel about Andy's suggestion to use SHOULD instead of MUST? That is:

An RDAP client submitting a query string containing non-ASCII characters SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform any local case mapping deemed necessary. It SHOULD normalize the strings using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server MAY immediately stop processing the query and return an error.  Servers SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character set of the target data that is to be looked up or searched and each string SHOULD be normalized using the same normalization that was used on the target data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this context, but is this getting closer?

Scott

 

In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies:

 

uuuu.aaa       does not match  uuu.AAA

aaa-uuu.aaa  does not match  AAA-uuu.aaa

 

(where u is Unicode, a is ASCII character)

 

ASCII characters are also UTF-8-encoded Unicode characters. You could just as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I’m trying to get across is that a query pattern that contains only ASCII characters does not need to be subjected to the normalization processing used for patterns that contain non-ASCII characters. Is this better?

 

“A query pattern that contains only ASCII characters does not need to be normalized. Case-insensitive character comparison SHOULD be used to determine matches for these patterns.”

 

Please suggest text if I’m still missing your point.

 

Scott


Normalization does not do any case folding, so this results in the inconsistencies above. ASCII case insensitive matching should be done on all strings, not just those that are entirely ASCII. Excluding handles which are case sensitive.

Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters.

"US-ASCII" seems to be preferred in standards to "ASCII", http://www.iana.org/assignments/character-sets/character-sets.xhtml

-Ernie
--------------010208010003070904000802-- From shollenbeck@verisign.com Fri Dec 13 10:21:33 2013 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 DD0A61AD8F0 for ; Fri, 13 Dec 2013 10:21: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 zDRyOIE87TRQ for ; Fri, 13 Dec 2013 10:21:30 -0800 (PST) Received: from exprod6og126.obsmtp.com (exprod6og126.obsmtp.com [64.18.1.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCAC1AE10A for ; Fri, 13 Dec 2013 10:21:09 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob126.postini.com ([64.18.5.12]) with SMTP ID DSNKUqtQDi4hhnvZ6qkWYnYB66wBmr/qnBSV@postini.com; Fri, 13 Dec 2013 10:21:23 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 rBDIL2Q7016039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 13:21:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Dec 2013 13:21:01 -0500 From: "Hollenbeck, Scott" To: Ernie Dainow Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAASrEgP//5CnwgAG4oYD//6700IAAb2IA//+s2jA= Date: Fri, 13 Dec 2013 18:21:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> In-Reply-To: <52AB4E60.8060205@afilias.info> 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_831693C2CDA2E849A7D7A712B24E257F49302A40BRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 18:21:34 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49302A40BRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 1:14 PM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote: From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 11:25 AM To: Hollenbeck, Scott Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott > wrote: I care strongly about coming to agreement on text ;), so how do we all feel= about Andy's suggestion to use SHOULD instead of MUST? That is: An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not = be able to do this reliably. An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error. Servers SHOULD map fullwidth and halfwidth= characters to their decomposition equivalents. Servers SHOULD convert stri= ngs to the same coded character set of the target data that is to be looked= up or searched and each string SHOULD be normalized using the same normali= zation that was used on the target data. Normalization Form C (NFC, [Unicod= e-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximi= ze predictability and interoperability. If the query pattern consists entir= ely of ASCII characters, servers SHOULD use case-insensitive matching again= st ASCII characters to determine matches. I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer? Scott In the last sentence, is there a particular reason that ASCII case insensit= ive matching is done only when the whole string is ASCII rather than charac= ter by character? This results in a number of inconsistencies: uuuu.aaa does not match uuu.AAA aaa-uuu.aaa does not match AAA-uuu.aaa (where u is Unicode, a is ASCII character) ASCII characters are also UTF-8-encoded Unicode characters. You could just = as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the U= nicode processing text applies, right? The point I'm trying to get across i= s that a query pattern that contains only ASCII characters does not need to= be subjected to the normalization processing used for patterns that contai= n non-ASCII characters. Is this better? "A query pattern that contains only ASCII characters does not need to be no= rmalized. Case-insensitive character comparison SHOULD be used to determine= matches for these patterns." Please suggest text if I'm still missing your point. Scott Normalization does not do any case folding, so this results in the inconsis= tencies above. ASCII case insensitive matching should be done on all string= s, not just those that are entirely ASCII. Excluding handles which are case= sensitive. Who/what says handles are case sensitive? Suggested text to replace last sentence: For domain name or nameserver queries, servers SHOULD use case-insensitive = matching on US-ASCII characters. Why only domain name and name server queries? Scott --_000_831693C2CDA2E849A7D7A712B24E257F49302A40BRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 1:14 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote:

From: Ernie Da= inow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

 

I care strongly about coming to agreement on text ;)= , so how do we all feel about Andy's suggestion to use SHOULD instead of MU= ST? That is:

An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error.  Servers SHOULD map fullwidth and half= width characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character se= t of the target data that is to be looked up or searched and each string SH= OULD be normalized using the same normalization that was used on the target= data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and t= o maximize predictability and interoperability. If the query pattern consis= ts entirely of ASCII characters, servers SHOULD use case-insensitive matchi= ng against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer?

Scott

 

In the last sentence, is there a particular reason t= hat ASCII case insensitive matching is done only when the whole string is A= SCII rather than character by character? This results in a number of incons= istencies:

 

uuuu.aaa       does not match  u= uu.AAA

aaa-uuu.aaa  does not match  AAA-uuu.aaa

 

(where u is Unicode, a is ASCII character)

 

ASCII characters are also UTF-8-encoded Un= icode characters. You could just as well re-write those patterns as uuuu.uu= u and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I’m trying to get across is that a query p= attern that contains only ASCII characters does not need to be subjected to= the normalization processing used for patterns that contain non-ASCII char= acters. Is this better?

 

“A query pattern that contains only = ASCII characters does not need to be normalized. Case-insensitive character= comparison SHOULD be used to determine matches for these patterns.”<= /span>

 

Please suggest text if I’m still mis= sing your point.

 

Scott


Normalization does not do any case folding, so this results in the inconsis= tencies above. ASCII case insensitive matching should be done on all string= s, not just those that are entirely ASCII. Excluding handles which are case= sensitive.

 

Who/what says handles are case sensitive?<= o:p>


Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive = matching on US-ASCII characters.

 

Why only domain name and name server queri= es?

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F49302A40BRN1WNEXMBX01vc_-- From edainow@afilias.info Fri Dec 13 11:47:42 2013 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 E801C1AE3FE for ; Fri, 13 Dec 2013 11:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 pzXiUOPnFjCe for ; Fri, 13 Dec 2013 11:47:38 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF891AE3E8 for ; Fri, 13 Dec 2013 11:47:37 -0800 (PST) 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 1VrYhv-0005Ni-3m for weirds@ietf.org; Fri, 13 Dec 2013 19:47:31 +0000 Received: from mail-ie0-f171.google.com ([209.85.223.171]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VrYhv-0008Hb-3I for weirds@ietf.org; Fri, 13 Dec 2013 19:47:31 +0000 Received: by mail-ie0-f171.google.com with SMTP id ar20so3515062iec.30 for ; Fri, 13 Dec 2013 11:47:25 -0800 (PST) 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=GE3b+p4ye9d8eqP2CHnGahul71xhoHtzrtK0x7VcyR8=; b=j5aq5X6aFnXGsj6a1NJfR4yG8/qfu0z98AmET09gG7zlABgQiTkfoIpGSbTgBlYUI9 I0z7dsMlFzrY3e9dqG/B2TuWTnqLaSklln2Gp0JQjuYo12KGVkhrBMjkmPEb8odF+Dug N+8t2+Peq99eW75iO1/CdvHpu5P+8EVRR9LFEECxmExiDnuECS44leEFdri4pr9XZQkE gT84xtC4bLLd4CrENfKT6d4hMY3RzHnnous0CldM9scsMtR9jdJZ/bbIICWDdRgoQxCM ozO4NkVIzlgkhpx1BaY8LeQxPKSkkPIq25Giue4P5N+RzXCHYKY47w2W7NRoEycIFWIR 1jtg== X-Gm-Message-State: ALoCoQmfjN3k0YsvQevWbl1KYiN32qYYWtgHcokBBSRnTx+0qzM3azVtYhA+loTBkZBaIi6mTIl6BMjyvrE5DE9Qx4X2/5YvpDiW6vRMO7Ot/khmV3V6IPT6nD2GQCM/wXF8UPqi1bB3 X-Received: by 10.50.30.229 with SMTP id v5mr4841782igh.27.1386964045572; Fri, 13 Dec 2013 11:47:25 -0800 (PST) X-Received: by 10.50.30.229 with SMTP id v5mr4841768igh.27.1386964045336; Fri, 13 Dec 2013 11:47:25 -0800 (PST) Received: from [192.168.2.21] (bas5-toronto47-845522795.dsl.bell.ca. [50.101.167.107]) by mx.google.com with ESMTPSA id ft2sm407384igb.5.2013.12.13.11.47.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 11:47:24 -0800 (PST) Message-ID: <52AB644B.2090107@afilias.info> Date: Fri, 13 Dec 2013 14:47:23 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Hollenbeck, Scott" References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Content-Type: multipart/alternative; boundary="------------020605000607020302000607" Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 19:47:43 -0000 This is a multi-part message in MIME format. --------------020605000607020302000607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2013-12-13 1:21 PM, Hollenbeck, Scott wrote: > > *From:*Ernie Dainow [mailto:edainow@afilias.info] > *Sent:* Friday, December 13, 2013 1:14 PM > *To:* Hollenbeck, Scott > *Cc:* weirds@ietf.org > *Subject:* Re: [weirds] using a preprocessing query parameter (was Re: > Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) > > On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote: > > *From:*Ernie Dainow [mailto:edainow@afilias.info] > *Sent:* Friday, December 13, 2013 11:25 AM > *To:* Hollenbeck, Scott > *Cc:* Andy Newton; Andrew Sullivan; weirds@ietf.org > > *Subject:* Re: [weirds] using a preprocessing query parameter (was > Re: Opinions please (was Re: comments on > draft-ietf-weirds-rdap-query-08)) > > On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott > > wrote: > > I care strongly about coming to agreement on text ;), so how do we > all feel about Andy's suggestion to use SHOULD instead of MUST? > That is: > > An RDAP client submitting a query string containing non-ASCII > characters SHOULD convert such strings into Unicode in UTF-8 > encoding. It MAY perform any local case mapping deemed necessary. > It SHOULD normalize the strings using Normalization Form C (NFC, > [Unicode-UAX15]); note that clients might not be able to do this > reliably. > > An RDAP server SHOULD treat each query string as Unicode in UTF-8 > encoding. If a string is not valid UTF-8, the server MAY > immediately stop processing the query and return an error. > Servers SHOULD map fullwidth and halfwidth characters to their > decomposition equivalents. Servers SHOULD convert strings to the > same coded character set of the target data that is to be looked > up or searched and each string SHOULD be normalized using the same > normalization that was used on the target data. Normalization Form > C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA > [RFC5891] and to maximize predictability and interoperability. If > the query pattern consists entirely of ASCII characters, servers > SHOULD use case-insensitive matching against ASCII characters to > determine matches. > > I'm going to have to see which error is appropriate to return in > this context, but is this getting closer? > > Scott > > In the last sentence, is there a particular reason that ASCII case > insensitive matching is done only when the whole string is ASCII > rather than character by character? This results in a number of > inconsistencies: > > uuuu.aaa does not match uuu.AAA > > aaa-uuu.aaa does not match AAA-uuu.aaa > > (where u is Unicode, a is ASCII character) > > ASCII characters are also UTF-8-encoded Unicode characters. You > could just as well re-write those patterns as uuuu.uuu and > uuu-uuu.uuu, and then the Unicode processing text applies, right? > The point I'm trying to get across is that a query pattern that > contains only ASCII characters does not need to be subjected to > the normalization processing used for patterns that contain > non-ASCII characters. Is this better? > > "A query pattern that contains only ASCII characters does not need > to be normalized. Case-insensitive character comparison SHOULD be > used to determine matches for these patterns." > > Please suggest text if I'm still missing your point. > > Scott > > > Normalization does not do any case folding, so this results in the > inconsistencies above. ASCII case insensitive matching should be done > on all strings, not just those that are entirely ASCII. Excluding > handles which are case sensitive. > > Who/what says handles are case sensitive? > Right, they may not be. Handle is defined only as "registry-unique identifiers" in json-response-06. It would be up to each server to determine whether to do case insensitive matching on handles or not. > > > Suggested text to replace last sentence: > For domain name or nameserver queries, servers SHOULD use > case-insensitive matching on US-ASCII characters. > > Why only domain name and name server queries? > > Domain name and nameserver are ASCII case insensitive according to DNS standards. Ernie --------------020605000607020302000607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2013-12-13 1:21 PM, Hollenbeck, Scott wrote:

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 1:14 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote:

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:

 

I care strongly about coming to agreement on text ;), so how do we all feel about Andy's suggestion to use SHOULD instead of MUST? That is:

An RDAP client submitting a query string containing non-ASCII characters SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform any local case mapping deemed necessary. It SHOULD normalize the strings using Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server MAY immediately stop processing the query and return an error.  Servers SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character set of the target data that is to be looked up or searched and each string SHOULD be normalized using the same normalization that was used on the target data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximize predictability and interoperability. If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this context, but is this getting closer?

Scott

 

In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies:

 

uuuu.aaa       does not match  uuu.AAA

aaa-uuu.aaa  does not match  AAA-uuu.aaa

 

(where u is Unicode, a is ASCII character)

 

ASCII characters are also UTF-8-encoded Unicode characters. You could just as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I’m trying to get across is that a query pattern that contains only ASCII characters does not need to be subjected to the normalization processing used for patterns that contain non-ASCII characters. Is this better?

 

“A query pattern that contains only ASCII characters does not need to be normalized. Case-insensitive character comparison SHOULD be used to determine matches for these patterns.”

 

Please suggest text if I’m still missing your point.

 

Scott


Normalization does not do any case folding, so this results in the inconsistencies above. ASCII case insensitive matching should be done on all strings, not just those that are entirely ASCII. Excluding handles which are case sensitive.

 

Who/what says handles are case sensitive?

Right, they may not be. Handle is defined only as "registry-unique identifiers" in json-response-06. It would be up to each server to determine whether to do case insensitive matching on handles or not.


Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters.

 

Why only domain name and name server queries?

 


Domain name and nameserver are ASCII case insensitive according to DNS standards.

Ernie
--------------020605000607020302000607-- From shollenbeck@verisign.com Fri Dec 13 12:04:30 2013 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 724FD1AE321 for ; Fri, 13 Dec 2013 12:04:30 -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 1I9ghw6mum4J for ; Fri, 13 Dec 2013 12:04:25 -0800 (PST) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 8BACC1AE056 for ; Fri, 13 Dec 2013 12:04:04 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKUqtoLpKl/erLG75FLRDYq6QXresNcsDY@postini.com; Fri, 13 Dec 2013 12:04:19 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 rBDK3vSM019382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 15:03:57 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Dec 2013 15:03:57 -0500 From: "Hollenbeck, Scott" To: Ernie Dainow Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAASrEgP//5CnwgAG4oYD//6700IAAb2IA//+s2jAADaj0gAAKVj/w Date: Fri, 13 Dec 2013 20:03:56 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB644B.2090107@afilias.info> In-Reply-To: <52AB644B.2090107@afilias.info> 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_831693C2CDA2E849A7D7A712B24E257F49302B7BBRN1WNEXMBX01vc_" MIME-Version: 1.0 Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 20:04:30 -0000 --_000_831693C2CDA2E849A7D7A712B24E257F49302B7BBRN1WNEXMBX01vc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 2:47 PM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On 2013-12-13 1:21 PM, Hollenbeck, Scott wrote: From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 1:14 PM To: Hollenbeck, Scott Cc: weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote: From: Ernie Dainow [mailto:edainow@afilias.info] Sent: Friday, December 13, 2013 11:25 AM To: Hollenbeck, Scott Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinio= ns please (was Re: comments on draft-ietf-weirds-rdap-query-08)) On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott > wrote: I care strongly about coming to agreement on text ;), so how do we all feel= about Andy's suggestion to use SHOULD instead of MUST? That is: An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not = be able to do this reliably. An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error. Servers SHOULD map fullwidth and halfwidth= characters to their decomposition equivalents. Servers SHOULD convert stri= ngs to the same coded character set of the target data that is to be looked= up or searched and each string SHOULD be normalized using the same normali= zation that was used on the target data. Normalization Form C (NFC, [Unicod= e-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and to maximi= ze predictability and interoperability. If the query pattern consists entir= ely of ASCII characters, servers SHOULD use case-insensitive matching again= st ASCII characters to determine matches. I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer? Scott In the last sentence, is there a particular reason that ASCII case insensit= ive matching is done only when the whole string is ASCII rather than charac= ter by character? This results in a number of inconsistencies: uuuu.aaa does not match uuu.AAA aaa-uuu.aaa does not match AAA-uuu.aaa (where u is Unicode, a is ASCII character) ASCII characters are also UTF-8-encoded Unicode characters. You could just = as well re-write those patterns as uuuu.uuu and uuu-uuu.uuu, and then the U= nicode processing text applies, right? The point I'm trying to get across i= s that a query pattern that contains only ASCII characters does not need to= be subjected to the normalization processing used for patterns that contai= n non-ASCII characters. Is this better? "A query pattern that contains only ASCII characters does not need to be no= rmalized. Case-insensitive character comparison SHOULD be used to determine= matches for these patterns." Please suggest text if I'm still missing your point. Scott Normalization does not do any case folding, so this results in the inconsis= tencies above. ASCII case insensitive matching should be done on all string= s, not just those that are entirely ASCII. Excluding handles which are case= sensitive. Who/what says handles are case sensitive? Right, they may not be. Handle is defined only as "registry-unique identifi= ers" in json-response-06. It would be up to each server to determine whethe= r to do case insensitive matching on handles or not. Suggested text to replace last sentence: For domain name or nameserver queries, servers SHOULD use case-insensitive = matching on US-ASCII characters. Why only domain name and name server queries? Domain name and nameserver are ASCII case insensitive according to DNS stan= dards. Please note the word "only" in my question. What about entity handles and e= ntity names? Assuming we go with "up to each server" as described above I c= an't use "For domain name or nameserver queries" as you suggested, and I re= ally don't want to expand that to add entities because we run the risk of n= ot covering queries that might be added in the future. So let's try again. = How about "Case insensitive pattern matching SHOULD be used to compare US-A= SCII characters in query patterns" instead of "If the query pattern consist= s entirely of ASCII characters, servers SHOULD use case-insensitive matchin= g against ASCII characters to determine matches". FWIW I think a server operator that treats handles as case sensitive and do= main names as case insensitive is going to have some confusion issues with = users. Scott --_000_831693C2CDA2E849A7D7A712B24E257F49302B7BBRN1WNEXMBX01vc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 2:47 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On 2013-12-13 1:21 PM, Hollenbeck, Scott wrote:=

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 1:14 PM
To: Hollenbeck, Scott
Cc: weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On 2013-12-13 11:53 AM, Hollenbeck, Scott wrote:

From: Ernie Da= inow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 11:25 AM
To: Hollenbeck, Scott
Cc: Andy Newton; Andrew Sullivan; weirds@ietf.org
Subject: Re: [weirds] using a preprocessing query parameter (was Re:= Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08))

 

On Thu, Dec 12, 2013 at 2:20 PM, Hollenbeck, Scott &= lt;shollenbec= k@verisign.com> wrote:

 

I care strongly about coming to agreement on text ;)= , so how do we all feel about Andy's suggestion to use SHOULD instead of MU= ST? That is:

An RDAP client submitting a query string containing non-ASCII characters SH= OULD convert such strings into Unicode in UTF-8 encoding. It MAY perform an= y local case mapping deemed necessary. It SHOULD normalize the strings usin= g Normalization Form C (NFC, [Unicode-UAX15]); note that clients might not be able to do this reliably.

An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an error.  Servers SHOULD map fullwidth and half= width characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character se= t of the target data that is to be looked up or searched and each string SH= OULD be normalized using the same normalization that was used on the target= data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA [RFC5891] and t= o maximize predictability and interoperability. If the query pattern consis= ts entirely of ASCII characters, servers SHOULD use case-insensitive matchi= ng against ASCII characters to determine matches.

I'm going to have to see which error is appropriate to return in this conte= xt, but is this getting closer?

Scott

 

In the last sentence, is there a particular reason t= hat ASCII case insensitive matching is done only when the whole string is A= SCII rather than character by character? This results in a number of incons= istencies:

 

uuuu.aaa       does not match  u= uu.AAA

aaa-uuu.aaa  does not match  AAA-uuu.aaa

 

(where u is Unicode, a is ASCII character)

 

ASCII characters are also UTF-8-encoded Un= icode characters. You could just as well re-write those patterns as uuuu.uu= u and uuu-uuu.uuu, and then the Unicode processing text applies, right? The point I’m trying to get across is that a query p= attern that contains only ASCII characters does not need to be subjected to= the normalization processing used for patterns that contain non-ASCII char= acters. Is this better?

 

“A query pattern that contains only = ASCII characters does not need to be normalized. Case-insensitive character= comparison SHOULD be used to determine matches for these patterns.”<= /span>

 

Please suggest text if I’m still mis= sing your point.

 

Scott


Normalization does not do any case folding, so this results in the inconsis= tencies above. ASCII case insensitive matching should be done on all string= s, not just those that are entirely ASCII. Excluding handles which are case= sensitive.

 

Who/what says handles are case sensitive?<= /span>

Right, they may not be. Handle is defined only as &q= uot;registry-unique identifiers" in json-response-06. It would be up t= o each server to determine whether to do case insensitive matching on handl= es or not.


Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive = matching on US-ASCII characters.

 

Why only domain name and name server queri= es?

 

 

Domain name and nameserver are ASCII case insensitiv= e according to DNS standards.

Please note the word “only” in= my question. What about entity handles and entity names? Assuming we go wi= th “up to each server” as described above I can’t use = 220;For domain name or nameserver queries” as you suggested, and I really don’t wa= nt to expand that to add entities because we run the risk of not covering q= ueries that might be added in the future. So let’s try again. How abo= ut “Case insensitive pattern matching SHOULD be used to compare US-ASCII characters in query patterns” instead of “= If the query pattern consists entirely of ASCII characters, servers SHOULD = use case-insensitive matching against ASCII characters to determine matches= ”.

 

FWIW I think a server operator that treats= handles as case sensitive and domain names as case insensitive is going to= have some confusion issues with users.

 

Scott

--_000_831693C2CDA2E849A7D7A712B24E257F49302B7BBRN1WNEXMBX01vc_-- From ajs@anvilwalrusden.com Fri Dec 13 12:24:04 2013 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 96BCC1AE3E9 for ; Fri, 13 Dec 2013 12:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 Zzu_rjLTWjlu for ; Fri, 13 Dec 2013 12:24:03 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4C68F1AE3A0 for ; Fri, 13 Dec 2013 12:24:03 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3E8238A031 for ; Fri, 13 Dec 2013 20:23:56 +0000 (UTC) Date: Fri, 13 Dec 2013 15:23:49 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131213202349.GA1265@mx1.yitter.info> References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB644B.2090107@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 20:24:04 -0000 I can't entirely tell which bits of this message are from which person, because quote markers seem to have been left out; apologies for any confusion. In any case, On Fri, Dec 13, 2013 at 08:03:56PM +0000, Hollenbeck, Scott wrote: > From: Ernie Dainow [mailto:edainow@afilias.info] > Sent: Friday, December 13, 2013 2:47 PM > > In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies: > > uuuu.aaa does not match uuu.AAA > aaa-uuu.aaa does not match AAA-uuu.aaa > > (where u is Unicode, a is ASCII character) Yes. The problem is that US-ASCII case folding rules are entirely straightforward in English. Once you get outside of English in US-ASCII, everything goes pear-shaped very quickly. For instance, according to the standard French orthography, the upper case of é is E. So if you have a string "ECOLE" and you want to do case-insensitive searching, you need to look at "ecole" and "école" as well. We already decided, I believe, that we don't want to do this. (Worse, according to standard Québecois orthography, the upper case of é is É, which means there aren't even universal rules.) And that's an easy example. Think about Turkish i-like characters, for instance. So, in my view (and in the view of anyone I've ever met who knows even a little bit about the sharp, poiny bits of Unicode), handling a string "case-insensitively" is complicated. We said we weren't going to do complicated, so let's just not. As for doing this character by character, it will be completely mystifying to anyone that a and A match but for some reason é and E don't, in the same string. No actual humans have a theory of the ASCII range of Unicode vs. the rest of it, so we can't mix this behaviour in the same string. > Suggested text to replace last sentence: > For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters. Not this, please. That would appear to permit matching on écoLE, and that's just not a U-label. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From edainow@afilias.info Fri Dec 13 12:41:00 2013 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 B9D5C1AE028 for ; Fri, 13 Dec 2013 12:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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 PDWjjXrpVNH0 for ; Fri, 13 Dec 2013 12:40:58 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id 4300B1ADFBD for ; Fri, 13 Dec 2013 12:40:58 -0800 (PST) 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 1VrZXX-0002nu-4O for weirds@ietf.org; Fri, 13 Dec 2013 20:40:51 +0000 Received: from mail-ie0-f174.google.com ([209.85.223.174]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1VrZXX-0003cY-3x for weirds@ietf.org; Fri, 13 Dec 2013 20:40:51 +0000 Received: by mail-ie0-f174.google.com with SMTP id at1so3598959iec.19 for ; Fri, 13 Dec 2013 12:40:45 -0800 (PST) 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; bh=0mRqCjuvTh+19U578b0bQ8f7/yR6GS+mdsRZBzF7Tz4=; b=m1d56I/Vlp/7TtC/7iGneLlW8OxNwn1CB8AWiWVbH5tsxckGBwrEQ6kjvzKFqypvd+ I2AJLXkYm90DYNhBV7u1GfWpvQNr0D0E+oRH1Y1ecHe7kjOvmN+k3cLxcUdxocsMq1XV ny2IsP/fdp1k+0Xq7cOArvUo1OpJK70bd8qF+Lm3FlrH2jqNcjRh/M5OxZ8aYOdzouak ivyVEKf1sLJcr5JF4dItAxKT9VKvuQfb77Ch/aTz+rI/4RMEAtHfmLV+m1v7+AehLyq/ gO77HS5MEucaPd0c/SKyom9SUfxtzuY5qraEpyqRP6+gyTogp4dh8k8pRe61r7u5lxRS GeDw== X-Gm-Message-State: ALoCoQktMc81DSYAggtSMKgq/qguYy2XUeqxffbVI19X0lObcafR10bSbtTJ1m9NsqmU2P/nzPPxesYsQxTzMP14Wu/IK1aAhzQYpyn62le2kyA3m6LRmFvQqhnd9otdoCfBaO1GmRSU X-Received: by 10.42.94.78 with SMTP id a14mr2339309icn.77.1386967245798; Fri, 13 Dec 2013 12:40:45 -0800 (PST) X-Received: by 10.42.94.78 with SMTP id a14mr2339301icn.77.1386967245632; Fri, 13 Dec 2013 12:40:45 -0800 (PST) Received: from [192.168.2.21] (bas5-toronto47-845522795.dsl.bell.ca. [50.101.167.107]) by mx.google.com with ESMTPSA id o1sm642128igh.9.2013.12.13.12.40.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 12:40:45 -0800 (PST) Message-ID: <52AB70CC.70605@afilias.info> Date: Fri, 13 Dec 2013 15:40:44 -0500 From: Ernie Dainow User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Andrew Sullivan , weirds@ietf.org References: <52A8E008.4060405@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB644B.2090107@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131213202349.GA1265@mx1.yitter.info> In-Reply-To: <20131213202349.GA1265@mx1.yitter.info> Content-Type: multipart/alternative; boundary="------------070307000001090506010102" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 20:41:01 -0000 This is a multi-part message in MIME format. --------------070307000001090506010102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2013-12-13 3:23 PM, Andrew Sullivan wrote: > On Fri, Dec 13, 2013 at 08:03:56PM +0000, Hollenbeck, Scott wrote: >> From: Ernie Dainow [mailto:edainow@afilias.info] >> Sent: Friday, December 13, 2013 2:47 PM >> >> In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies: >> >> uuuu.aaa does not match uuu.AAA >> aaa-uuu.aaa does not match AAA-uuu.aaa >> >> (where u is Unicode, a is ASCII character) > Yes. The problem is that US-ASCII case folding rules are entirely > straightforward in English. Once you get outside of English in > US-ASCII, everything goes pear-shaped very quickly. > > For instance, according to the standard French orthography, the upper > case of é is E. So if you have a string "ECOLE" and you want to do > case-insensitive searching, you need to look at "ecole" and "école" as > well. We already decided, I believe, that we don't want to do this. > > (Worse, according to standard Québecois orthography, the upper case of > é is É, which means there aren't even universal rules.) > > And that's an easy example. Think about Turkish i-like characters, > for instance. > > So, in my view (and in the view of anyone I've ever met who knows even > a little bit about the sharp, poiny bits of Unicode), handling a > string "case-insensitively" is complicated. We said we weren't going > to do complicated, so let's just not. > > As for doing this character by character, it will be completely > mystifying to anyone that a and A match but for some reason é and E > don't, in the same string. No actual humans have a theory of the > ASCII range of Unicode vs. the rest of it, so we can't mix this > behaviour in the same string. > >> Suggested text to replace last sentence: >> For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters. > Not this, please. That would appear to permit matching on écoLE, and > that's just not a U-label. > > So is Scott's original wording on this safe, we do want to cover case insensitivity as in the DNS standard: If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches. Since it is only a SHOULD, if the server treats handles or anything else as case sensitive, they are free to do so. -Ernie --------------070307000001090506010102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 2013-12-13 3:23 PM, Andrew Sullivan wrote:
On Fri, Dec 13, 2013 at 08:03:56PM +0000, Hollenbeck, Scott wrote:

From: Ernie Dainow [mailto:edainow@afilias.info]
Sent: Friday, December 13, 2013 2:47 PM

In the last sentence, is there a particular reason that ASCII case insensitive matching is done only when the whole string is ASCII rather than character by character? This results in a number of inconsistencies:

uuuu.aaa       does not match  uuu.AAA
aaa-uuu.aaa  does not match  AAA-uuu.aaa

(where u is Unicode, a is ASCII character)

Yes.  The problem is that US-ASCII case folding rules are entirely
straightforward in English.  Once you get outside of English in
US-ASCII, everything goes pear-shaped very quickly.

For instance, according to the standard French orthography, the upper
case of é is E.  So if you have a string "ECOLE" and you want to do
case-insensitive searching, you need to look at "ecole" and "école" as
well.  We already decided, I believe, that we don't want to do this. 

(Worse, according to standard Québecois orthography, the upper case of
é is É, which means there aren't even universal rules.)

And that's an easy example.  Think about Turkish i-like characters,
for instance.

So, in my view (and in the view of anyone I've ever met who knows even
a little bit about the sharp, poiny bits of Unicode), handling a
string "case-insensitively" is complicated.  We said we weren't going
to do complicated, so let's just not.

As for doing this character by character, it will be completely
mystifying to anyone that a and A match but for some reason é and E
don't, in the same string.  No actual humans have a theory of the
ASCII range of Unicode vs. the rest of it, so we can't mix this
behaviour in the same string.


Suggested text to replace last sentence:
For domain name or nameserver queries, servers SHOULD use case-insensitive matching on US-ASCII characters.

Not this, please.  That would appear to permit matching on écoLE, and
that's just not a U-label.

So is Scott's original wording on this safe, we do want to cover case insensitivity as in the DNS standard:

 If the query pattern consists entirely of ASCII characters, servers SHOULD use case-insensitive matching against ASCII characters to determine matches.

Since it is only a SHOULD, if the server treats handles or anything else as case sensitive, they are free to do so.

-Ernie


--------------070307000001090506010102-- From ajs@anvilwalrusden.com Fri Dec 13 13:23:14 2013 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 E09361AE10E for ; Fri, 13 Dec 2013 13:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.242 X-Spam-Level: X-Spam-Status: No, score=-0.242 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, GB_I_LETTER=-2, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 sUL-bMuV6EoT for ; Fri, 13 Dec 2013 13:23:13 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 29F811AE0E9 for ; Fri, 13 Dec 2013 13:23:13 -0800 (PST) Received: from mx1.yitter.info (nat-02-mht.dyndns.com [216.146.45.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 8B31A8A031 for ; Fri, 13 Dec 2013 21:23:06 +0000 (UTC) Date: Fri, 13 Dec 2013 16:23:04 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131213212304.GE1265@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB644B.2090107@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131213202349.GA1265@mx1.yitter.info> <52AB70CC.70605@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52AB70CC.70605@afilias.info> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 21:23:15 -0000 On Fri, Dec 13, 2013 at 03:40:44PM -0500, Ernie Dainow wrote: > > So is Scott's original wording on this safe, we do want to cover > case insensitivity as in the DNS standard: If we're trying to match the DNS matching rules, then we should say that. In that case, it's not _strings_ we're matching, but labels. Each label is handled separately. These cases are perfectly acceptable: école.EXAMPLE.com. école.EXample.com. This case is not: écOLE.example.com. So, if we're just trying to cope with DNS names, then we should say something like this: DNS names are treated according to the DNS matching rules as described in [RFC1035], section 3.1 for NR-LDH labels; and the matching rules as described in [RFC5891], section 5.4 for U-labels. Matching of DNS names proceeds one label at a time, because it is possible for a combination of U-labels and NR-LDH labels to be found in a single domain or host name. The determination of whether a label is a U-label or an NR-LDH label is based on whether the label contains any characters outside of the ASCII letters, digits, or hyphen (the so-called LDH rule). Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Fri Dec 13 15:13:14 2013 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 AD9021AE0D1 for ; Fri, 13 Dec 2013 15:13:14 -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 sPnx99rHJhA8 for ; Fri, 13 Dec 2013 15:13:13 -0800 (PST) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id E0A9B1AE019 for ; Fri, 13 Dec 2013 15:13:11 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUquUgQm+ZMMHwhAfwikDEABWxlsp6OS8@postini.com; Fri, 13 Dec 2013 15:13:07 PST 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 rBDND4ht008261 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Dec 2013 18:13:04 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 13 Dec 2013 18:13:04 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan Thread-Topic: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) Thread-Index: AQHO9bk/g+d8jH7jG06Q2J59XuS/3ppO8MSggADv3gCAASrEgP//5CnwgAG4oYD//6700IAAb2IA//+s2jAADaj0gAAKVj/w//+3e4CAAAS6AIAAC9QA///K6vI= Date: Fri, 13 Dec 2013 23:13:03 +0000 Message-ID: References: <831693C2CDA2E849A7D7A712B24E257F49300919@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <831693C2CDA2E849A7D7A712B24E257F4930294E@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB4E60.8060205@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302A40@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <52AB644B.2090107@afilias.info> <831693C2CDA2E849A7D7A712B24E257F49302B7B@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131213202349.GA1265@mx1.yitter.info> <52AB70CC.70605@afilias.info>,<20131213212304.GE1265@mx1.yitter.info> In-Reply-To: <20131213212304.GE1265@mx1.yitter.info> 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 Cc: "weirds@ietf.org" Subject: Re: [weirds] using a preprocessing query parameter (was Re: Opinions please (was Re: comments on draft-ietf-weirds-rdap-query-08)) 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, 13 Dec 2013 23:13:15 -0000 Scott > On Dec 13, 2013, at 4:23 PM, "Andrew Sullivan" w= rote: >=20 >> On Fri, Dec 13, 2013 at 03:40:44PM -0500, Ernie Dainow wrote: >>=20 >> So is Scott's original wording on this safe, we do want to cover >> case insensitivity as in the DNS standard: >=20 > If we're trying to match the DNS matching rules, then we should say > that. In that case, it's not _strings_ we're matching, but labels. > Each label is handled separately. These cases are perfectly acceptable: >=20 >=20 > =E9cole.EXAMPLE.com. > =E9cole.EXample.com. >=20 > This case is not: >=20 > =E9cOLE.example.com. >=20 > So, if we're just trying to cope with DNS names, then we should say > something like this: [snip] We also have to deal with entity names and handles. Scott= From kambe@jprs.co.jp Mon Dec 16 01:09:28 2013 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 77DFB1AE111 for ; Mon, 16 Dec 2013 01:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.969 X-Spam-Level: * X-Spam-Status: No, score=1.969 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.538, 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 w5XfjWPMt_2N for ; Mon, 16 Dec 2013 01:09:27 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 0365F1ADDBF for ; Mon, 16 Dec 2013 01:09:26 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id rBG99O6u029234 for ; Mon, 16 Dec 2013 18:09:24 +0900 X-AuditID: ac120820-b7f196d00000167f-a9-52aec3441cef Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 5D.BE.05759.443CEA25; Mon, 16 Dec 2013 18:09:24 +0900 (JST) Date: Mon, 16 Dec 2013 18:08:12 +0900 (JST) Message-Id: <20131216.180812.200788944.kambe@jprs.co.jp> To: weirds@ietf.org From: Naoki Kambe Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPIsWRmVeSWpSXmKPExsWyRoiFT9fl8Logg+vNmhbzu46zODB6LFny kymAMYrLJiU1J7MstUjfLoEr43PDRcaCO0wVk85MZ2xgnMrUxcjBISFgIvFrV3oXIyeQKSZx 4d56NhBbSOAko8TjU3EgNouAtsSvB52sIDavgIXEoVM/WUBsEQFhicUv34HZwgIKEhf63zKD 2GwCKhLL7m0GG88voC8xtSkFYrydRNNfkHIOoDGCEn93CIOEmQW0JHpmPGaHsOUltr+dwzyB kXcWQtUsJFWzkFQtYGRexSiTn5amW5yal1Kcm25gqFdSma+XVVBUrJcMojcxgsOHQ2EH44xT BocYBTgYlXh4+63XBQmxJpYVV+YeYpTkYFIS5a07BBTiS8pPqcxILM6ILyrNSS0+xCjBwawk wmtwECjHm5JYWZValA+TkuZgURLnPf7nTKCQQHpiSWp2ampBahFMVoaDQ0mClxdkqGBRanpq RVpmTglCmomDE2Q4D9BwB5Aa3uKCxNzizHSI/ClGSSlx3s8HgBICIImM0jy43leM4kAvCPMq gLTxAFMBXNcroIFMQAOfrwEbWJKIkJJqYNyY6abZcvccS+fmVl6fNzprj2Y3v/bh6GA9/urR ucfNeq1/3RZmpHxcrBKfP//sgRczz4cXHbn2Q28Nv1vQybWch0Te8zzwnT15UnLdRRZV4bvK XS9Wbrbscueb/qM3ev3k2JcySydfc9wr9vrxl5/1YRv3HMxfVDFd4PMZp4exGttWPFJkDnmq xFKckWioxVxUnAgACDb/KMICAAA= Subject: [weirds] Interop test in London? 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, 16 Dec 2013 09:09:28 -0000 Hello, I'm curious about participating in an interop test in the upcoming IETF in London. I'm thinking that a prototype RDAP service, which is actually being developed now, will be tested. According to the last meeting in Vancouver, we'll have it in London. Could anyone post the details about that to the list? Regards, Naoki Kambe From zhoulinlin@cnnic.cn Mon Dec 16 01:35:12 2013 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 E814E1AE11D for ; Mon, 16 Dec 2013 01:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538] 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 PQKUbmgYl9ch for ; Mon, 16 Dec 2013 01:35:07 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id BF5151AE0B4 for ; Mon, 16 Dec 2013 01:35:06 -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, 16 Dec 2013 17:35:02 +0800 From: "Linlin Zhou" To: "'Naoki Kambe'" , References: <20131216.180812.200788944.kambe@jprs.co.jp> In-Reply-To: <20131216.180812.200788944.kambe@jprs.co.jp> Date: Mon, 16 Dec 2013 17:35:01 +0800 Message-ID: <00b901cefa42$17bde6f0$4739b4d0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac76PoqR1H8/tLE/SvGwPxxKM7+V1wAAdpdQ Content-Language: zh-cn Subject: Re: [weirds] Interop test in London? 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, 16 Dec 2013 09:35:13 -0000 Welcome to participate. Marc Blanchet will send notification before IETF meeting on the weirds-interop mailing list. You can ask him to add you to the mailing list. Regards, Linlin > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Naoki Kambe > Sent: Monday, December 16, 2013 5:08 PM > To: weirds@ietf.org > Subject: [weirds] Interop test in London? > > Hello, > > I'm curious about participating in an interop test in the upcoming IETF in > London. I'm thinking that a prototype RDAP service, which is actually being > developed now, will be tested. According to the last meeting in Vancouver, > we'll have it in London. Could anyone post the details about that to the list? > > Regards, > > Naoki Kambe > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From marc.blanchet@viagenie.ca Mon Dec 16 06:16:14 2013 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 B470E1ADFE5 for ; Mon, 16 Dec 2013 06:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 N49dFJEXbC8H for ; Mon, 16 Dec 2013 06:16:13 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 047941AD7C1 for ; Mon, 16 Dec 2013 06:16:13 -0800 (PST) Received: from [IPv6:2620:0:230:2002::1001] (unknown [IPv6:2620:0:230:2002::1001]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 616574002A; Mon, 16 Dec 2013 09:16:11 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Marc Blanchet In-Reply-To: <20131216.180812.200788944.kambe@jprs.co.jp> Date: Mon, 16 Dec 2013 09:16:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131216.180812.200788944.kambe@jprs.co.jp> To: Naoki Kambe X-Mailer: Apple Mail (2.1822) Cc: "" Subject: Re: [weirds] Interop test in London? 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, 16 Dec 2013 14:16:14 -0000 Le 2013-12-16 =E0 04:08, Naoki Kambe a =E9crit : > Hello, Kambe-san, >=20 > I'm curious about participating in an interop test in the upcoming > IETF in London. I'm thinking that a prototype RDAP service, which is > actually being developed now, will be tested. According to the last > meeting in Vancouver, we'll have it in London. yes. > Could anyone post the > details about that to the list? there is a separate mailing list setup for interop participant. We will = subscribe you to the mailing list. the details of the interop will be discussed on that separate mailing = list. last time, we did the interop session sunday morning. Before, it was = saturday afternoon. The group should decide on the interop mailing list. Marc. >=20 > Regards, >=20 > Naoki Kambe > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From kambe@jprs.co.jp Mon Dec 16 16:56:25 2013 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 6C2551ADF80 for ; Mon, 16 Dec 2013 16:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.07 X-Spam-Level: X-Spam-Status: No, score=0.07 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.538, 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 JksRzHdREE93 for ; Mon, 16 Dec 2013 16:56:24 -0800 (PST) Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4961ADF32 for ; Mon, 16 Dec 2013 16:56:24 -0800 (PST) Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id rBH0uM5G008516 for ; Tue, 17 Dec 2013 09:56:22 +0900 X-AuditID: ac120820-b7f196d00000167f-98-52afa134932a Received: from localhost (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id BD.A3.05759.431AFA25; Tue, 17 Dec 2013 09:56:20 +0900 (JST) Date: Tue, 17 Dec 2013 09:54:38 +0900 (JST) Message-Id: <20131217.095438.82808882.kambe@jprs.co.jp> To: weirds@ietf.org From: Naoki Kambe In-Reply-To: References: <20131216.180812.200788944.kambe@jprs.co.jp> Organization: Japan Registry Services Co., Ltd. X-Mailer: Mew version 5.2.52 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCIsWRmVeSWpSXmKPExsWyRoiFT9dk4fogg56Dchbzu46zODB6LFny kymAMYrLJiU1J7MstUjfLoErY+a73ewFSxkr+j4cYmpgbGbsYuTgkBAwkbjwvbSLkRPIFJO4 cG89WxcjF4eQwElGiVcbbjOBJFgEtCU6u5rZQWxeAXOJJRfaGEFsEQFhicUv37GA2MICuhLH Lrczg9hsAioSy+5tBuvlFLCXeLNmMVi9kECuxP6jj9lA9vIL6EtMbUqB2Gsn0fQXZAwH0HhB ib87hEHCzAJaEj0zHrND2PIS29/OYZ7AyD8LoWoWkqpZSKoWMDKvYpTJT0vTLU7NSynOTTcw 1CupzNfLKigq1ksG0ZsYwQHHobCDccYpg0OMAhyMSjy8UrPXBwmxJpYVV+YeYpTkYFIS5Y0A CfEl5adUZiQWZ8QXleakFh9ilOBgVhLhZSkAyvGmJFZWpRblw6SkOViUxHmP/zkTKCSQnliS mp2aWpBaBJOV4eBQkuB9PQ+oUbAoNT21Ii0zpwQhzcTBCTKcB2j44vkgw4sLEnOLM9Mh8qcY VTluzf7wjVGIJS8/L1VKnHcVSJEASFFGaR7cnFeM4kDvCPNWg6zhASYVuAmvgIYzAQ1/vmYd yPCSRISUVAOj+RzNL74ZIbxnd/RydKb/z65kv6H/YZ+xH0trgEfqVtFp8wyzggXaZ81//+PA uRu/gl9fNS09N3nBBKHX9RGyS7Z/dVsfrRHFuqt1vlrzrfKK3x9y7PbpZfQcM/Vb8zxk/8ze VRVqghtzlz7wbFdcZb/yd9Ca6wXxi64t4p+yv+zl5eoVHi/6lFiKMxINtZiLihMB41uLZucC AAA= Subject: Re: [weirds] Interop test in London? 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, 17 Dec 2013 00:56:25 -0000 Marc-san, Linlin-san, Thank you for the quick responses. I already received the information about that list. We'll talk there later. Regards, Naoki Kambe From shollenbeck@verisign.com Tue Dec 17 05:25:04 2013 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 75CCB1AE1AB for ; Tue, 17 Dec 2013 05:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 pXdJoCSRyfOO for ; Tue, 17 Dec 2013 05:25:02 -0800 (PST) Received: from exprod6og122.obsmtp.com (exprod6og122.obsmtp.com [64.18.1.238]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA141AE1A7 for ; Tue, 17 Dec 2013 05:25:02 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob122.postini.com ([64.18.5.12]) with SMTP ID DSNKUrBQrWsZKlXP8c+XY+VJ5sub1aTdM41M@postini.com; Tue, 17 Dec 2013 05:25:01 PST 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 rBHDP0rX009034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Dec 2013 08:25:00 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 08:25:00 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: Updated Search Processing Text Proposal Thread-Index: Ac77K2BvBWI8u+MwTDGfQnY8BC6IGA== Date: Tue, 17 Dec 2013 13:24:59 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49305696@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 Subject: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 13:25:04 -0000 I'm going to try to capture and summarize the results of the recent discuss= ion on search processing text. This is what's currently in rdap-query-08: Servers SHOULD thus accept any search pattern that is otherwise properly en= coded. If the pattern consists entirely of ASCII characters, servers SHOUL= D use case-insensitive prefix matching against ASCII labels to determine pa= rtial matches. If the text in the pattern is or can be converted to a U-la= bel, servers SHOULD use prefix matching against U-labels to determine parti= al matches. Proposed new text: An RDAP client submitting a query string containing non-US-ASCII characters= SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform= any local case mapping deemed necessary. It SHOULD normalize the strings u= sing Normalization Form C (NFC, [Unicode-UAX15]); note that clients might n= ot be able to do this reliably. An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an HTTP 400 error response code. Servers SHOULD map = fullwidth and halfwidth characters to their decomposition equivalents. Serv= ers SHOULD convert strings to the same coded character set of the target da= ta that is to be looked up or searched and each string SHOULD be normalized= using the same normalization that was used on the target data. Normalizati= on Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDNA = [RFC5891] and to maximize predictability and interoperability. Case insensi= tive pattern matching SHOULD be used to compare US-ASCII characters in quer= y patterns. DNS names are treated according to the DNS matching rules as described in S= ection 3.1 of RFC 1035 [RFC1035] for NR-LDH labels and the matching rules d= escribed in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of DN= S names proceeds one label at a time, because it is possible for a combinat= ion of U-labels and NR-LDH labels to be found in a single domain or host na= me. The determination of whether a label is a U-label or an NR-LDH label is= based on whether the label contains any characters outside of the US-ASCII= letters, digits, or hyphen (the so-called LDH rule). I appreciate the thoughts and text provided by everyone - thanks! Scott From ajs@anvilwalrusden.com Tue Dec 17 06:42:08 2013 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 E9EF31AE1B6 for ; Tue, 17 Dec 2013 06:42:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 3w7lHaBPhTkX for ; Tue, 17 Dec 2013 06:42:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD81AE17A for ; Tue, 17 Dec 2013 06:42:07 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id B068D8A031 for ; Tue, 17 Dec 2013 14:42:06 +0000 (UTC) Date: Tue, 17 Dec 2013 09:42:05 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131217144205.GC2761@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 14:42:09 -0000 On Tue, Dec 17, 2013 at 01:24:59PM +0000, Hollenbeck, Scott wrote: > Case insensitive pattern matching SHOULD be used to compare US-ASCII > characters in query patterns. I still very strongly suggest that the behaviour needs to be string-based, not character-based. If you're going to do case insensitive work, you need to use Unicode case folding, not do case folding for some characters and not others. The above has the absurd consequence that école and École don't match, but école and éCole do. We said we didn't want to get into the complications of case folding or the disaster that will result from trying to do decorated-vs-undecorated character matching, which is why not to use all of case folding. So I can see an argument for case insensitivity for ASCII strings, but one cannot do this character by character. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Tue Dec 17 06:49:08 2013 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 C77A61AE216 for ; Tue, 17 Dec 2013 06:49:08 -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 B1LP2HkE0bu6 for ; Tue, 17 Dec 2013 06:49:04 -0800 (PST) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5191AE215 for ; Tue, 17 Dec 2013 06:49:03 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKUrBkXszjitTJ0SISloE6SWoIV4YazBBW@postini.com; Tue, 17 Dec 2013 06:49:03 PST Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id rBHEn1SI011954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 09:49:01 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 09:49:01 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Updated Search Processing Text Proposal Thread-Index: Ac77K2BvBWI8u+MwTDGfQnY8BC6IGAANK/qAAApNhRA= Date: Tue, 17 Dec 2013 14:48:59 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49305A49@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217144205.GC2761@mx1.yitter.info> In-Reply-To: <20131217144205.GC2761@mx1.yitter.info> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 14:49:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldw0KPiBTdWxsaXZhbg0KPiBT ZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNywgMjAxMyA5OjQyIEFNDQo+IFRvOiB3ZWlyZHNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt3ZWlyZHNdIFVwZGF0ZWQgU2VhcmNoIFByb2Nlc3Npbmcg VGV4dCBQcm9wb3NhbA0KPiANCj4gT24gVHVlLCBEZWMgMTcsIDIwMTMgYXQgMDE6MjQ6NTlQTSAr MDAwMCwgSG9sbGVuYmVjaywgU2NvdHQgd3JvdGU6DQo+IA0KPiA+IENhc2UgaW5zZW5zaXRpdmUg cGF0dGVybiBtYXRjaGluZyBTSE9VTEQgYmUgdXNlZCB0byBjb21wYXJlIFVTLUFTQ0lJDQo+ID4g Y2hhcmFjdGVycyBpbiBxdWVyeSBwYXR0ZXJucy4NCj4gDQo+IEkgc3RpbGwgdmVyeSBzdHJvbmds eSBzdWdnZXN0IHRoYXQgdGhlIGJlaGF2aW91ciBuZWVkcyB0byBiZQ0KPiBzdHJpbmctYmFzZWQs IG5vdCBjaGFyYWN0ZXItYmFzZWQuICBJZiB5b3UncmUgZ29pbmcgdG8gZG8gY2FzZQ0KPiBpbnNl bnNpdGl2ZSB3b3JrLCB5b3UgbmVlZCB0byB1c2UgVW5pY29kZSBjYXNlIGZvbGRpbmcsIG5vdCBk byBjYXNlDQo+IGZvbGRpbmcgZm9yIHNvbWUgY2hhcmFjdGVycyBhbmQgbm90IG90aGVycy4gIFRo ZSBhYm92ZSBoYXMgdGhlIGFic3VyZA0KPiBjb25zZXF1ZW5jZSB0aGF0IMOpY29sZSBhbmQgw4lj b2xlIGRvbid0IG1hdGNoLCBidXQgw6ljb2xlIGFuZCDDqUNvbGUgZG8uDQo+IA0KPiBXZSBzYWlk IHdlIGRpZG4ndCB3YW50IHRvIGdldCBpbnRvIHRoZSBjb21wbGljYXRpb25zIG9mIGNhc2UgZm9s ZGluZw0KPiBvciB0aGUgZGlzYXN0ZXIgdGhhdCB3aWxsIHJlc3VsdCBmcm9tIHRyeWluZyB0byBk bw0KPiBkZWNvcmF0ZWQtdnMtdW5kZWNvcmF0ZWQgY2hhcmFjdGVyIG1hdGNoaW5nLCB3aGljaCBp cyB3aHkgbm90IHRvIHVzZQ0KPiBhbGwgb2YgY2FzZSBmb2xkaW5nLiAgU28gSSBjYW4gc2VlIGFu IGFyZ3VtZW50IGZvciBjYXNlIGluc2Vuc2l0aXZpdHkNCj4gZm9yIEFTQ0lJIHN0cmluZ3MsIGJ1 dCBvbmUgY2Fubm90IGRvIHRoaXMgY2hhcmFjdGVyIGJ5IGNoYXJhY3Rlci4NCg0KU28gaG93IHdv dWxkIHlvdSBzdWdnZXN0IHJlLXdvcmRpbmcgdGhhdCBzZW50ZW5jZT8NCg0KU2NvdHQNCg== From ajs@anvilwalrusden.com Tue Dec 17 07:09:32 2013 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 286DD1AE022 for ; Tue, 17 Dec 2013 07:09:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 4enS6xVgS7Jk for ; Tue, 17 Dec 2013 07:09:14 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9F21ADF5E for ; Tue, 17 Dec 2013 07:09:14 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 7A11C8A031 for ; Tue, 17 Dec 2013 15:00:36 +0000 (UTC) Date: Tue, 17 Dec 2013 10:00:35 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131217150034.GD2761@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217144205.GC2761@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F49305A49@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49305A49@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 15:09:32 -0000 On Tue, Dec 17, 2013 at 02:48:59PM +0000, Hollenbeck, Scott wrote: > So how would you suggest re-wording that sentence? If and only if the entire query pattern uses only Unicode characters from the US-ASCII range, then case insensitive pattern matching SHOULD be used. Otherwise, no case folding is performed. I confess that I expect this will be a controversial position. Certainly, from experience, I expect people from the .gr registry to react very negatively to such a proposal. If we're going to deal with case, the only alternative to the above (which people said they didn't like on grounds of complication) is to use Unicode case folding all the time. If you do that, you have to decide whether to handle SpecialCasing or not. If you want text for this approach, I can come up with something but it'll be more complicated than the above. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Tue Dec 17 10:23:18 2013 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 71C241AE1FF for ; Tue, 17 Dec 2013 10:23:18 -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 W67TrBCfmJVx for ; Tue, 17 Dec 2013 10:23:16 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id 55EAA1AE211 for ; Tue, 17 Dec 2013 10:23:16 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUrCWk5a+7omUV+YVhy2BRR3YkyHskXnu@postini.com; Tue, 17 Dec 2013 10:23:15 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 rBHIMYOs019042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 17 Dec 2013 13:23:14 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 17 Dec 2013 13:22:34 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Updated Search Processing Text Proposal Thread-Index: Ac77K2BvBWI8u+MwTDGfQnY8BC6IGAANK/qAAApNhRD//7K/gIAAG8Yg Date: Tue, 17 Dec 2013 18:22:33 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217144205.GC2761@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F49305A49@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217150034.GD2761@mx1.yitter.info> In-Reply-To: <20131217150034.GD2761@mx1.yitter.info> 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 Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 18:23:18 -0000 > -----Original Message----- > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > Sullivan > Sent: Tuesday, December 17, 2013 10:01 AM > To: weirds@ietf.org > Subject: Re: [weirds] Updated Search Processing Text Proposal >=20 > On Tue, Dec 17, 2013 at 02:48:59PM +0000, Hollenbeck, Scott wrote: >=20 > > So how would you suggest re-wording that sentence? >=20 > If and only if the entire query pattern uses only Unicode > characters from the US-ASCII range, then case insensitive pattern > matching SHOULD be used. Otherwise, no case folding is performed. >=20 > I confess that I expect this will be a controversial position. > Certainly, from experience, I expect people from the .gr registry to > react very negatively to such a proposal. >=20 > If we're going to deal with case, the only alternative to the above > (which people said they didn't like on grounds of complication) is to > use Unicode case folding all the time. If you do that, you have to > decide whether to handle SpecialCasing or not. If you want text for > this approach, I can come up with something but it'll be more > complicated than the above. Is this not acceptable to anyone? Scott From andy@arin.net Tue Dec 17 10:36:04 2013 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 6F1F21AE0C3 for ; Tue, 17 Dec 2013 10:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 5K7oJ21JZHdk for ; Tue, 17 Dec 2013 10:36:02 -0800 (PST) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by ietfa.amsl.com (Postfix) with ESMTP id A674F1AE087 for ; Tue, 17 Dec 2013 10:36:02 -0800 (PST) Received: by smtp2.arin.net (Postfix, from userid 323) id 92D022136AB; Tue, 17 Dec 2013 13:36:01 -0500 (EST) Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp2.arin.net (Postfix) with ESMTP id DFA3D213666; Tue, 17 Dec 2013 13:36:00 -0500 (EST) 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, 17 Dec 2013 13:36:00 -0500 Received: from CHAXCH01.corp.arin.net ([169.254.1.174]) by CHAXCH03.corp.arin.net ([10.1.30.17]) with mapi id 14.02.0328.009; Tue, 17 Dec 2013 13:35:56 -0500 From: Andy Newton To: "Hollenbeck, Scott" , Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Updated Search Processing Text Proposal Thread-Index: Ac77K2BvBWI8u+MwTDGfQnY8BC6IGAANK/qAAApNhRD//7K/gIAAG8Yg///MkQA= Date: Tue, 17 Dec 2013 18:35:56 +0000 Message-ID: In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> 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: text/plain; charset="us-ascii" Content-ID: <54024520287ECB468152BE1A2BCD5C9D@corp.arin.net> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 18:36:04 -0000 On 12/17/13 1:22 PM, "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew >> Sullivan >> Sent: Tuesday, December 17, 2013 10:01 AM >> To: weirds@ietf.org >> Subject: Re: [weirds] Updated Search Processing Text Proposal >>=20 >> On Tue, Dec 17, 2013 at 02:48:59PM +0000, Hollenbeck, Scott wrote: >>=20 >> > So how would you suggest re-wording that sentence? >>=20 >> If and only if the entire query pattern uses only Unicode >> characters from the US-ASCII range, then case insensitive pattern >> matching SHOULD be used. Otherwise, no case folding is performed. >>=20 >> I confess that I expect this will be a controversial position. >> Certainly, from experience, I expect people from the .gr registry to >> react very negatively to such a proposal. >>=20 >> If we're going to deal with case, the only alternative to the above >> (which people said they didn't like on grounds of complication) is to >> use Unicode case folding all the time. If you do that, you have to >> decide whether to handle SpecialCasing or not. If you want text for >> this approach, I can come up with something but it'll be more >> complicated than the above. > >Is this not acceptable to anyone? I agree with this in principle, but I guess it depends on the details. Is special casing with Unicode commonly found in libraries? If not, we probably ought to punt on this. -andy From ajs@anvilwalrusden.com Tue Dec 17 15:19:20 2013 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 8CD5B1ADD9A for ; Tue, 17 Dec 2013 15:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 y3Vm5clUHx6y for ; Tue, 17 Dec 2013 15:19:18 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E21131ADC03 for ; Tue, 17 Dec 2013 15:19:16 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D6F198A031 for ; Tue, 17 Dec 2013 19:49:21 +0000 (UTC) Date: Tue, 17 Dec 2013 14:49:20 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131217194920.GG2761@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 17 Dec 2013 23:19:20 -0000 On Tue, Dec 17, 2013 at 06:35:56PM +0000, Andy Newton wrote: > > Is special casing with Unicode commonly found in libraries? If not, we > probably ought to punt on this. The problem is that special casing is Hard. It's the thing that, just for instance, copes with the fact that the character "i" is the lower case of "I" in every language except Turkish. In Turkish, it is the lower case of "İ" (U+0130), and the lower case of "I" is "ı" (U+0131). What this means is that special casing is locale-sensitive. But we don't have a mechanism AFAICT for communicating locale for this sort of thing. This makes me feel like special-casing search should not be included, and there should be text that says "we're not doing any of that". Therefore, here's another suggestion: An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server MAY immediately stop processing the query and return an HTTP 400 error response code. When processing queries, there is a difference in handling DNS names, including those including putative U-labels, and everything else. DNS names are treated according to the DNS matching rules as described in Section 3.1 of RFC 1035 [RFC1035] for NR-LDH labels and the matching rules described in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of DNS names proceeds one label at a time, because it is possible for a combination of U-labels and NR-LDH labels to be found in a single domain or host name. The determination of whether a label is a U-label or an NR-LDH label is based on whether the label contains any characters outside of the US-ASCII letters, digits, or hyphen (the so-called LDH rule). For everything else, servers SHOULD map fullwidth and halfwidth characters to their decomposition equivalents. Servers SHOULD convert strings to the same coded character set of the target data that is to be looked up or searched and each string SHOULD be normalized using the same normalization that was used on the target data. In general, storage of strings as Unicode is RECOMMENDED. For the purposes of comparison, Normalization Form KC (NFKC, [Unicode-UAX15]) with case folding is RECOMMENDED to maximize predictability and the number of matches. Note the use of case-folded NFKC as opposed to NFC in this case. This is still only for search, right, and not for exact matching? (That's my impression given the text we're adjusting.) That is, my intention is that the above apply to search, because I think case folded format (==NFKC + case fold) is more likely to yield matches; but I think NFC and unfolded is a better exact-string matching answer, which is why it's still called for here in the U-label matching. Sorry for the thrash on this topic. Internationalization sucks. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From superuser@gmail.com Tue Dec 17 18:08:59 2013 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 4AC6E1AE1D5 for ; Tue, 17 Dec 2013 18:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.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, GB_I_LETTER=-2, 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 Osdln2oEI8_9 for ; Tue, 17 Dec 2013 18:08:56 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4861AE1D0 for ; Tue, 17 Dec 2013 18:08:56 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u57so6880100wes.37 for ; Tue, 17 Dec 2013 18:08:54 -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=VQqkPwvIioAzsdhJPwkjM0MlIJ2wgg7mATx1kctRp1g=; b=c3bainLDtnBZBPxJiqH3wG21mz5VTX4s/nKoaZASRGKw/TdbZiDg+GiNpzL+UyCyiF FJN9UCG7tgg0xSyZb50vO3HeP7ocVbLiGp1NrokvetgOUVsLRQirb6mRfDMMi8NVjZuq 7MfyJeFCQUyfZbVNjeDO15lDam0V2LeeBUpHiHbIR9t9wSW+Tvjaokj9EZSCjBc5toZ3 mU4WM9v96oay4IcQOztkQdAG0o+uiY6dbbMjX/nKIJFV1khWsI57ddZfZMJJ1aXwen7+ ZIjc+l3/e/t2QR0w3ahTiEwQJxtXNFCLM+AtUZKK8VQE5sXi5FJSrTQ9Nh207FUgYQKR wvsg== MIME-Version: 1.0 X-Received: by 10.194.201.225 with SMTP id kd1mr21978886wjc.35.1387332534730; Tue, 17 Dec 2013 18:08:54 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 17 Dec 2013 18:08:54 -0800 (PST) In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49305696@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Tue, 17 Dec 2013 18:08:54 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Hollenbeck, Scott" Content-Type: multipart/alternative; boundary=047d7b86f172eb07d004edc58637 Cc: "weirds@ietf.org" Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 18 Dec 2013 02:08:59 -0000 --047d7b86f172eb07d004edc58637 Content-Type: text/plain; charset=ISO-8859-1 Participatorially speaking, On Tue, Dec 17, 2013 at 5:24 AM, Hollenbeck, Scott wrote: > Proposed new text: > > An RDAP client submitting a query string containing non-US-ASCII > characters SHOULD convert such strings into Unicode in UTF-8 encoding. It > MAY perform any local case mapping deemed necessary. It SHOULD normalize > the strings using Normalization Form C (NFC, [Unicode-UAX15]); note that > clients might not be able to do this reliably. > Having been beaten about the head and neck with a thick stick on this topic, I've become sensitive to it. The SHOULDs here automatically have me asking questions like "Under what circumstances would you not do this? Why isn't it a MUST? What's the nature of the discretion left to the implementer?" I've also been encouraged recently to, upon using a SHOULD, also add a sentence giving an example or guidance of a situation in which an implementation would reasonably opt to do something else, or at least what breaks if the implementer chooses not to comply. > An RDAP server SHOULD treat each query string as Unicode in UTF-8 > encoding. If a string is not valid UTF-8, the server MAY immediately stop > processing the query and return an HTTP 400 error response code. Servers > SHOULD map fullwidth and halfwidth characters to their decomposition > equivalents. Servers SHOULD convert strings to the same coded character set > of the target data that is to be looked up or searched and each string > SHOULD be normalized using the same normalization that was used on the > target data. Normalization Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to > be consistent with IDNA [RFC5891] and to maximize predictability and > interoperability. Case insensitive pattern matching SHOULD be used to > compare US-ASCII characters in query patterns. > Another thing that's been suggested to me, which might be simpler, is to drop the RFC2119 language altogether. Instead of saying "X SHOULD/MUST do Y", simply say "X does Y"; the implication here is that if X doesn't do Y, it's simply not implementing RDAP. Also, this is entirely SHOULD and RECOMMENDED stuff. That means an implementer is entirely within its rights to do something completely different than what's specified here, and still claim compliance. How interoperable would such a thing really be? > > DNS names are treated according to the DNS matching rules as described in > Section 3.1 of RFC 1035 [RFC1035] for NR-LDH labels and the matching rules > described in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of > DNS names proceeds one label at a time, because it is possible for a > combination of U-labels and NR-LDH labels to be found in a single domain or > host name. The determination of whether a label is a U-label or an NR-LDH > label is based on whether the label contains any characters outside of the > US-ASCII letters, digits, or hyphen (the so-called LDH rule). > Here's an example where "are" is there where in the previous paragraph we use "SHOULD/MUST be". It might be just fine to write the earlier paragraph that way. I don't feel particularly strongly about this, but I think if we were to move forward with this as-is, we should expect our ADs to ask these questions and be prepared to answer them. -MSK, still nursing past RFC2119 welts --047d7b86f172eb07d004edc58637 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Participatorially speaking,

On Tue, Dec 17, 2013 at= 5:24 AM, Hollenbeck, Scott <shollenbeck@verisign.com> wrote:
Proposed new text:

An RDAP client submitting a query string containing non-US-ASCII characters= SHOULD convert such strings into Unicode in UTF-8 encoding. It MAY perform= any local case mapping deemed necessary. It SHOULD normalize the strings u= sing Normalization Form C (NFC, [Unicode-UAX15]); note that clients might n= ot be able to do this reliably.

Having been beaten about the head and neck= with a thick stick on this topic, I've become sensitive to it.

= The SHOULDs here automatically have me asking questions like "Under wh= at circumstances would you not do this?=A0 Why isn't it a MUST?=A0 What= 's the nature of the discretion left to the implementer?"=A0 I'= ;ve also been encouraged recently to, upon using a SHOULD, also add a sente= nce giving an example or guidance of a situation in which an implementation= would reasonably opt to do something else, or at least what breaks if the = implementer chooses not to comply.
=A0
An RDAP server SHOULD treat each query string as Unicode in UTF-8 encoding.= If a string is not valid UTF-8, the server MAY immediately stop processing= the query and return an HTTP 400 error response code. =A0Servers SHOULD ma= p fullwidth and halfwidth characters to their decomposition equivalents. Se= rvers SHOULD convert strings to the same coded character set of the target = data that is to be looked up or searched and each string SHOULD be normaliz= ed using the same normalization that was used on the target data. Normaliza= tion Form C (NFC, [Unicode-UAX15]) is RECOMMENDED to be consistent with IDN= A [RFC5891] and to maximize predictability and interoperability. Case insen= sitive pattern matching SHOULD be used to compare US-ASCII characters in qu= ery patterns.

Another thing that's been suggested to= me, which might be simpler, is to drop the RFC2119 language altogether.=A0= Instead of saying "X SHOULD/MUST do Y", simply say "X does = Y"; the implication here is that if X doesn't do Y, it's simpl= y not implementing RDAP.

Also, this is entirely SHOULD and RECOMMENDED stuff.=A0 That mean= s an implementer is entirely within its rights to do something completely d= ifferent than what's specified here, and still claim compliance.=A0 How= interoperable would such a thing really be?
=A0

DNS names are treated according to the DNS matching rules as described in S= ection 3.1 of RFC 1035 [RFC1035] for NR-LDH labels and the matching rules d= escribed in Section 5.4 of RFC 5891 [RFC5891] for U-labels. =A0Matching of = DNS names proceeds one label at a time, because it is possible for a combin= ation of U-labels and NR-LDH labels to be found in a single domain or host = name. The determination of whether a label is a U-label or an NR-LDH label = is based on whether the label contains any characters outside of the US-ASC= II letters, digits, or hyphen (the so-called LDH rule).

Here's an example where "are"= ; is there where in the previous paragraph we use "SHOULD/MUST be"= ;.=A0 It might be just fine to write the earlier paragraph that way.
I don't feel particularly strongly about this, but I think i= f we were to move forward with this as-is, we should expect our ADs to ask = these questions and be prepared to answer them.

-MSK, still nursing = past RFC2119 welts
--047d7b86f172eb07d004edc58637-- From shollenbeck@verisign.com Wed Dec 18 05:09:09 2013 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 2CA781AE1E5 for ; Wed, 18 Dec 2013 05:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 XAEhcTj0lQpq for ; Wed, 18 Dec 2013 05:09:07 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id AE8081AE1D1 for ; Wed, 18 Dec 2013 05:09:04 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUrGeb9p6qZO4S15ZKECb5pY4sgk0YWYR@postini.com; Wed, 18 Dec 2013 05:09:06 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 rBID92Xv018237 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 08:09:02 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Dec 2013 08:09:02 -0500 From: "Hollenbeck, Scott" To: "Murray S. Kucherawy" , Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Updated Search Processing Text Proposal Thread-Index: AQHO+2ETBWI8u+MwTDGfQnY8BC6IGJpZ6tCA Date: Wed, 18 Dec 2013 13:09:01 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49306776@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217194920.GG2761@mx1.yitter.info> In-Reply-To: <20131217194920.GG2761@mx1.yitter.info> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 18 Dec 2013 13:09:09 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldw0KPiBTdWxsaXZhbg0KPiBT ZW50OiBUdWVzZGF5LCBEZWNlbWJlciAxNywgMjAxMyAyOjQ5IFBNDQo+IFRvOiB3ZWlyZHNAaWV0 Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt3ZWlyZHNdIFVwZGF0ZWQgU2VhcmNoIFByb2Nlc3Npbmcg VGV4dCBQcm9wb3NhbA0KPiANCj4gT24gVHVlLCBEZWMgMTcsIDIwMTMgYXQgMDY6MzU6NTZQTSAr MDAwMCwgQW5keSBOZXd0b24gd3JvdGU6DQo+ID4NCj4gPiBJcyBzcGVjaWFsIGNhc2luZyB3aXRo IFVuaWNvZGUgY29tbW9ubHkgZm91bmQgaW4gbGlicmFyaWVzPyBJZiBub3QsDQo+IHdlDQo+ID4g cHJvYmFibHkgb3VnaHQgdG8gcHVudCBvbiB0aGlzLg0KPiANCj4gVGhlIHByb2JsZW0gaXMgdGhh dCBzcGVjaWFsIGNhc2luZyBpcyBIYXJkLiAgSXQncyB0aGUgdGhpbmcgdGhhdCwganVzdA0KPiBm b3IgaW5zdGFuY2UsIGNvcGVzIHdpdGggdGhlIGZhY3QgdGhhdCB0aGUgY2hhcmFjdGVyICJpIiBp cyB0aGUgbG93ZXINCj4gY2FzZSBvZiAiSSIgaW4gZXZlcnkgbGFuZ3VhZ2UgZXhjZXB0IFR1cmtp c2guICBJbiBUdXJraXNoLCBpdCBpcyB0aGUNCj4gbG93ZXIgY2FzZSBvZiAixLAiIChVKzAxMzAp LCBhbmQgdGhlIGxvd2VyIGNhc2Ugb2YgIkkiIGlzICLEsSIgKFUrMDEzMSkuDQo+IFdoYXQgdGhp cyBtZWFucyBpcyB0aGF0IHNwZWNpYWwgY2FzaW5nIGlzIGxvY2FsZS1zZW5zaXRpdmUuICBCdXQg d2UNCj4gZG9uJ3QgaGF2ZSBhIG1lY2hhbmlzbSBBRkFJQ1QgZm9yIGNvbW11bmljYXRpbmcgbG9j YWxlIGZvciB0aGlzIHNvcnQNCj4gb2YgdGhpbmcuDQo+IA0KPiBUaGlzIG1ha2VzIG1lIGZlZWwg bGlrZSBzcGVjaWFsLWNhc2luZyBzZWFyY2ggc2hvdWxkIG5vdCBiZSBpbmNsdWRlZCwNCj4gYW5k IHRoZXJlIHNob3VsZCBiZSB0ZXh0IHRoYXQgc2F5cyAid2UncmUgbm90IGRvaW5nIGFueSBvZiB0 aGF0Ii4NCj4gVGhlcmVmb3JlLCBoZXJlJ3MgYW5vdGhlciBzdWdnZXN0aW9uOg0KPiANCj4gICAg IEFuIFJEQVAgc2VydmVyIFNIT1VMRCB0cmVhdCBlYWNoIHF1ZXJ5IHN0cmluZyBhcyBVbmljb2Rl IGluIFVURi04DQo+ICAgICBlbmNvZGluZy4gIElmIGEgc3RyaW5nIGlzIG5vdCB2YWxpZCBVVEYt OCwgdGhlIHNlcnZlciBNQVkNCj4gICAgIGltbWVkaWF0ZWx5IHN0b3AgcHJvY2Vzc2luZyB0aGUg cXVlcnkgYW5kIHJldHVybiBhbiBIVFRQIDQwMCBlcnJvcg0KPiAgICAgcmVzcG9uc2UgY29kZS4N Cj4gDQo+ICAgICBXaGVuIHByb2Nlc3NpbmcgcXVlcmllcywgdGhlcmUgaXMgYSBkaWZmZXJlbmNl IGluIGhhbmRsaW5nIEROUw0KPiAgICAgbmFtZXMsIGluY2x1ZGluZyB0aG9zZSBpbmNsdWRpbmcg cHV0YXRpdmUgVS1sYWJlbHMsIGFuZCBldmVyeXRoaW5nDQo+ICAgICBlbHNlLiAgRE5TIG5hbWVz IGFyZSB0cmVhdGVkIGFjY29yZGluZyB0byB0aGUgRE5TIG1hdGNoaW5nIHJ1bGVzDQo+ICAgICBh cyBkZXNjcmliZWQgaW4gU2VjdGlvbiAzLjEgb2YgUkZDIDEwMzUgW1JGQzEwMzVdIGZvciBOUi1M REgNCj4gICAgIGxhYmVscyBhbmQgdGhlIG1hdGNoaW5nIHJ1bGVzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDUuNCBvZiBSRkMgNTg5MQ0KPiAgICAgW1JGQzU4OTFdIGZvciBVLWxhYmVscy4gIE1hdGNo aW5nIG9mIEROUyBuYW1lcyBwcm9jZWVkcyBvbmUgbGFiZWwNCj4gICAgIGF0IGEgdGltZSwgYmVj YXVzZSBpdCBpcyBwb3NzaWJsZSBmb3IgYSBjb21iaW5hdGlvbiBvZiBVLWxhYmVscw0KPiAgICAg YW5kIE5SLUxESCBsYWJlbHMgdG8gYmUgZm91bmQgaW4gYSBzaW5nbGUgZG9tYWluIG9yIGhvc3Qg bmFtZS4gVGhlDQo+ICAgICBkZXRlcm1pbmF0aW9uIG9mIHdoZXRoZXIgYSBsYWJlbCBpcyBhIFUt bGFiZWwgb3IgYW4gTlItTERIIGxhYmVsDQo+ICAgICBpcyBiYXNlZCBvbiB3aGV0aGVyIHRoZSBs YWJlbCBjb250YWlucyBhbnkgY2hhcmFjdGVycyBvdXRzaWRlIG9mDQo+ICAgICB0aGUgVVMtQVND SUkgbGV0dGVycywgZGlnaXRzLCBvciBoeXBoZW4gKHRoZSBzby1jYWxsZWQgTERIIHJ1bGUpLg0K PiANCj4gICAgIEZvciBldmVyeXRoaW5nIGVsc2UsIHNlcnZlcnMgU0hPVUxEIG1hcCBmdWxsd2lk dGggYW5kIGhhbGZ3aWR0aA0KPiAgICAgY2hhcmFjdGVycyB0byB0aGVpciBkZWNvbXBvc2l0aW9u IGVxdWl2YWxlbnRzLiAgU2VydmVycyBTSE9VTEQNCj4gICAgIGNvbnZlcnQgc3RyaW5ncyB0byB0 aGUgc2FtZSBjb2RlZCBjaGFyYWN0ZXIgc2V0IG9mIHRoZSB0YXJnZXQgZGF0YQ0KPiAgICAgdGhh dCBpcyB0byBiZSBsb29rZWQgdXAgb3Igc2VhcmNoZWQgYW5kIGVhY2ggc3RyaW5nIFNIT1VMRCBi ZQ0KPiAgICAgbm9ybWFsaXplZCB1c2luZyB0aGUgc2FtZSBub3JtYWxpemF0aW9uIHRoYXQgd2Fz IHVzZWQgb24gdGhlDQo+ICAgICB0YXJnZXQgZGF0YS4gIEluIGdlbmVyYWwsIHN0b3JhZ2Ugb2Yg c3RyaW5ncyBhcyBVbmljb2RlIGlzDQo+ICAgICBSRUNPTU1FTkRFRC4gIEZvciB0aGUgcHVycG9z ZXMgb2YgY29tcGFyaXNvbiwgTm9ybWFsaXphdGlvbiBGb3JtDQo+ICAgICBLQyAoTkZLQywgW1Vu aWNvZGUtVUFYMTVdKSB3aXRoIGNhc2UgZm9sZGluZyBpcyBSRUNPTU1FTkRFRCB0bw0KPiAgICAg bWF4aW1pemUgcHJlZGljdGFiaWxpdHkgYW5kIHRoZSBudW1iZXIgb2YgbWF0Y2hlcy4gIE5vdGUg dGhlIHVzZQ0KPiAgICAgb2YgY2FzZS1mb2xkZWQgTkZLQyBhcyBvcHBvc2VkIHRvIE5GQyBpbiB0 aGlzIGNhc2UuDQoNCkxldCBtZSB0cnkgdG8gdGFrZSBhIGNyYWNrIGF0IGFkZHJlc3NpbmcgTXVy cmF5J3MgU0hPVUxEL01VU1QgY29tbWVudCBbMV0gc3RhcnRpbmcgd2l0aCBBbmRyZXcncyB0ZXh0 IGFib3ZlOg0KDQpBbiBSREFQIHNlcnZlciB0cmVhdHMgZWFjaCBxdWVyeSBzdHJpbmcgYXMgVW5p Y29kZSBpbiBVVEYtOCBlbmNvZGluZy4gIElmIGEgc3RyaW5nIGlzIG5vdCB2YWxpZCBVVEYtOCwg dGhlIHNlcnZlciBjYW4gaW1tZWRpYXRlbHkgc3RvcCBwcm9jZXNzaW5nIHRoZSBxdWVyeSBhbmQg cmV0dXJuIGFuIEhUVFAgNDAwIGVycm9yIHJlc3BvbnNlIGNvZGUuICANCg0KV2hlbiBwcm9jZXNz aW5nIHF1ZXJpZXMsIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBpbiBoYW5kbGluZyBETlMgbmFtZXMs IGluY2x1ZGluZyB0aG9zZSBpbmNsdWRpbmcgcHV0YXRpdmUgVS1sYWJlbHMsIGFuZCBldmVyeXRo aW5nIGVsc2UuICBETlMgbmFtZXMgYXJlIHRyZWF0ZWQgYWNjb3JkaW5nIHRvIHRoZSBETlMgbWF0 Y2hpbmcgcnVsZXMgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gMy4xIG9mIFJGQyAxMDM1IFtSRkMx MDM1XSBmb3IgTlItTERIIGxhYmVscyBhbmQgdGhlIG1hdGNoaW5nIHJ1bGVzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDUuNCBvZiBSRkMgNTg5MSBbUkZDNTg5MV0gZm9yIFUtbGFiZWxzLiAgTWF0Y2hp bmcgb2YgRE5TIG5hbWVzIHByb2NlZWRzIG9uZSBsYWJlbCBhdCBhIHRpbWUsIGJlY2F1c2UgaXQg aXMgcG9zc2libGUgZm9yIGEgY29tYmluYXRpb24gb2YgVS1sYWJlbHMgYW5kIE5SLUxESCBsYWJl bHMgdG8gYmUgZm91bmQgaW4gYSBzaW5nbGUgZG9tYWluIG9yIGhvc3QgbmFtZS4gVGhlIGRldGVy bWluYXRpb24gb2Ygd2hldGhlciBhIGxhYmVsIGlzIGEgVS1sYWJlbCBvciBhbiBOUi1MREggbGFi ZWwgaXMgYmFzZWQgb24gd2hldGhlciB0aGUgbGFiZWwgY29udGFpbnMgYW55IGNoYXJhY3RlcnMg b3V0c2lkZSBvZiB0aGUgVVMtQVNDSUkgbGV0dGVycywgZGlnaXRzLCBvciBoeXBoZW4gKHRoZSBz by1jYWxsZWQgTERIIHJ1bGUpLg0KDQpGb3IgZXZlcnl0aGluZyBlbHNlLCBzZXJ2ZXJzIG1hcCBm dWxsd2lkdGggYW5kIGhhbGZ3aWR0aCBjaGFyYWN0ZXJzIHRvIHRoZWlyIGRlY29tcG9zaXRpb24g ZXF1aXZhbGVudHMuICBTZXJ2ZXJzIGNvbnZlcnQgc3RyaW5ncyB0byB0aGUgc2FtZSBjb2RlZCBj aGFyYWN0ZXIgc2V0IG9mIHRoZSB0YXJnZXQgZGF0YSB0aGF0IGlzIHRvIGJlIGxvb2tlZCB1cCBv ciBzZWFyY2hlZCBhbmQgZWFjaCBzdHJpbmcgaXMgbm9ybWFsaXplZCB1c2luZyB0aGUgc2FtZSBu b3JtYWxpemF0aW9uIHRoYXQgd2FzIHVzZWQgb24gdGhlIHRhcmdldCBkYXRhLiAgSW4gZ2VuZXJh bCwgc3RvcmFnZSBvZiBzdHJpbmdzIGFzIFVuaWNvZGUgaXMgUkVDT01NRU5ERUQuICBGb3IgdGhl IHB1cnBvc2VzIG9mIGNvbXBhcmlzb24sIE5vcm1hbGl6YXRpb24gRm9ybSBLQyAoTkZLQywgW1Vu aWNvZGUtVUFYMTVdKSB3aXRoIGNhc2UgZm9sZGluZyBpcyB1c2VkIHRvIG1heGltaXplIHByZWRp Y3RhYmlsaXR5IGFuZCB0aGUgbnVtYmVyIG9mIG1hdGNoZXMuICBOb3RlIHRoZSB1c2Ugb2YgY2Fz ZS1mb2xkZWQgTkZLQyBhcyBvcHBvc2VkIHRvIE5GQyBpbiB0aGlzIGNhc2UuDQoNClNjb3R0DQoN ClsxXSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvd2VpcmRzL2N1cnJlbnQv bXNnMDM1MDkuaHRtbA0K From ajs@anvilwalrusden.com Wed Dec 18 05:20:06 2013 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 89EBD1AE3CE for ; Wed, 18 Dec 2013 05:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.141 X-Spam-Level: X-Spam-Status: No, score=-2.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 vbElgh7ppPg0 for ; Wed, 18 Dec 2013 05:20:04 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5128A1AE1E5 for ; Wed, 18 Dec 2013 05:20:03 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id BF44D8A031 for ; Wed, 18 Dec 2013 13:20:01 +0000 (UTC) Date: Wed, 18 Dec 2013 08:19:56 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131218131956.GA5938@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217194920.GG2761@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F49306776@BRN1WNEXMBX01.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49306776@BRN1WNEXMBX01.vcorp.ad.vrsn.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 18 Dec 2013 13:20:06 -0000 This is ok with me. It strikes me, however, that RFC 2119 is having pretty perverse effects if we're now rewriting text to get around using those precise definitions, in order not to get into picky procedural arguments. :( On Wed, Dec 18, 2013 at 01:09:01PM +0000, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: weirds [mailto:weirds-bounces@ietf.org] On Behalf Of Andrew > > Sullivan > > Sent: Tuesday, December 17, 2013 2:49 PM > > To: weirds@ietf.org > > Subject: Re: [weirds] Updated Search Processing Text Proposal > > > > On Tue, Dec 17, 2013 at 06:35:56PM +0000, Andy Newton wrote: > > > > > > Is special casing with Unicode commonly found in libraries? If not, > > we > > > probably ought to punt on this. > > > > The problem is that special casing is Hard. It's the thing that, just > > for instance, copes with the fact that the character "i" is the lower > > case of "I" in every language except Turkish. In Turkish, it is the > > lower case of "İ" (U+0130), and the lower case of "I" is "ı" (U+0131). > > What this means is that special casing is locale-sensitive. But we > > don't have a mechanism AFAICT for communicating locale for this sort > > of thing. > > > > This makes me feel like special-casing search should not be included, > > and there should be text that says "we're not doing any of that". > > Therefore, here's another suggestion: > > > > An RDAP server SHOULD treat each query string as Unicode in UTF-8 > > encoding. If a string is not valid UTF-8, the server MAY > > immediately stop processing the query and return an HTTP 400 error > > response code. > > > > When processing queries, there is a difference in handling DNS > > names, including those including putative U-labels, and everything > > else. DNS names are treated according to the DNS matching rules > > as described in Section 3.1 of RFC 1035 [RFC1035] for NR-LDH > > labels and the matching rules described in Section 5.4 of RFC 5891 > > [RFC5891] for U-labels. Matching of DNS names proceeds one label > > at a time, because it is possible for a combination of U-labels > > and NR-LDH labels to be found in a single domain or host name. The > > determination of whether a label is a U-label or an NR-LDH label > > is based on whether the label contains any characters outside of > > the US-ASCII letters, digits, or hyphen (the so-called LDH rule). > > > > For everything else, servers SHOULD map fullwidth and halfwidth > > characters to their decomposition equivalents. Servers SHOULD > > convert strings to the same coded character set of the target data > > that is to be looked up or searched and each string SHOULD be > > normalized using the same normalization that was used on the > > target data. In general, storage of strings as Unicode is > > RECOMMENDED. For the purposes of comparison, Normalization Form > > KC (NFKC, [Unicode-UAX15]) with case folding is RECOMMENDED to > > maximize predictability and the number of matches. Note the use > > of case-folded NFKC as opposed to NFC in this case. > > Let me try to take a crack at addressing Murray's SHOULD/MUST comment [1] starting with Andrew's text above: > > An RDAP server treats each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server can immediately stop processing the query and return an HTTP 400 error response code. > > When processing queries, there is a difference in handling DNS names, including those including putative U-labels, and everything else. DNS names are treated according to the DNS matching rules as described in Section 3.1 of RFC 1035 [RFC1035] for NR-LDH labels and the matching rules described in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of DNS names proceeds one label at a time, because it is possible for a combination of U-labels and NR-LDH labels to be found in a single domain or host name. The determination of whether a label is a U-label or an NR-LDH label is based on whether the label contains any characters outside of the US-ASCII letters, digits, or hyphen (the so-called LDH rule). > > For everything else, servers map fullwidth and halfwidth characters to their decomposition equivalents. Servers convert strings to the same coded character set of the target data that is to be looked up or searched and each string is normalized using the same normalization that was used on the target data. In general, storage of strings as Unicode is RECOMMENDED. For the purposes of comparison, Normalization Form KC (NFKC, [Unicode-UAX15]) with case folding is used to maximize predictability and the number of matches. Note the use of case-folded NFKC as opposed to NFC in this case. > > Scott > > [1] http://www.ietf.org/mail-archive/web/weirds/current/msg03509.html -- Andrew Sullivan ajs@anvilwalrusden.com From shollenbeck@verisign.com Wed Dec 18 05:26:42 2013 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 35FEE1AE2F3 for ; Wed, 18 Dec 2013 05:26:42 -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 tUPMXZatd_dt for ; Wed, 18 Dec 2013 05:26:40 -0800 (PST) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id 399B51AE0CA for ; Wed, 18 Dec 2013 05:26:39 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKUrGijdz2j8P/sObC2sh91vshvSX5rcgF@postini.com; Wed, 18 Dec 2013 05:26:39 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 rBIDQaiU018689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 08:26:37 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Dec 2013 08:26:36 -0500 From: "Hollenbeck, Scott" To: Andrew Sullivan , "weirds@ietf.org" Thread-Topic: [weirds] Updated Search Processing Text Proposal Thread-Index: AQHO+2ETBWI8u+MwTDGfQnY8BC6IGJpZ6tCAgABZ7wD//61sIA== Date: Wed, 18 Dec 2013 13:26:35 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F493067B8@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217194920.GG2761@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F49306776@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131218131956.GA5938@mx1.yitter.info> In-Reply-To: <20131218131956.GA5938@mx1.yitter.info> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 18 Dec 2013 13:26:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB3ZWlyZHMgW21haWx0bzp3ZWly ZHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJldw0KPiBTdWxsaXZhbg0KPiBT ZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDE4LCAyMDEzIDg6MjAgQU0NCj4gVG86IHdlaXJkc0Bp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3dlaXJkc10gVXBkYXRlZCBTZWFyY2ggUHJvY2Vzc2lu ZyBUZXh0IFByb3Bvc2FsDQo+IA0KPiBUaGlzIGlzIG9rIHdpdGggbWUuICBJdCBzdHJpa2VzIG1l LCBob3dldmVyLCB0aGF0IFJGQyAyMTE5IGlzIGhhdmluZw0KPiBwcmV0dHkgcGVydmVyc2UgZWZm ZWN0cyBpZiB3ZSdyZSBub3cgcmV3cml0aW5nIHRleHQgdG8gZ2V0IGFyb3VuZCB1c2luZw0KPiB0 aG9zZSBwcmVjaXNlIGRlZmluaXRpb25zLCBpbiBvcmRlciBub3QgdG8gZ2V0IGludG8gcGlja3kg cHJvY2VkdXJhbA0KPiBhcmd1bWVudHMuIDooDQoNCkluZGVlZCEgTWF5YmUgd2UgY2FuIGp1c3Qg bG93ZXItY2FzZSB0aGVtLi4uIDspDQoNClNjb3R0DQo= From shollenbeck@verisign.com Wed Dec 18 10:41:53 2013 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 3FCBB1AE0A6 for ; Wed, 18 Dec 2013 10:41:53 -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 QqEhpcBMgicw for ; Wed, 18 Dec 2013 10:41:52 -0800 (PST) Received: from exprod6og124.obsmtp.com (exprod6og124.obsmtp.com [64.18.1.242]) by ietfa.amsl.com (Postfix) with ESMTP id B60591AE0A1 for ; Wed, 18 Dec 2013 10:41:51 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob124.postini.com ([64.18.5.12]) with SMTP ID DSNKUrHsbYnsy3eoM/tOXlMz6RILl6k0ztSg@postini.com; Wed, 18 Dec 2013 10:41:50 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 rBIIfmTo014281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Dec 2013 13:41:48 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Wed, 18 Dec 2013 13:41:48 -0500 From: "Hollenbeck, Scott" To: "weirds@ietf.org" Thread-Topic: rdap-query and .well-known Thread-Index: Ac78IMwKYF0XgdcyR6aAmUsYQAo0lA== Date: Wed, 18 Dec 2013 18:41:47 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49306BBE@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 Cc: "Mark Nottingham \(mnot@mnot.net\)" Subject: [weirds] rdap-query and .well-known 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, 18 Dec 2013 18:41:53 -0000 Since the discussion on search text seems to be winding down I wanted to re= visit what I think is the last bit of "are we sure?" text in rdap-query-08:= the well known URL text. I've cc'd Mark Nottingham in the hope of continui= ng to discussion that stopped with these messages from John and Simon: http://www.ietf.org/mail-archive/web/weirds/current/msg03387.html http://www.ietf.org/mail-archive/web/weirds/current/msg03390.html Mark, some additional guidance on the need for this approach would be helpf= ul. Scott From marc.blanchet@viagenie.ca Wed Dec 18 10:48:47 2013 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 215E81AE146 for ; Wed, 18 Dec 2013 10:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 eryA7eBxFDSS for ; Wed, 18 Dec 2013 10:48:45 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9821AE134 for ; Wed, 18 Dec 2013 10:48:45 -0800 (PST) Received: from h227.viagenie.ca (h227.viagenie.ca [206.123.31.227]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 55DC1403A8; Wed, 18 Dec 2013 13:48:41 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Marc Blanchet In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F49306BBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Date: Wed, 18 Dec 2013 13:48:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <51C15679-AEE3-4744-9CA9-8F07AD25D17D@viagenie.ca> References: <831693C2CDA2E849A7D7A712B24E257F49306BBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1827) Cc: "Mark Nottingham \(mnot@mnot.net\)" , "weirds@ietf.org" Subject: Re: [weirds] rdap-query and .well-known 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, 18 Dec 2013 18:48:47 -0000 since then, the bootstrap draft has received positive feedback and is at = the tail of the wg last call to be accepted. So unless issues are = raised, the current bootstrap approach means that the bootstrap will = provide a full url to the client. Therefore, we may not need the = well-known approach. Marc. Le 2013-12-18 =E0 13:41, Hollenbeck, Scott a = =E9crit : > Since the discussion on search text seems to be winding down I wanted = to revisit what I think is the last bit of "are we sure?" text in = rdap-query-08: the well known URL text. I've cc'd Mark Nottingham in the = hope of continuing to discussion that stopped with these messages from = John and Simon: >=20 > http://www.ietf.org/mail-archive/web/weirds/current/msg03387.html >=20 > http://www.ietf.org/mail-archive/web/weirds/current/msg03390.html >=20 > Mark, some additional guidance on the need for this approach would be = helpful. >=20 > Scott >=20 >=20 > _______________________________________________ > weirds mailing list > weirds@ietf.org > https://www.ietf.org/mailman/listinfo/weirds From superuser@gmail.com Wed Dec 18 12:27:48 2013 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 1133A1AE274 for ; Wed, 18 Dec 2013 12:27:48 -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 dE5o5_Gs-qJy for ; Wed, 18 Dec 2013 12:27:46 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 571C61AE26F for ; Wed, 18 Dec 2013 12:27:46 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bz8so5878087wib.16 for ; Wed, 18 Dec 2013 12:27:44 -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=fVDg91BMlu6OLTWJ+MbanoJYY6NwHaBaNb9shXeTF+4=; b=xppn5CUUlcOtyT2rDwROvTnhovCaLSEAUC7cvcUpWYz2Z6XkHAadWPHlq/ui1pmadv KMTs/TiYplLj/jFe3XclnjMCVx2rVP2bDaFSBeqcuGnkY6OZlaZgeVdpq8uBBlT1Dzys DiFaDSw5PrCsuFnNdMqbyaf/P/x6K9HlPXmJLRv12d7m56DjekbsCBkQPyNQrsn8CH21 dKdpoi3jlTRjx6OgqxDzEQiNGvxhxLPwKD86PwD1UMgzEyB6sWjfeOiKcQcWoeZMgR5I XWOppmQ5j3XoD4Q2y/Y+FxPqXUF2DdQ//D8fXdPi/QULTfd9HkU+hq1FxNQfaTYV6PFg wr+g== MIME-Version: 1.0 X-Received: by 10.194.157.10 with SMTP id wi10mr1671wjb.92.1387398464279; Wed, 18 Dec 2013 12:27:44 -0800 (PST) Received: by 10.180.84.106 with HTTP; Wed, 18 Dec 2013 12:27:44 -0800 (PST) In-Reply-To: <20131218131956.GA5938@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F49305F29@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131217194920.GG2761@mx1.yitter.info> <831693C2CDA2E849A7D7A712B24E257F49306776@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131218131956.GA5938@mx1.yitter.info> Date: Wed, 18 Dec 2013 12:27:44 -0800 Message-ID: From: "Murray S. Kucherawy" To: Andrew Sullivan Content-Type: multipart/alternative; boundary=089e0122ebe2a01aed04edd4e0a3 Cc: "weirds@ietf.org" Subject: Re: [weirds] Updated Search Processing Text Proposal 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, 18 Dec 2013 20:27:48 -0000 --089e0122ebe2a01aed04edd4e0a3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 18, 2013 at 5:19 AM, Andrew Sullivan wrote: > This is ok with me. It strikes me, however, that RFC 2119 is having > pretty perverse effects if we're now rewriting text to get around > using those precise definitions, in order not to get into picky > procedural arguments. :( > I agree, it's become unpleasant space. I think we might be due for a revision that provides better guidance (and this comes up from time to time), but that's not work for this WG. -MSK --089e0122ebe2a01aed04edd4e0a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 18, 2013 at 5:19 AM, Andrew Sullivan <aj= s@anvilwalrusden.com> wrote:
This is ok with me. =A0It strikes me, howeve= r, that RFC 2119 is having
pretty perverse effects if we're now rewriting text to get around
using those precise definitions, in order not to get into picky
procedural arguments. :(

I agree, it= 9;s become unpleasant space.=A0 I think we might be due for a revision that= provides better guidance (and this comes up from time to time), but that&#= 39;s not work for this WG.

-MSK
--089e0122ebe2a01aed04edd4e0a3-- From shollenbeck@verisign.com Thu Dec 19 04:42:19 2013 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 52FEE1A1F33 for ; Thu, 19 Dec 2013 04:42:19 -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 ieCA2hiZKqVZ for ; Thu, 19 Dec 2013 04:42:18 -0800 (PST) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by ietfa.amsl.com (Postfix) with ESMTP id BDA3E1A1F58 for ; Thu, 19 Dec 2013 04:42:16 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKUrLpplKFpv1c115bmaLqZXHZY7I+py2W@postini.com; Thu, 19 Dec 2013 04:42:16 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 rBJCgDPY031727 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 07:42:13 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 19 Dec 2013 07:42:13 -0500 From: "Hollenbeck, Scott" To: Marc Blanchet Thread-Topic: [weirds] rdap-query and .well-known Thread-Index: Ac78IMwKYF0XgdcyR6aAmUsYQAo0lAAKuE4AABrcMcA= Date: Thu, 19 Dec 2013 12:42:12 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F4930733D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F49306BBE@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <51C15679-AEE3-4744-9CA9-8F07AD25D17D@viagenie.ca> In-Reply-To: <51C15679-AEE3-4744-9CA9-8F07AD25D17D@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 Cc: "Mark Nottingham \(mnot@mnot.net\)" , "weirds@ietf.org" Subject: Re: [weirds] rdap-query and .well-known 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, 19 Dec 2013 12:42:19 -0000 > -----Original Message----- > From: Marc Blanchet [mailto:marc.blanchet@viagenie.ca] > Sent: Wednesday, December 18, 2013 1:49 PM > To: Hollenbeck, Scott > Cc: weirds@ietf.org; Mark Nottingham (mnot@mnot.net) > Subject: Re: [weirds] rdap-query and .well-known >=20 > since then, the bootstrap draft has received positive feedback and is > at the tail of the wg last call to be accepted. So unless issues are > raised, the current bootstrap approach means that the bootstrap will > provide a full url to the client. Therefore, we may not need the well- > known approach. I'd feel better about this if we could bootstrap *all* queries - but we can= 't. Unstructured entity names and search patterns pose a particular challen= ge. Scott From prvs=005861d705=johnl@iecc.com Thu Dec 19 05:40:37 2013 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 BF8051A1F62 for ; Thu, 19 Dec 2013 05:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 wupczdndYHmU for ; Thu, 19 Dec 2013 05:40:31 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 79BE71AD948 for ; Thu, 19 Dec 2013 05:40:31 -0800 (PST) Received: (qmail 35703 invoked from network); 19 Dec 2013 13:40:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Dec 2013 13:40: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:mime-version:content-type:content-transfer-encoding; s=52b2f74c.xn--3zv.k1310; i=johnl@user.iecc.com; bh=kCzVy2PIKQzFzHYJRLonLItXRlosiGCCcA/Hwl+nYBM=; b=RGrO8OL2JrSxfLR7IhMWVuE6fcaqJybwZIGUoMcLJ/PTWoO1qnNAlg2UCNU+FHLKKKwvQ0YNHp1Jxp3e0o8JTyTFPji5nRSI6YOIGubnfqA58YWScB+CMl5RgooIab6f/3aiLK+l7EqbNlxnrHcVYYJzAYXv4NX91q1z+sFSVzo+Zxwq8XsPIr9fd5/9yCE3zySCMMF1r3MUfiS9g6di79Rp3ZZkiOxJ71SFBQk9A05+DnowRJ8O/Zr2yN0k6N5W 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=52b2f74c.xn--3zv.k1310; olt=johnl@user.iecc.com; bh=kCzVy2PIKQzFzHYJRLonLItXRlosiGCCcA/Hwl+nYBM=; b=WvcIyA6YseoKr6yYunUB1ORyM5ESTPzfmhDIajVW+aPsQJzhzsgCgPnLEPlicQKqTW1ANSR6EBTW8K3t+ZQGpOi47QI7NZ7Qeq90FVWdKLp5AE5sxET2h+b57YGz86i2b3l7RlZTwFU2Xv2C4i/euK0b4B5u7+keO1XPu+GpXeidMJD1G5BmHM9mKw6Hsq6yjr54vUeyaS8NtdxvqOe7c2uT0C0KkszjuyzOvra3XXMi09bA4OKv56HxsSKPJdOg Date: 19 Dec 2013 13:40:05 -0000 Message-ID: <20131219134005.35451.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <831693C2CDA2E849A7D7A712B24E257F4930733D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] rdap-query and .well-known 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, 19 Dec 2013 13:40:38 -0000 >I'd feel better about this if we could bootstrap *all* queries - but we can't. >Unstructured entity names and search patterns pose a particular challenge. For unstructured entity names, you can only look them up, with or without a bootstrap, if you know what provider defined it. For names you got from a previous lookup, I think we should add a field to the JSON that tells you where to look up the entities. For names you got somewhere else, you basically have to look up the name or IP or ASN it's describing, and then ask whatever server answered that question. Search patterns are almost easy. If you're searching for blah*.tld, you use the bootstrap for the TLD. If you're searching for blah*.ac.uk, you uh, well, hmmn. R's, John From shollenbeck@verisign.com Thu Dec 19 05:44:52 2013 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 C705B1ADBCE for ; Thu, 19 Dec 2013 05:44:52 -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 j_XJSclbUqWZ for ; Thu, 19 Dec 2013 05:44:51 -0800 (PST) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC5091AD948 for ; Thu, 19 Dec 2013 05:44:47 -0800 (PST) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP ID DSNKUrL4TrvyMr6L1/kl/v79UNvqbDcY5561@postini.com; Thu, 19 Dec 2013 05:44:49 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 rBJDijk7001092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Dec 2013 08:44:45 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 19 Dec 2013 08:44:45 -0500 From: "Hollenbeck, Scott" To: John Levine , "weirds@ietf.org" Thread-Topic: [weirds] rdap-query and .well-known Thread-Index: Ac78IMwKYF0XgdcyR6aAmUsYQAo0lAAKuE4AABrcMcAADKd2gAAKciZA Date: Thu, 19 Dec 2013 13:44:44 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F49307457@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <831693C2CDA2E849A7D7A712B24E257F4930733D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131219134005.35451.qmail@joyce.lan> In-Reply-To: <20131219134005.35451.qmail@joyce.lan> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [weirds] rdap-query and .well-known 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, 19 Dec 2013 13:44:53 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2huIExldmluZSBbbWFpbHRv OmpvaG5sQHRhdWdoLmNvbV0NCj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE5LCAyMDEzIDg6 NDAgQU0NCj4gVG86IHdlaXJkc0BpZXRmLm9yZw0KPiBDYzogSG9sbGVuYmVjaywgU2NvdHQNCj4g U3ViamVjdDogUmU6IFt3ZWlyZHNdIHJkYXAtcXVlcnkgYW5kIC53ZWxsLWtub3duDQo+IA0KPiA+ SSdkIGZlZWwgYmV0dGVyIGFib3V0IHRoaXMgaWYgd2UgY291bGQgYm9vdHN0cmFwICphbGwqIHF1 ZXJpZXMgLSBidXQNCj4gd2UgY2FuJ3QuDQo+ID5VbnN0cnVjdHVyZWQgZW50aXR5IG5hbWVzIGFu ZCBzZWFyY2ggcGF0dGVybnMgcG9zZSBhIHBhcnRpY3VsYXINCj4gY2hhbGxlbmdlLg0KPiANCj4g Rm9yIHVuc3RydWN0dXJlZCBlbnRpdHkgbmFtZXMsIHlvdSBjYW4gb25seSBsb29rIHRoZW0gdXAs IHdpdGggb3INCj4gd2l0aG91dCBhIGJvb3RzdHJhcCwgaWYgeW91IGtub3cgd2hhdCBwcm92aWRl ciBkZWZpbmVkIGl0LiAgRm9yIG5hbWVzDQo+IHlvdSBnb3QgZnJvbSBhIHByZXZpb3VzIGxvb2t1 cCwgSSB0aGluayB3ZSBzaG91bGQgYWRkIGEgZmllbGQgdG8gdGhlDQo+IEpTT04gdGhhdCB0ZWxs cyB5b3Ugd2hlcmUgdG8gbG9vayB1cCB0aGUgZW50aXRpZXMuICBGb3IgbmFtZXMgeW91IGdvdA0K PiBzb21ld2hlcmUgZWxzZSwgeW91IGJhc2ljYWxseSBoYXZlIHRvIGxvb2sgdXAgdGhlIG5hbWUg b3IgSVAgb3IgQVNODQo+IGl0J3MgZGVzY3JpYmluZywgYW5kIHRoZW4gYXNrIHdoYXRldmVyIHNl cnZlciBhbnN3ZXJlZCB0aGF0IHF1ZXN0aW9uLg0KPiANCj4gU2VhcmNoIHBhdHRlcm5zIGFyZSBh bG1vc3QgZWFzeS4gIElmIHlvdSdyZSBzZWFyY2hpbmcgZm9yIGJsYWgqLnRsZCwNCj4geW91IHVz ZSB0aGUgYm9vdHN0cmFwIGZvciB0aGUgVExELiAgSWYgeW91J3JlIHNlYXJjaGluZyBmb3INCj4g YmxhaCouYWMudWssIHlvdSB1aCwgd2VsbCwgaG1tbi4NCg0KSSB3YXMgdGhpbmtpbmcgYWJvdXQg ZG9tYWluIHNlYXJjaCBwYXR0ZXJucyBsaWtlIGV4YW1wbGUqLiBQb2ludCBpcyB0aGF0IGJvb3Rz dHJhcHBpbmcgaGFzIHNvbWUgbGltaXRhdGlvbnMuDQoNClNjb3R0DQo= From ajs@anvilwalrusden.com Thu Dec 19 06:09:06 2013 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 198291ADF2E for ; Thu, 19 Dec 2013 06:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 QxTv3t4rMtVP for ; Thu, 19 Dec 2013 06:09:05 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id E16211ADE8B for ; Thu, 19 Dec 2013 06:09:04 -0800 (PST) Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 586A88A031 for ; Thu, 19 Dec 2013 14:09:02 +0000 (UTC) Date: Thu, 19 Dec 2013 09:09:01 -0500 From: Andrew Sullivan To: weirds@ietf.org Message-ID: <20131219140901.GC7244@mx1.yitter.info> References: <831693C2CDA2E849A7D7A712B24E257F4930733D@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <20131219134005.35451.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131219134005.35451.qmail@joyce.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [weirds] rdap-query and .well-known 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, 19 Dec 2013 14:09:06 -0000 On Thu, Dec 19, 2013 at 01:40:05PM -0000, John Levine wrote: > you use the bootstrap for the TLD. If you're searching for > blah*.ac.uk, you uh, well, hmmn. If only we had a global, widely-available service that allowed one to publish information about services at a name. A -- Andrew Sullivan ajs@anvilwalrusden.com From prvs=005861d705=johnl@iecc.com Thu Dec 19 07:33:58 2013 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 089531ADFCC for ; Thu, 19 Dec 2013 07:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.33 X-Spam-Level: X-Spam-Status: No, score=-2.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 dGa8_YVzGqzi for ; Thu, 19 Dec 2013 07:33:52 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 28E171ADFC4 for ; Thu, 19 Dec 2013 07:33:51 -0800 (PST) Received: (qmail 56943 invoked from network); 19 Dec 2013 15:33:49 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Dec 2013 15:33:49 -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=52b311dd.xn--30v786c.k1310; i=johnl@user.iecc.com; bh=+TjENdy/UphQFi7m3E59zkt6EnMj7dDHXj7vOY3xvbI=; b=ZKw5RGmS7TeyFWT2ODByILQpPju1U6n02ZaZtRLvLYfi4W6q2p2ThogdxaGP2RhjespMQUC4F7cvdBAdwB5VpM24PNFwE+pHvZ2e0eofqJ3KeZRw0fv3yYvGLPbvdZAeHIKQIk5wZKU4mJ5+jvWGS0Ul6YPQTkkoi31WoKfgDquPtH3uTJ4zStuF1vkHsbuQYfuczwyOvSRt5/0wXj2XZ3CrgV52GQ9+pFH5rC4xP45NT+/BslXXQLNTrqUTDWIH 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=52b311dd.xn--30v786c.k1310; olt=johnl@user.iecc.com; bh=+TjENdy/UphQFi7m3E59zkt6EnMj7dDHXj7vOY3xvbI=; b=uuPN6z3mYkDsE9BgF0OA2aCYPSSvXz+mN2IjH0zXZQAbmzPSmzFZ9tgRsEQSCisEuovLdc2qMWEsWV9H6wMDe6Ji3e5y1ezVtef2HEPlhrJq7n8OTxe/gQo1va1gmFgZriDKbqghWTOqOT9CvNu6GPgp4zi0ow9t1FbhlRp0Ife+4gcSReqCUZdZ4tIZG/CYW6rn1EUtk939k+aVraK7DldIces43NDUou4jWonl5OyhaKxikTRhfONRcxw8Ixs2 Date: 19 Dec 2013 15:33:24 -0000 Message-ID: <20131219153324.2661.qmail@joyce.lan> From: "John Levine" To: weirds@ietf.org In-Reply-To: <20131219140901.GC7244@mx1.yitter.info> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [weirds] rdap-query and .well-known 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, 19 Dec 2013 15:33:58 -0000 >> you use the bootstrap for the TLD. If you're searching for >> blah*.ac.uk, you uh, well, hmmn. > >If only we had a global, widely-available service that allowed one to >publish information about services at a name. Except that this is the converse, we want to know what names have a service, a question that the DNS specifically doesn't address. R's, John From internet-drafts@ietf.org Thu Dec 19 12:04:12 2013 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 4F6141AE1F6; Thu, 19 Dec 2013 12:04:12 -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 FYnoaE0rKiQo; Thu, 19 Dec 2013 12:04:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CED8F1AE6D9; Thu, 19 Dec 2013 12:04:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.84 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131219200409.31469.17631.idtracker@ietfa.amsl.com> Date: Thu, 19 Dec 2013 12:04:09 -0800 Cc: weirds@ietf.org Subject: [weirds] I-D Action: draft-ietf-weirds-rdap-query-09.txt 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: Thu, 19 Dec 2013 20:04:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Web Extensible Internet Registration Data= Service Working Group of the IETF. Title : Registration Data Access Protocol Query Format Author(s) : Andrew Lee Newton Scott Hollenbeck Filename : draft-ietf-weirds-rdap-query-09.txt Pages : 17 Date : 2013-12-19 Abstract: This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-query There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-weirds-rdap-query-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-weirds-rdap-query-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/