From ajs@anvilwalrusden.com Tue Feb 14 13:25:18 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BE621E8122 for ; Tue, 14 Feb 2012 13:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1njKooCA5+X for ; Tue, 14 Feb 2012 13:25:14 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 4C41921E811E for ; Tue, 14 Feb 2012 13:25:13 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 32B5D1ECB41C for ; Tue, 14 Feb 2012 21:25:09 +0000 (UTC) Date: Tue, 14 Feb 2012 16:25:05 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120214212504.GD22144@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 21:25:18 -0000 Hi, draft-obispo-epp-idn-00 includes a mechanism for indicating some sort of code point selector (there called a language tag). I mentioned before my reservation about this term "language tag", and suggested that future developments would likely make something more generic somewhat more useful (even if we continue to use RFC 5646 to generate the tags that serve as identifiers, as I think we should). I noted today, however, another thing that bugs me. RFC 5731 makes the data conform to RFC 952 as updated by RFC 1123. At the risk of oversimplifying, this is the LDH rule. RFC 5891 section 4.1 suggests that it would be desirable to require both the A-label and U-label as input, so that the registry side could valdate whether the A-label actually corresponds to the desired U-label. I know that some don't think this is a good policy to have, but that's not relevant for this discussion; the question is, if someone were going to implement such a policy, how could they? I'm wondering whether we couldn't make an optional element in this proposed extension that would contain the name in U-label form. In other words, in the U-label format, A-labels wouldn't be allowed. A repository, on receiving this, could validate that the A-label and U-label matched. If they did not, it would be an error. Thoughts? A -- Andrew Sullivan ajs@anvilwalrusden.com From james.mitchell@ausregistry.com.au Tue Feb 14 15:43:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3981F1F0C4C for ; Tue, 14 Feb 2012 15:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upYCCqfxf05O for ; Tue, 14 Feb 2012 15:43:48 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 274371F0C43 for ; Tue, 14 Feb 2012 15:43:42 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 15 Feb 2012 10:43:26 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 15 Feb 2012 10:43:12 +1100 From: James Mitchell To: Andrew Sullivan , "provreg@ietf.org" Date: Wed, 15 Feb 2012 10:43:13 +1100 Thread-Topic: [provreg] U-labels and draft-obispo-epp-idn-00 Thread-Index: AczrXy5FJfhKKDQHSyWkn5zwZ0+npQAEh49Q Message-ID: <8CEF048B9EC83748B1517DC64EA130FB6B2AB34671@off-win2003-01.ausregistrygroup.local> References: <20120214212504.GD22144@mail.yitter.info> In-Reply-To: <20120214212504.GD22144@mail.yitter.info> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:43:49 -0000 I agree with Andrew for including an optional "U-label" element. Server pol= icy can dictate how it is used. > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Wednesday, 15 February 2012 8:25 AM > To: provreg@ietf.org > Subject: [provreg] U-labels and draft-obispo-epp-idn-00 >=20 > Hi, >=20 > draft-obispo-epp-idn-00 includes a mechanism for indicating some sort > of code point selector (there called a language tag). I mentioned > before my reservation about this term "language tag", and suggested > that future developments would likely make something more generic > somewhat more useful (even if we continue to use RFC 5646 to generate > the tags that serve as identifiers, as I think we should). >=20 > I noted today, however, another thing that bugs me. RFC 5731 makes > the data conform to RFC 952 as updated by RFC 1123. > At the risk of oversimplifying, this is the LDH rule. >=20 > RFC 5891 section 4.1 suggests that it would be desirable to require > both the A-label and U-label as input, so that the registry side could > valdate whether the A-label actually corresponds to the desired > U-label. I know that some don't think this is a good policy to have, > but that's not relevant for this discussion; the question is, if > someone were going to implement such a policy, how could they? >=20 > I'm wondering whether we couldn't make an optional element in this > proposed extension that would contain the name in U-label form. In > other words, in the U-label format, A-labels wouldn't be allowed. >=20 > A repository, on receiving this, could validate that the A-label and > U-label matched. If they did not, it would be an error. >=20 > Thoughts? >=20 > A >=20 >=20 > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From lem@isc.org Tue Feb 14 15:58:40 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3D421E8117 for ; Tue, 14 Feb 2012 15:58:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86zwYTElqGe2 for ; Tue, 14 Feb 2012 15:58:40 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id D347121E810F for ; Tue, 14 Feb 2012 15:58:39 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id EB53DC941E; Tue, 14 Feb 2012 23:58:29 +0000 (UTC) (envelope-from lem@isc.org) Received: from [192.168.0.129] (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 5C508216C6A; Tue, 14 Feb 2012 23:58:29 +0000 (UTC) (envelope-from lem@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: <20120214212504.GD22144@mail.yitter.info> Date: Tue, 14 Feb 2012 18:58:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> References: <20120214212504.GD22144@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 23:58:40 -0000 On Feb 14, 2012, at 4:25 PM, Andrew Sullivan wrote: > RFC 5891 section 4.1 suggests that it would be desirable to require > both the A-label and U-label as input, so that the registry side could > valdate whether the A-label actually corresponds to the desired > U-label. I know that some don't think this is a good policy to have, > but that's not relevant for this discussion; the question is, if > someone were going to implement such a policy, how could they?=20 I agree that this might come in handy in many cases, and probably does = not hurt. Best regards. -lem From paf@frobbit.se Tue Feb 14 19:08:04 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594F821E8011 for ; Tue, 14 Feb 2012 19:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZ5uuH3ODQ5q for ; Tue, 14 Feb 2012 19:08:04 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 91FEC21E8010 for ; Tue, 14 Feb 2012 19:08:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 2A4631317553F; Wed, 15 Feb 2012 04:08:01 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0KFPMpdQJIUS; Wed, 15 Feb 2012 04:07:58 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 4A60C13175536; Wed, 15 Feb 2012 04:07:58 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120214212504.GD22144@mail.yitter.info> Date: Wed, 15 Feb 2012 04:07:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:08:04 -0000 On 14 feb 2012, at 22:25, Andrew Sullivan wrote: > A repository, on receiving this, could validate that the A-label and > U-label matched. If they did not, it would be an error. FWIW, I am against passing U-label to the registry. Specifically having = it "optional" as some registries will make it mandatory, and some will = not. This will once again create a requirement in difference in = implementation on the epp client side how to pass such a simple thing as = a domain name from the epp client to the epp server. Further, if we go down this path of sending a U-label, then we might in = the next step have epp servers that give the ability for the client to = send unicode strings that are non-normalized and because of that not 1:1 = mappings to the A-label as this piece of the data, and then validation = whether the A-label matches or not -- according to the algorithm chosen = by the registry. Etc. The slope is *extremely* slippery. The only think I can agree to is that: - The a-label is what is mandatory and normative in the exchange between = epp client and server - An epp server might optionally accept a u-label, but that is never = mandatory - Wrong u-label (or never sending it) can never block the use of the = a-label given it is accepted That way, epp clients can if they want to pass an optional u-label to = the registry and get some signalling back. But it is not part of the = mandatory communication when dealing with strings. I.e. I ask myself, if you as an epp client do have a U-label, what is = the chance the A-label is calculated wrongly? Adding that as a "feature" = is just silly. Patrik From paf@frobbit.se Tue Feb 14 19:09:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E555B21E802B for ; Tue, 14 Feb 2012 19:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq-fmORDIwqH for ; Tue, 14 Feb 2012 19:09:02 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 5419721E8010 for ; Tue, 14 Feb 2012 19:09:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id AB2D5131755A2; Wed, 15 Feb 2012 04:09:01 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xm6S2-fAT5D2; Wed, 15 Feb 2012 04:09:01 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 5CC351317559B; Wed, 15 Feb 2012 04:09:01 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <8CEF048B9EC83748B1517DC64EA130FB6B2AB34671@off-win2003-01.ausregistrygroup.local> Date: Wed, 15 Feb 2012 04:09:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <98B6DF42-E7D1-4FF9-8C03-AD6C3830249D@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <8CEF048B9EC83748B1517DC64EA130FB6B2AB34671@off-win2003-01.ausregistrygroup.local> To: James Mitchell X-Mailer: Apple Mail (2.1257) Cc: "provreg@ietf.org" Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:09:03 -0000 On 15 feb 2012, at 00:43, James Mitchell wrote: > I agree with Andrew for including an optional "U-label" element. = Server policy can dictate how it is used. No, this spec should dictate how it is used. It should not be one more = feature that can differ between epp implementations. We should *not* diverge in epp on how we express domain names inside the = protocol. The 'e' is not that much of an 'e'. Patrik From paf@frobbit.se Tue Feb 14 19:09:25 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2021E8010 for ; Tue, 14 Feb 2012 19:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfHbNAQgT1VO for ; Tue, 14 Feb 2012 19:09:25 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E046121F85A1 for ; Tue, 14 Feb 2012 19:09:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 3F671131755C9; Wed, 15 Feb 2012 04:09:24 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiAU6CTcQKuq; Wed, 15 Feb 2012 04:09:23 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id C62AF131755C2; Wed, 15 Feb 2012 04:09:23 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> Date: Wed, 15 Feb 2012 04:09:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> To: =?iso-8859-1?Q?Luis_Mu=F1oz?= X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:09:25 -0000 On 15 feb 2012, at 00:58, Luis Mu=F1oz wrote: > I agree that this might come in handy in many cases Mention one. paf From jay@nzrs.net.nz Tue Feb 14 19:20:01 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8556A21E8010 for ; Tue, 14 Feb 2012 19:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-J2mhtxIa6V for ; Tue, 14 Feb 2012 19:20:01 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id C989821E8034 for ; Tue, 14 Feb 2012 19:20:00 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 79B962DA72E; Wed, 15 Feb 2012 16:19:58 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0Ofd7kXPBr6; Wed, 15 Feb 2012 16:19:58 +1300 (NZDT) Received: from [192.168.22.132] (unknown [202.46.183.35]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id 4331D2DA72D; Wed, 15 Feb 2012 16:19:58 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jay Daley In-Reply-To: <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> Date: Wed, 15 Feb 2012 16:19:57 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:20:01 -0000 On 15/02/2012, at 4:09 PM, Patrik F=E4ltstr=F6m wrote: >> I agree that this might come in handy in many cases >=20 > Mention one. In .nz we expect both the U and A labels and that the A label is = correctly derived from the U. The reasoning for this is that = registrants are not in their minds registering the A label, they are = registering the U label and we want to guard against a processing error = that would not provide what the registrant wants. With only an A label = we can't trap this. Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From fobispo@isc.org Tue Feb 14 19:23:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA22721F866E for ; Tue, 14 Feb 2012 19:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gftghQEnwvF for ; Tue, 14 Feb 2012 19:23:01 -0800 (PST) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id CD18A21F866B for ; Tue, 14 Feb 2012 19:23:01 -0800 (PST) Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id 7BF4DC941E; Wed, 15 Feb 2012 03:22:49 +0000 (UTC) (envelope-from fobispo@isc.org) Received: from fobispo-mbp.lan (c-67-188-135-250.hsd1.ca.comcast.net [67.188.135.250]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 4E7BB216C6A; Wed, 15 Feb 2012 03:22:49 +0000 (UTC) (envelope-from fobispo@isc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Francisco Obispo In-Reply-To: Date: Tue, 14 Feb 2012 19:22:48 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1336FC1D-3400-4520-B487-BAE3672C23D6@isc.org> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> To: Jay Daley X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:23:02 -0000 .VE also uses a U-Label, and uses the encoding in the XML document to = check the code points against a white list. On Feb 14, 2012, at 7:19 PM, Jay Daley wrote: >=20 > On 15/02/2012, at 4:09 PM, Patrik F=E4ltstr=F6m wrote: >=20 >>> I agree that this might come in handy in many cases >>=20 >> Mention one. >=20 > In .nz we expect both the U and A labels and that the A label is = correctly derived from the U. The reasoning for this is that = registrants are not in their minds registering the A label, they are = registering the U label and we want to guard against a processing error = that would not provide what the registrant wants. With only an A label = we can't trap this. >=20 > Jay >=20 >=20 > --=20 > Jay Daley > Chief Executive > .nz Registry Services (New Zealand Domain Name Registry Limited) > desk: +64 4 931 6977 > mobile: +64 21 678840 >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From paf@frobbit.se Tue Feb 14 19:40:34 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476C721E80A3 for ; Tue, 14 Feb 2012 19:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpbztoNbwhof for ; Tue, 14 Feb 2012 19:40:33 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 4819E21E809E for ; Tue, 14 Feb 2012 19:40:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 8FA1313175A3C; Wed, 15 Feb 2012 04:40:30 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1oy4SZadoiR; Wed, 15 Feb 2012 04:40:30 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 6A59513175A35; Wed, 15 Feb 2012 04:40:30 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: Date: Wed, 15 Feb 2012 04:40:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> To: Jay Daley X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:40:34 -0000 On 15 feb 2012, at 04:19, Jay Daley wrote: > On 15/02/2012, at 4:09 PM, Patrik F=E4ltstr=F6m wrote: >=20 >>> I agree that this might come in handy in many cases >>=20 >> Mention one. >=20 > In .nz we expect both the U and A labels and that the A label is = correctly derived from the U. The reasoning for this is that = registrants are not in their minds registering the A label, they are = registering the U label and we want to guard against a processing error = that would not provide what the registrant wants. With only an A label = we can't trap this. And you have factual errors where a U-label and an A-label does not = match? You do not talk about cases where they believe they can register = some unicode string that is not a U-label? Note, the discussion is about U-labels and A-labels, not unicode strings = and A-labels. Patrik From ajs@anvilwalrusden.com Tue Feb 14 19:58:54 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B12421E8055 for ; Tue, 14 Feb 2012 19:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUAle4ugB4rA for ; Tue, 14 Feb 2012 19:58:53 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE8C21E8010 for ; Tue, 14 Feb 2012 19:58:53 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 648331ECB41C for ; Wed, 15 Feb 2012 03:58:52 +0000 (UTC) Date: Tue, 14 Feb 2012 22:58:46 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120215035845.GA1537@mail.yitter.info> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 03:58:54 -0000 On Wed, Feb 15, 2012 at 04:07:57AM +0100, Patrik Fältström wrote: > > FWIW, I am against passing U-label to the registry. Specifically > having it "optional" as some registries will make it mandatory, and > some will not. This will once again create a requirement in > difference in implementation on the epp client side how to pass such > a simple thing as a domain name from the epp client to the epp > server. Of all the people I'd ever imagined would suggest that IDNs were simple, you were last but one -- the other guy was Klensin -- in line! But let me respond in detail below. > Further, if we go down this path of sending a U-label, then we might > in the next step have epp servers that give the ability for the > client to send unicode strings that are non-normalized and because > of that not 1:1 mappings to the A-label as this piece of the data, > and then validation whether the A-label matches or not -- according > to the algorithm chosen by the registry. If those registries plan to use the EPP standard domain name mapping, they couldn't possibly do it this way: the element is not optional, and it only allows LDH. > - The a-label is what is mandatory and normative in the exchange between epp client and server Already true in the RFCs we have. > - An epp server might optionally accept a u-label, but that is never mandatory This is just registry policy, and there is no way you (or anyone else) is going to be able to legislate it. To begin with, there are many ccTLDs that are not subject to ICANN contract. > - Wrong u-label (or never sending it) can never block the use of the a-label given it is accepted > The entire _point_ of the extension would be to block such an A-label. The idea is exactly to make sure that the EPP client is sending you data that is correct. The idea here is exactly to make sure that the client and server in the EPP transaction agree on exactly what's being exchanged. Some registries check to make sure name servers are properly delegated. That mode of operation appears to be supported by some text in RFCs 1034 and 1035, but many gTLDs don't do it. By the same token, RFC 5891 says that collecting both the U-label and the A-label, or only the A-label, are preferable; and of these, the former is preferred over the latter. If you think that verify the name server data that a client hands you is acceptable, then why isn't it acceptable to verify the transformation -- probably performed by an intermediate party ("the registrar") rather than the person who wants the name ("the registrant") -- in the case of A-labels and U-labels? > I.e. I ask myself, if you as an epp client do have a U-label, what is the chance the A-label is calculated wrongly? Adding that as a "feature" is just silly. In the case where the U-label contained "ß", the chances are at the very least non-zero, at least today and for the near future: last I checked (about 30 seconds ago) libidn2 isn't in the Debian stable distribution, just for instance. Similarly with ZWNJ and ZWJ. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jay@nzrs.net.nz Tue Feb 14 20:56:44 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21E11E8074 for ; Tue, 14 Feb 2012 20:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DPK+kVxWl+u for ; Tue, 14 Feb 2012 20:56:44 -0800 (PST) Received: from srsomail.nzrs.net.nz (srsomail.nzrs.net.nz [202.46.183.22]) by ietfa.amsl.com (Postfix) with ESMTP id 194E711E8073 for ; Tue, 14 Feb 2012 20:56:43 -0800 (PST) Received: from localhost (srsomail.office.nzrs.net.nz [202.46.183.22]) by srsomail.nzrs.net.nz (Postfix) with ESMTP id 0F7302DA784; Wed, 15 Feb 2012 17:56:42 +1300 (NZDT) Received: from srsomail.nzrs.net.nz ([202.46.183.22]) by localhost (srsomail.office.nzrs.net.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wn0Ag5HkxFx0; Wed, 15 Feb 2012 17:56:41 +1300 (NZDT) Received: from [192.168.1.5] (121-73-174-22.dsl.telstraclear.net [121.73.174.22]) (Authenticated sender: jay) by srsomail.nzrs.net.nz (Postfix) with ESMTPSA id A509D2DA77E; Wed, 15 Feb 2012 17:56:41 +1300 (NZDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Jay Daley In-Reply-To: <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> Date: Wed, 15 Feb 2012 17:56:40 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <8E5905D6-2BDF-48F3-983F-3FA65C73E909@nzrs.net.nz> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 04:56:44 -0000 On 15/02/2012, at 4:40 PM, Patrik F=E4ltstr=F6m wrote: > And you have factual errors where a U-label and an A-label does not = match? In testing yes, not in production, but then we have less than 200 IDN = registrations. > You do not talk about cases where they believe they can register some = unicode string that is not a U-label? You only asked for one example, not a canonical ruleset for how we = process the U-label data! Obviously the U-label must be valid and if it = is not then we don't process it in the same way we don't process invalid = A-labels. > Note, the discussion is about U-labels and A-labels, not unicode = strings and A-labels. And my point was that for non-IDNs the registrant believes they are = registering an A-label which is the same A-label that the registry = registers. But with IDN there is no longer this direct relationship as = the registrant believes they are registering the U-label while the = registry actually registers the A-label. =20 Jay --=20 Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 From paf@frobbit.se Tue Feb 14 20:59:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B298711E8088 for ; Tue, 14 Feb 2012 20:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YiyPPgwr7bAd for ; Tue, 14 Feb 2012 20:59:02 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id A83B211E8073 for ; Tue, 14 Feb 2012 20:58:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 5F17F131765C0; Wed, 15 Feb 2012 05:58:51 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NmKaAjv5RK+k; Wed, 15 Feb 2012 05:58:51 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id F2613131765B8; Wed, 15 Feb 2012 05:58:50 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120215035845.GA1537@mail.yitter.info> Date: Wed, 15 Feb 2012 05:58:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 04:59:02 -0000 On 15 feb 2012, at 04:58, Andrew Sullivan wrote: > Of all the people I'd ever imagined would suggest that IDNs were > simple, you were last but one -- the other guy was Klensin -- in > line! But let me respond in detail below. =20 :-D The whole reason for my answer is because IDN _is_ complicated. >> Further, if we go down this path of sending a U-label, then we might >> in the next step have epp servers that give the ability for the >> client to send unicode strings that are non-normalized and because >> of that not 1:1 mappings to the A-label as this piece of the data, >> and then validation whether the A-label matches or not -- according >> to the algorithm chosen by the registry. >=20 > If those registries plan to use the EPP standard domain name mapping, > they couldn't possibly do it this way: the element is = not > optional, and it only allows LDH. Good, then we agree here. >> - The a-label is what is mandatory and normative in the exchange = between epp client and server >=20 > Already true in the RFCs we have. Exactly! >> - An epp server might optionally accept a u-label, but that is never = mandatory >=20 > This is just registry policy, and there is no way you (or anyone else) > is going to be able to legislate it. To begin with, there are many > ccTLDs that are not subject to ICANN contract.=20 No, it has to do whether a registry that claims to use epp is doing. We already have far too many "private extensions" to epp where = registries claims they implement epp when in fact they have private = extensions, or interpretations of extensions that forces registrars to = make all different kind of hacks to be able to interoperate. I do not want that to be possible. I want to limit the number of = extensions to epp to an absolute minimum and I want registries that = implement them to do it the same way. If a registry choose to NOT use epp, fine. I will not force them. But as = a registrar it is very good to know. Specifically for the registries = that do claim today they use epp, but you can not see the specification = of their protocol unless you sign an NDA, pay a check, and THEN you see = the epp version they have is so broken it is...well, I do not really = have words for some of the things I have seen here. Once again, I am not against them doing whatever they want. I am against = calling that epp. We *MUST* be better on saying what is epp and what is not epp. And, sure, an extension that a registry have that is not mandatory for = the registrar, that is fine, as the registrar does not have to implement = that feature. >> - Wrong u-label (or never sending it) can never block the use of the = a-label given it is accepted >=20 > The entire _point_ of the extension would be to block such an > A-label. The idea is exactly to make sure that the EPP client is > sending you data that is correct. The idea here is exactly to make > sure that the client and server in the EPP transaction agree on > exactly what's being exchanged. In this case, what the client should send is _not_ a U-label. You know = better than anyone else what an A-label and U-label is, and you give = examples below on unicode strings that are passed around that are not = U-labels. Remember that there is by definition a 1:1 mapping between = A-labels and U-labels. What I hear you say now is that the client should be able to pass an = A-label for registration, and also a unicode string that the client do = claim is what the registrant wanted to register. And the question is then what to do if it is the case that: 1. That unicode string is passed to the registry 2. The registry do not believe that unicode string can be represented by = the A-label that is also sent > Some registries check to make sure name servers are properly > delegated. Checking that a domain name is delegated before it can be registered I = think is a big mistake, as they do not accept domain names to be = registered without being delegated. That increases the interest in their = zone file as the zone file in this case do disclose what domain names = are registered and not. My point is that yes, validation of various kinds is good of course (I = have been pushing for more validations myself), but tying it to = _registration_policy_ is a pain. > That mode of operation appears to be supported by some > text in RFCs 1034 and 1035, but many gTLDs don't do it. By the same > token, RFC 5891 says that collecting both the U-label and the A-label, > or only the A-label, are preferable; and of these, the former is > preferred over the latter. If you think that verify the name > server data that a client hands you is acceptable, then why isn't it > acceptable to verify the transformation -- probably performed by an > intermediate party ("the registrar") rather than the person who wants > the name ("the registrant") -- in the case of A-labels and U-labels? There is a big difference between validating A-label and U-label = conformance and A-label and unicode string matchings. >> I.e. I ask myself, if you as an epp client do have a U-label, what is = the chance the A-label is calculated wrongly? Adding that as a "feature" = is just silly. >=20 > In the case where the U-label contained "=DF", the chances are at the > very least non-zero, at least today and for the near future: last I > checked (about 30 seconds ago) libidn2 isn't in the Debian stable > distribution, just for instance. Similarly with ZWNJ and ZWJ. So, the reason why we want to do this is to ensure there is no bug in = the libraries used by various parties? What is the library is wrong in the registry, but not registrar? Once again, having the registry exposing an optional function where a = _unicode_string_ can be passed together with an A-label to have that = validated together with whatever policies the registry has, fine, but = not be able to (according to epp) register a domain name with only an = A-label is what I am against. Patrik From paf@frobbit.se Tue Feb 14 21:01:03 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A6711E8088 for ; Tue, 14 Feb 2012 21:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErvoLEKB5j8Z for ; Tue, 14 Feb 2012 21:01:03 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 401EB11E8073 for ; Tue, 14 Feb 2012 21:01:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id A1C5F1317664F; Wed, 15 Feb 2012 06:01:02 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKje7NfWF-zQ; Wed, 15 Feb 2012 06:01:02 +0100 (CET) Received: from [IPv6:2a02:80:3ffc::14] (unknown [IPv6:2a02:80:3ffc::14]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 582D613176648; Wed, 15 Feb 2012 06:01:02 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <8E5905D6-2BDF-48F3-983F-3FA65C73E909@nzrs.net.nz> Date: Wed, 15 Feb 2012 06:01:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8DD2D02A-3ECB-4FCC-B611-983759546204@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> <8E5905D6-2BDF-48F3-983F-3FA65C73E909@nzrs.net.nz> To: Jay Daley X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:01:04 -0000 On 15 feb 2012, at 05:56, Jay Daley wrote: >> You do not talk about cases where they believe they can register some = unicode string that is not a U-label? >=20 > You only asked for one example, not a canonical ruleset for how we = process the U-label data! Obviously the U-label must be valid and if it = is not then we don't process it in the same way we don't process invalid = A-labels. Fair. >> Note, the discussion is about U-labels and A-labels, not unicode = strings and A-labels. >=20 > And my point was that for non-IDNs the registrant believes they are = registering an A-label which is the same A-label that the registry = registers. But with IDN there is no longer this direct relationship as = the registrant believes they are registering the U-label while the = registry actually registers the A-label. =20 I claim the registrant believe they register a unicode string, while the = registry in fact register an A-label. Thats why I am confused why people are so focused on U-labels. The = trouble is in the unicode string -> U-label mapping, not the U-label -> = A-label mapping. Patrik From james.mitchell@ausregistry.com.au Tue Feb 14 21:05:08 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847A821F85A0 for ; Tue, 14 Feb 2012 21:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAnmgLybaINI for ; Tue, 14 Feb 2012 21:05:07 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id 39BBE21F8597 for ; Tue, 14 Feb 2012 21:04:58 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 15 Feb 2012 16:04:53 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Wed, 15 Feb 2012 16:04:39 +1100 From: James Mitchell To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , Jay Daley Date: Wed, 15 Feb 2012 16:04:39 +1100 Thread-Topic: [provreg] U-labels and draft-obispo-epp-idn-00 Thread-Index: Aczrk6ly/FRFI+WYRTqSOzvJpLmQUgABB+Sw Message-ID: <8CEF048B9EC83748B1517DC64EA130FB6B2AB34880@off-win2003-01.ausregistrygroup.local> References: <20120214212504.GD22144@mail.yitter.info> <5855A893-7C29-4C1F-B03B-7A328ED761C5@isc.org> <550657DA-46E7-4573-AC95-D6FB24AC5F68@frobbit.se> <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> In-Reply-To: <1BB9C8AE-D1DF-4679-9D60-FA621DF01308@frobbit.se> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:05:08 -0000 I agree that _technically_ both A-label and U-label are not required. Howev= er by requiring both U-label and A-label a registry can guarantee that the = registrar knew the corresponding U-label prior to registration. Registrars = may choose to generate the U-label from the A-label (that they somehow deri= ved), however it is also their choice to send a create command to the regis= try where the U-label is not what the registrar or the registrant expected.= In this case the registry has done all it possibly can to ensure that the = correct name has been registered. You will find that a few ccTLDs will have= this hat on. As an example, consider the U-label of U+03C2 (final sigma) which has a cor= responding A-label of xn--3xa. Using IDNA 2003 based processing however the= derived ACE-label for U+03C2 is xn--4xa, which is a valid A-label, however= for the U-label U+03C3 (non-final sigma). A registrar can send the registr= y one of these A-labels, and the registry can programmatically determine th= e corresponding U-label, however is this the same U-label that the registra= r was expecting to register? James > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrik F=E4ltstr=F6m > Sent: Wednesday, 15 February 2012 2:41 PM > To: Jay Daley > Cc: provreg@ietf.org > Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 >=20 >=20 > On 15 feb 2012, at 04:19, Jay Daley wrote: >=20 > > On 15/02/2012, at 4:09 PM, Patrik F=E4ltstr=F6m wrote: > > > >>> I agree that this might come in handy in many cases > >> > >> Mention one. > > > > In .nz we expect both the U and A labels and that the A label is > correctly derived from the U. The reasoning for this is that > registrants are not in their minds registering the A label, they are > registering the U label and we want to guard against a processing error > that would not provide what the registrant wants. With only an A label > we can't trap this. >=20 > And you have factual errors where a U-label and an A-label does not > match? You do not talk about cases where they believe they can register > some unicode string that is not a U-label? >=20 > Note, the discussion is about U-labels and A-labels, not unicode > strings and A-labels. >=20 > Patrik >=20 > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Tue Feb 14 21:13:46 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DABD21F8671 for ; Tue, 14 Feb 2012 21:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXFmb7Ga4pBX for ; Tue, 14 Feb 2012 21:13:45 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4721F864A for ; Tue, 14 Feb 2012 21:13:45 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id C55B11ECB41C for ; Wed, 15 Feb 2012 05:13:44 +0000 (UTC) Date: Wed, 15 Feb 2012 00:13:42 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120215051341.GB1537@mail.yitter.info> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> 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: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 05:13:46 -0000 On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik Fältström wrote: > > In this case, what the client should send is _not_ a U-label. You know better than anyone else what an A-label and U-label is, and you give examples below on unicode strings that are passed around that are not U-labels. Remember that there is by definition a 1:1 mapping between A-labels and U-labels. > The examples I gave are not U-labels, no. But they're Unicode forms of IDNA2003-compliant systems that happen to generate Punycode forms that are perfectly good A-labels. If I got a candidate U-label that didn't match the A-label, I could detect this. If I just get the A-label, I can't. > And the question is then what to do if it is the case that: > > 1. That unicode string is passed to the registry > > 2. The registry do not believe that unicode string can be represented by the A-label that is also sent > If I ran the circus, this would be a fatal error for the registration. Moreover, RFC 5891, section 4.2.1, agrees with me: If both the U-label and A-label forms are available, the registry MUST ensure that the A-label form is in lowercase, perform a conversion to a U-label, perform the steps and tests described below on that U-label, and then verify that the A-label produced by the step in Section 4.4 matches the one provided as input. In addition, the U-label that was provided as input and the one obtained by conversion of the A-label MUST match exactly. If, for some reason, these tests fail, the registration MUST be rejected. > > In the case where the U-label contained "ß", the chances are at the > > > very least non-zero, at least today and for the near future: last I > > checked (about 30 seconds ago) libidn2 isn't in the Debian stable > > distribution, just for instance. Similarly with ZWNJ and ZWJ. > > So, the reason why we want to do this is to ensure there is no bug in the libraries used by various parties? There's no _bug_ in libidn when it maps ß to ss. That's what it's supposed to do. Moreover, if the input string was (say) üß, then the result would in fact be a Punycode-form IDNA2003 string that happened also to be an IDNA2008 A-label. It just wouldn't be the right one, because in IDNA2003 üß becomes üss before the Punycode transformation. The point of requiring the U-label is to be able to catch this sort of corner case. In complicated typographic systems like Arabic this is loads worse, because not only are ZWNJ and ZWJ mapped away in IDNA2003, but many people won't be able to see that. But a machine could spot it and throw an error. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From Klaus.Malorny@knipp.de Wed Feb 15 02:27:00 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337A421F86C5 for ; Wed, 15 Feb 2012 02:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxmWIQfDRK2l for ; Wed, 15 Feb 2012 02:26:59 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 2332C21F8643 for ; Wed, 15 Feb 2012 02:26:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id AF4C471; Wed, 15 Feb 2012 11:26:52 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id w48HEwK0UnC7; Wed, 15 Feb 2012 11:26:46 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id AA10E9C; Wed, 15 Feb 2012 10:36:04 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id q1F9a1BY007326; Wed, 15 Feb 2012 10:36:02 +0100 (MEZ) Message-ID: <4F3B7C81.8010404@knipp.de> Date: Wed, 15 Feb 2012 10:36:01 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120214 Thunderbird/13.0a1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 10:27:00 -0000 On 15/02/12 05:58, Patrik F=E4ltstr=F6m wrote: > On 15 feb 2012, at 04:58, Andrew Sullivan wrote: >> >> If those registries plan to use the EPP standard domain name mapping, >> they couldn't possibly do it this way: the element is no= t >> optional, and it only allows LDH. > > Good, then we agree here. > >>> - The a-label is what is mandatory and normative in the exchange betw= een epp client and server >> >> Already true in the RFCs we have. > > Exactly! > > Hi, where is this stated, if I may ask? Can't find this in RFC 5730/5731 or i= n the=20 RFC 5891 which was mentioned in a later post. In my humble opinion, it is a bad idea to spread the use of Punycode into= areas=20 where there is no technical need for it. While I am still fascinated abou= t the=20 mathematical tricks that are used in make the code as small as possible, = we=20 should not forget that it was a technical crutch to add Unicode to DNS in= a=20 backward-compatible fashion. I may be good for DNS, but should stay there= =2E XML=20 as the basis of EPP, on the other hand, has its own means to deal with Un= icode,=20 it even works with plain ASCII, using numeric entities. So using Punycode= with=20 XML is unnecessary and some kind of "double encoding". This is similar as= one=20 would mandate to use "U+NNNN" or "\uNNNN" notations or using UTF-7 within= the=20 XML document itself (i.e. not as a document encoding), which would of cou= rse=20 cause head-shaking. Of course, it is arguable what kind of Unicode string is expected, i.e. w= hether=20 it is demanded that a normalized, prepared or whatever constrained string= has to=20 be submitted, or whether the registry accepts any form and does the=20 normalization before it further processes the name. Regards, Klaus From paf@frobbit.se Wed Feb 15 02:38:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06F721F87CC for ; Wed, 15 Feb 2012 02:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slheZ-U+AgNM for ; Wed, 15 Feb 2012 02:38:45 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id E03F521F87C9 for ; Wed, 15 Feb 2012 02:38:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id 81A651317E45B; Wed, 15 Feb 2012 11:38:38 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QsdzLa6bBz1; Wed, 15 Feb 2012 11:38:38 +0100 (CET) Received: from dyn-fg117.sth.netnod.se (dyn-fg117.sth.netnod.se [77.72.226.117]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 21D691317E457; Wed, 15 Feb 2012 11:38:38 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <20120215051341.GB1537@mail.yitter.info> Date: Wed, 15 Feb 2012 08:57:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C236727-6DF6-4490-8737-F6FE028D7E0E@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <20120215051341.GB1537@mail.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 10:38:50 -0000 On 15 feb 2012, at 06:13, Andrew Sullivan wrote: > On Wed, Feb 15, 2012 at 05:58:50AM +0100, Patrik F=E4ltstr=F6m wrote: >>=20 >> In this case, what the client should send is _not_ a U-label. You = know better than anyone else what an A-label and U-label is, and you = give examples below on unicode strings that are passed around that are = not U-labels. Remember that there is by definition a 1:1 mapping between = A-labels and U-labels. >=20 > The examples I gave are not U-labels, no. But they're Unicode forms > of IDNA2003-compliant systems that happen to generate Punycode forms > that are perfectly good A-labels. If I got a candidate U-label that > didn't match the A-label, I could detect this. If I just get the > A-label, I can't. Bingo! Sending U-labels in addition to A-labels does not make any sense. >>> In the case where the U-label contained "=DF", the chances are at = the >>=20 >>> very least non-zero, at least today and for the near future: last I >>> checked (about 30 seconds ago) libidn2 isn't in the Debian stable >>> distribution, just for instance. Similarly with ZWNJ and ZWJ. >>=20 >> So, the reason why we want to do this is to ensure there is no bug in = the libraries used by various parties? >=20 > There's no _bug_ in libidn when it maps =DF to ss. That's what it's > supposed to do. Moreover, if the input string was (say) =FC=DF, then = the > result would in fact be a Punycode-form IDNA2003 string that happened > also to be an IDNA2008 A-label. It just wouldn't be the right one, > because in IDNA2003 =FC=DF becomes =FCss before the Punycode > transformation. The point of requiring the U-label is to be able to > catch this sort of corner case. But then you do no longer talk about sending U-labels and A-labels! You send unicode strings and A-labels! Patrik From shollenbeck@verisign.com Wed Feb 15 04:36:02 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5721F8666 for ; Wed, 15 Feb 2012 04:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-E9qImAXsec for ; Wed, 15 Feb 2012 04:36:01 -0800 (PST) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7021F863F for ; Wed, 15 Feb 2012 04:35:57 -0800 (PST) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKTzumqkS0z5LgvZ+ASXKIYenP/ovRJlxW@postini.com; Wed, 15 Feb 2012 04:36:00 PST Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q1FCZknS020863; Wed, 15 Feb 2012 07:35:49 -0500 Received: from dul1wnexcn04.vcorp.ad.vrsn.com ([10.170.12.139]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 07:35:46 -0500 Received: from BRN1WNEXCAS01.vcorp.ad.vrsn.com ([10.173.152.205]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 07:35:45 -0500 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Wed, 15 Feb 2012 07:35:44 -0500 From: "Hollenbeck, Scott" To: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= , "james.mitchell@ausregistry.com.au" Thread-Topic: [provreg] U-labels and draft-obispo-epp-idn-00 Thread-Index: AQHM6180qP3MO32kCU6H1xApp75svJY9YeeAgAA5fwCAAEfqEA== Date: Wed, 15 Feb 2012 12:35:44 +0000 Message-ID: <831693C2CDA2E849A7D7A712B24E257F0D59D7F9@BRN1WNEXMBX01.vcorp.ad.vrsn.com> References: <20120214212504.GD22144@mail.yitter.info> <8CEF048B9EC83748B1517DC64EA130FB6B2AB34671@off-win2003-01.ausregistrygroup.local> <98B6DF42-E7D1-4FF9-8C03-AD6C3830249D@frobbit.se> In-Reply-To: <98B6DF42-E7D1-4FF9-8C03-AD6C3830249D@frobbit.se> 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 X-OriginalArrivalTime: 15 Feb 2012 12:35:45.0647 (UTC) FILETIME=[56AEDFF0:01CCEBDE] Cc: "provreg@ietf.org" Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:36:02 -0000 > -----Original Message----- > From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On > Behalf Of Patrik F=E4ltstr=F6m > Sent: Tuesday, February 14, 2012 10:09 PM > To: james.mitchell@ausregistry.com.au > Cc: provreg@ietf.org > Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 >=20 >=20 > On 15 feb 2012, at 00:43, James Mitchell wrote: >=20 > > I agree with Andrew for including an optional "U-label" element. > Server policy can dictate how it is used. >=20 > No, this spec should dictate how it is used. It should not be one more > feature that can differ between epp implementations. >=20 > We should *not* diverge in epp on how we express domain names inside > the protocol. >=20 > The 'e' is not that much of an 'e'. Completely correct. I don't have a strong preference for including U-labels= or not (5891 suggests that including both is preferred "because it permits= further verification of user intent"), but if they are included the syntax= and processing should be consistent. Scott From paf@frobbit.se Wed Feb 15 04:38:17 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E95E21F867C for ; Wed, 15 Feb 2012 04:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQrPY4p5absL for ; Wed, 15 Feb 2012 04:38:17 -0800 (PST) Received: from srv01.frobbit.se (srv01.frobbit.se [IPv6:2a02:80:3ffe::39]) by ietfa.amsl.com (Postfix) with ESMTP id 75F5621F85BB for ; Wed, 15 Feb 2012 04:38:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id B1F5313181849; Wed, 15 Feb 2012 13:38:08 +0100 (CET) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pql3+d7hamw9; Wed, 15 Feb 2012 13:38:08 +0100 (CET) Received: from [IPv6:2a01:3f0:1::7c96:54d8:c3a0:f6ec] (unknown [IPv6:2a01:3f0:1::7c96:54d8:c3a0:f6ec]) (Authenticated sender: paf01) by srv01.frobbit.se (Postfix) with ESMTP id 7DE6F13181846; Wed, 15 Feb 2012 13:38:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <4F3B7C81.8010404@knipp.de> Date: Wed, 15 Feb 2012 13:38:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C9F5F10-9625-45C4-B53C-D5028C5B2C1E@frobbit.se> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <4F3B7C81.8010404@knipp.de> To: Klaus Malorny X-Mailer: Apple Mail (2.1257) Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:38:17 -0000 On 15 feb 2012, at 10:36, Klaus Malorny wrote: > to add Unicode to DNS in a backward-compatible fashion No, to add Unicode to domain names, and there are multiple reasons why = it ended up like it did. LDH encoding is just one of them. The ability = to have a different encoding in the future (different prefix than xn--, = i.e. without destroying the full namespace) another. But that discussion is something we do not have to have here. Where I agree with you is that it does not matter whether we pass = U-label or A-label as there is a 1:1 mapping between them, and that is = as I have explained in other email messages not a big deal. What people seems to ask for is the ability to pass a unicode string = together with {A,U}-label so that the registry can say whether what is = registered is really what the registrant asked for. Patrik From ajs@anvilwalrusden.com Wed Feb 15 05:18:47 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D3D21F8786 for ; Wed, 15 Feb 2012 05:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NbaclYBnBxY for ; Wed, 15 Feb 2012 05:18:47 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 0704521F877F for ; Wed, 15 Feb 2012 05:18:46 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 914A31ECB41C for ; Wed, 15 Feb 2012 13:18:45 +0000 (UTC) Date: Wed, 15 Feb 2012 08:18:39 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120215131838.GA1963@mail.yitter.info> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <20120215051341.GB1537@mail.yitter.info> <9C236727-6DF6-4490-8737-F6FE028D7E0E@frobbit.se> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9C236727-6DF6-4490-8737-F6FE028D7E0E@frobbit.se> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:18:47 -0000 Hi, At the risk of creating a stain on the ground where once there was a horse that had already been beaten to death, let me try once more. On Wed, Feb 15, 2012 at 08:57:17AM +0100, Patrik Fältström wrote: > > The examples I gave are not U-labels, no. But they're Unicode forms > > of IDNA2003-compliant systems that happen to generate Punycode forms > > that are perfectly good A-labels. If I got a candidate U-label that > > didn't match the A-label, I could detect this. If I just get the > > A-label, I can't. > > Bingo! > > Sending U-labels in addition to A-labels does not make any sense. Of course if we could be sure that every time we had what looked like an A-label, the party that sent it did in fact have the U-label, then I agree that there would be no reason whatever to send them both. The nice thing about IDNA2008 is that every A-label corresponds to exactly one U-label. The nasty thing about IDNA2008, however, is that some A-labels also correspond to Punycode forms from IDNA2003, and those Punycode forms do not always match a Unicode form that is the same as the U-label you'd get under IDNA2008. See upthread for examples. This incompatibility is one of the reasons that Unicode pushes UTS 46. I'm trying to suggest a way to ensure no confusion, by ensuring we have a (standard) way at registration time of detecting when something is wrong. I want to make the element optional precisely so that, at some brave happy day in the future when we have no reason to suppose anyone is sending an IDNA2003-based Punycode form, we could turn the thing off. Moreover, I'm aware that some registries don't like to do this sort of additional verification of client-supplied data, and that therefore it cannot be a required element. Even RFC 5891 doesn't say you need to submit both; it just says that it would be better. > But then you do no longer talk about sending U-labels and A-labels! > > You send unicode strings and A-labels! Yes, in a case where the U-label and A-label are not products of one another, then either the U-label or the A-label is wrong. But in some of those cases, it is _indeterminate_ which one is wrong. For instance, suppose I have a string with a final form sigma in the middle of it (because it's made up by putting together two strings that would be words in Greek), an IDNA2003 transformation will not include Punycode that will get you a final form sigma. The final form sigma is mapped away, as you know. Now, if you have the input of the candidate U-label and the candidate A-label, you can tell whether they are in fact the U-label and A-label for one another. If you only have the A-label, you can generate a perfectly good U-label, but it isn't the one the EPP client thought it was requesting. I maintain -- and I think the plain meaning of RFC 5891 agrees with me -- that this additional check should result in the rejection of the registration request. If it makes you happier to call the element where we put the candidate U-label "unicodestring", or "bobsgreatuncle", or "greatpointlesslongnameforelement", instead of "u-label", I don't care. My point is merely that it is entirely reasonable for a registry to have this requirement, and to enforce it. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From michael@mwyoung.ca Wed Feb 15 05:45:11 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184A621F862F for ; Wed, 15 Feb 2012 05:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4OyYPrNVj8i for ; Wed, 15 Feb 2012 05:45:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB8421F8722 for ; Wed, 15 Feb 2012 05:45:03 -0800 (PST) Received: by iagf6 with SMTP id f6so1748716iag.31 for ; Wed, 15 Feb 2012 05:45:02 -0800 (PST) Received: by 10.42.144.2 with SMTP id z2mr33300864icu.18.1329313501566; Wed, 15 Feb 2012 05:45:01 -0800 (PST) Received: from DUN20111 (CPEf81edff844ad-CM00080da07047.cpe.net.cable.rogers.com. [99.226.80.88]) by mx.google.com with ESMTPS id mr24sm5950375ibb.1.2012.02.15.05.44.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Feb 2012 05:45:00 -0800 (PST) From: "Michael Young" To: =?iso-8859-1?Q?'Patrik_F=E4ltstr=F6m'?= , "'Andrew Sullivan'" References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> In-Reply-To: Date: Wed, 15 Feb 2012 08:44:58 -0500 Message-ID: <000901ccebe8$02f7b530$08e71f90$@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIjGdEfdNdakZOGM+GmBYK2Yt3ewwJbcNQfAhJHf/sBqqp5Z5Vg1mnQ Content-Language: en-ca X-Gm-Message-State: ALoCoQlbfYTnCgbBAaA7BLO9AJzsbbj6VzRz5HrkTdIZAv9tu8qZPnJnQqnIH/woTrSBbDvdJukU Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 13:45:11 -0000 I agree with Patrick here but please read my whole response before = reacting, So we are suggesting that we set the expectation ( and I say setting expectation only because it was suggested as optional) that the registry will do the work of validating whether or not the registrar successfully translated their U-label to the right A-label. The problems I see here is that you end up with more overhead in the = inline transaction OR you have to go asynch and inform them later on if they succeeded in the registration. Just in principle I don=92t like loading = up the synchronous transaction further and asynch does not tend to make registrars happy. They like to tell their customers whether or not they = got the registration while they wait at their web portals. Having said all that I am now going to turn my line of argument 180 = degrees. Since we know some registries are actually already doing this, and the PRIORITY goal is to have one IDN extension to rule them all, then I = think we need to include it as optional. It's out there, it's happening for = various reasons, and we need to accommodate it. Michael Young -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On = Behalf Of Patrik F=E4ltstr=F6m Sent: February-14-12 11:59 PM To: Andrew Sullivan Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 On 15 feb 2012, at 04:58, Andrew Sullivan wrote: > Of all the people I'd ever imagined would suggest that IDNs were=20 > simple, you were last but one -- the other guy was Klensin -- in line! = =20 > But let me respond in detail below. :-D The whole reason for my answer is because IDN _is_ complicated. >> Further, if we go down this path of sending a U-label, then we might=20 >> in the next step have epp servers that give the ability for the=20 >> client to send unicode strings that are non-normalized and because of = >> that not 1:1 mappings to the A-label as this piece of the data, and=20 >> then validation whether the A-label matches or not -- according to=20 >> the algorithm chosen by the registry. >=20 > If those registries plan to use the EPP standard domain name mapping,=20 > they couldn't possibly do it this way: the element is=20 > not optional, and it only allows LDH. Good, then we agree here. >> - The a-label is what is mandatory and normative in the exchange=20 >> between epp client and server >=20 > Already true in the RFCs we have. Exactly! >> - An epp server might optionally accept a u-label, but that is never=20 >> mandatory >=20 > This is just registry policy, and there is no way you (or anyone else) = > is going to be able to legislate it. To begin with, there are many=20 > ccTLDs that are not subject to ICANN contract. No, it has to do whether a registry that claims to use epp is doing. We already have far too many "private extensions" to epp where = registries claims they implement epp when in fact they have private extensions, or interpretations of extensions that forces registrars to make all = different kind of hacks to be able to interoperate. I do not want that to be possible. I want to limit the number of = extensions to epp to an absolute minimum and I want registries that implement them = to do it the same way. If a registry choose to NOT use epp, fine. I will not force them. But as = a registrar it is very good to know. Specifically for the registries that = do claim today they use epp, but you can not see the specification of their protocol unless you sign an NDA, pay a check, and THEN you see the epp version they have is so broken it is...well, I do not really have words = for some of the things I have seen here. Once again, I am not against them doing whatever they want. I am against calling that epp. We *MUST* be better on saying what is epp and what is not epp. And, sure, an extension that a registry have that is not mandatory for = the registrar, that is fine, as the registrar does not have to implement = that feature. >> - Wrong u-label (or never sending it) can never block the use of the=20 >> a-label given it is accepted >=20 > The entire _point_ of the extension would be to block such an A-label. = =20 > The idea is exactly to make sure that the EPP client is sending you=20 > data that is correct. The idea here is exactly to make sure that the=20 > client and server in the EPP transaction agree on exactly what's being = > exchanged. In this case, what the client should send is _not_ a U-label. You know better than anyone else what an A-label and U-label is, and you give examples below on unicode strings that are passed around that are not U-labels. Remember that there is by definition a 1:1 mapping between A-labels and U-labels. What I hear you say now is that the client should be able to pass an = A-label for registration, and also a unicode string that the client do claim is = what the registrant wanted to register. And the question is then what to do if it is the case that: 1. That unicode string is passed to the registry 2. The registry do not believe that unicode string can be represented by = the A-label that is also sent > Some registries check to make sure name servers are properly=20 > delegated. Checking that a domain name is delegated before it can be registered I = think is a big mistake, as they do not accept domain names to be registered without being delegated. That increases the interest in their zone file = as the zone file in this case do disclose what domain names are registered = and not. My point is that yes, validation of various kinds is good of course (I = have been pushing for more validations myself), but tying it to _registration_policy_ is a pain. > That mode of operation appears to be supported by some text in RFCs=20 > 1034 and 1035, but many gTLDs don't do it. By the same token, RFC=20 > 5891 says that collecting both the U-label and the A-label, or only=20 > the A-label, are preferable; and of these, the former is preferred=20 > over the latter. If you think that verify the name server data that a = > client hands you is acceptable, then why isn't it acceptable to verify = > the transformation -- probably performed by an intermediate party=20 > ("the registrar") rather than the person who wants the name ("the=20 > registrant") -- in the case of A-labels and U-labels? There is a big difference between validating A-label and U-label = conformance and A-label and unicode string matchings. >> I.e. I ask myself, if you as an epp client do have a U-label, what is = the chance the A-label is calculated wrongly? Adding that as a "feature" is = just silly. >=20 > In the case where the U-label contained "=DF", the chances are at the > very least non-zero, at least today and for the near future: last I=20 > checked (about 30 seconds ago) libidn2 isn't in the Debian stable=20 > distribution, just for instance. Similarly with ZWNJ and ZWJ. So, the reason why we want to do this is to ensure there is no bug in = the libraries used by various parties? What is the library is wrong in the registry, but not registrar? Once again, having the registry exposing an optional function where a _unicode_string_ can be passed together with an A-label to have that validated together with whatever policies the registry has, fine, but = not be able to (according to epp) register a domain name with only an A-label = is what I am against. Patrik _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From james.mitchell@ausregistry.com.au Wed Feb 15 06:48:49 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A006D21F8526 for ; Wed, 15 Feb 2012 06:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHn1RPrC0Kay for ; Wed, 15 Feb 2012 06:48:48 -0800 (PST) Received: from mx01.ausregistry.net.au (mx01.ausregistry.net.au [202.65.15.41]) by ietfa.amsl.com (Postfix) with ESMTP id B72DB21F8540 for ; Wed, 15 Feb 2012 06:48:46 -0800 (PST) Received: from off-win2003-01.stkildard.vic.ausregistry.com.au (HELO off-win2003-01.ausregistrygroup.local) ([10.30.1.3]) by iron01.off08.stkildard.vic.ausregistry.com.au with ESMTP; 16 Feb 2012 01:48:43 +1100 Received: from off-win2003-01.ausregistrygroup.local ([10.30.1.3]) by off-win2003-01.ausregistrygroup.local ([10.30.1.3]) with mapi; Thu, 16 Feb 2012 01:48:29 +1100 From: James Mitchell To: Michael Young , =?iso-8859-1?Q?=27Patrik_F=E4ltstr=F6m=27?= , 'Andrew Sullivan' Date: Thu, 16 Feb 2012 01:48:40 +1100 Thread-Topic: [provreg] U-labels and draft-obispo-epp-idn-00 Thread-Index: Aczr8ODl8gf4xqFQQ5601pmNXyb/PA== Message-ID: In-Reply-To: <000901ccebe8$02f7b530$08e71f90$@mwyoung.ca> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 14:48:49 -0000 There seems some confusion about what this "unicode domain name" represents. It is my understanding that it is the _expected_ U-label form. The deviations between IDNA 2003 and IDNA 2008 (sigma, zwnj etc) illustrate a potential benefit to this approach. Michael, if this is the case then there is no additional overhead in logic other than one string comparison. This is very different however to a (user supplied?) Unicode string that somehow maps to the A-label form. I don't see how a registry could make use of this programatically unless the same registry also defined the mappings allowed for the translation of the arbitrary Unicode string to an A-label. A registry may however want this value for non-programatic reasons including correspondence with the registrant. This extension should clearly state which of the above it represents if the intent is to avoid different implementations, of course assuming that the extension will include this "unicode domain name" element :) James On 16/02/12 12:44 AM, "Michael Young" wrote: >I agree with Patrick here but please read my whole response before >reacting, > > >So we are suggesting that we set the expectation ( and I say setting >expectation only because it was suggested as optional) that the registry >will do the work of validating whether or not the registrar successfully >translated their U-label to the right A-label. > >The problems I see here is that you end up with more overhead in the >inline >transaction OR you have to go asynch and inform them later on if they >succeeded in the registration. Just in principle I don=B9t like loading u= p >the synchronous transaction further and asynch does not tend to make >registrars happy. They like to tell their customers whether or not they >got >the registration while they wait at their web portals. > >Having said all that I am now going to turn my line of argument 180 >degrees. >Since we know some registries are actually already doing this, and the >PRIORITY goal is to have one IDN extension to rule them all, then I think >we >need to include it as optional. It's out there, it's happening for >various >reasons, and we need to accommodate it. > > >Michael Young > >-----Original Message----- >From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf >Of Patrik F=E4ltstr=F6m >Sent: February-14-12 11:59 PM >To: Andrew Sullivan >Cc: provreg@ietf.org >Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 > >On 15 feb 2012, at 04:58, Andrew Sullivan wrote: > >> Of all the people I'd ever imagined would suggest that IDNs were >> simple, you were last but one -- the other guy was Klensin -- in line! >> But let me respond in detail below. > >:-D > >The whole reason for my answer is because IDN _is_ complicated. > >>> Further, if we go down this path of sending a U-label, then we might >>> in the next step have epp servers that give the ability for the >>> client to send unicode strings that are non-normalized and because of >>> that not 1:1 mappings to the A-label as this piece of the data, and >>> then validation whether the A-label matches or not -- according to >>> the algorithm chosen by the registry. >>=20 >> If those registries plan to use the EPP standard domain name mapping, >> they couldn't possibly do it this way: the element is >> not optional, and it only allows LDH. > >Good, then we agree here. > >>> - The a-label is what is mandatory and normative in the exchange >>> between epp client and server >>=20 >> Already true in the RFCs we have. > >Exactly! > >>> - An epp server might optionally accept a u-label, but that is never >>> mandatory >>=20 >> This is just registry policy, and there is no way you (or anyone else) >> is going to be able to legislate it. To begin with, there are many >> ccTLDs that are not subject to ICANN contract. > >No, it has to do whether a registry that claims to use epp is doing. > >We already have far too many "private extensions" to epp where registries >claims they implement epp when in fact they have private extensions, or >interpretations of extensions that forces registrars to make all different >kind of hacks to be able to interoperate. > >I do not want that to be possible. I want to limit the number of >extensions >to epp to an absolute minimum and I want registries that implement them to >do it the same way. > >If a registry choose to NOT use epp, fine. I will not force them. But as a >registrar it is very good to know. Specifically for the registries that do >claim today they use epp, but you can not see the specification of their >protocol unless you sign an NDA, pay a check, and THEN you see the epp >version they have is so broken it is...well, I do not really have words >for >some of the things I have seen here. > >Once again, I am not against them doing whatever they want. I am against >calling that epp. > >We *MUST* be better on saying what is epp and what is not epp. > >And, sure, an extension that a registry have that is not mandatory for the >registrar, that is fine, as the registrar does not have to implement that >feature. > >>> - Wrong u-label (or never sending it) can never block the use of the >>> a-label given it is accepted >>=20 >> The entire _point_ of the extension would be to block such an A-label. >> The idea is exactly to make sure that the EPP client is sending you >> data that is correct. The idea here is exactly to make sure that the >> client and server in the EPP transaction agree on exactly what's being >> exchanged. > >In this case, what the client should send is _not_ a U-label. You know >better than anyone else what an A-label and U-label is, and you give >examples below on unicode strings that are passed around that are not >U-labels. Remember that there is by definition a 1:1 mapping between >A-labels and U-labels. > >What I hear you say now is that the client should be able to pass an >A-label >for registration, and also a unicode string that the client do claim is >what >the registrant wanted to register. > >And the question is then what to do if it is the case that: > >1. That unicode string is passed to the registry > >2. The registry do not believe that unicode string can be represented by >the >A-label that is also sent > >> Some registries check to make sure name servers are properly >> delegated. > >Checking that a domain name is delegated before it can be registered I >think >is a big mistake, as they do not accept domain names to be registered >without being delegated. That increases the interest in their zone file as >the zone file in this case do disclose what domain names are registered >and >not. > >My point is that yes, validation of various kinds is good of course (I >have >been pushing for more validations myself), but tying it to >_registration_policy_ is a pain. > >> That mode of operation appears to be supported by some text in RFCs >> 1034 and 1035, but many gTLDs don't do it. By the same token, RFC >> 5891 says that collecting both the U-label and the A-label, or only >> the A-label, are preferable; and of these, the former is preferred >> over the latter. If you think that verify the name server data that a >> client hands you is acceptable, then why isn't it acceptable to verify >> the transformation -- probably performed by an intermediate party >> ("the registrar") rather than the person who wants the name ("the >> registrant") -- in the case of A-labels and U-labels? > >There is a big difference between validating A-label and U-label >conformance >and A-label and unicode string matchings. > >>> I.e. I ask myself, if you as an epp client do have a U-label, what is >>>the >chance the A-label is calculated wrongly? Adding that as a "feature" is >just >silly. >>=20 >> In the case where the U-label contained "=DF", the chances are at the > >> very least non-zero, at least today and for the near future: last I >> checked (about 30 seconds ago) libidn2 isn't in the Debian stable >> distribution, just for instance. Similarly with ZWNJ and ZWJ. > >So, the reason why we want to do this is to ensure there is no bug in the >libraries used by various parties? > >What is the library is wrong in the registry, but not registrar? > >Once again, having the registry exposing an optional function where a >_unicode_string_ can be passed together with an A-label to have that >validated together with whatever policies the registry has, fine, but not >be >able to (according to epp) register a domain name with only an A-label is >what I am against. > > Patrik > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg > >_______________________________________________ >provreg mailing list >provreg@ietf.org >https://www.ietf.org/mailman/listinfo/provreg From ajs@anvilwalrusden.com Wed Feb 15 08:56:21 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C9321F86E4 for ; Wed, 15 Feb 2012 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-1.497, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_INFO=1.448, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ORi51mrBCj7 for ; Wed, 15 Feb 2012 08:56:20 -0800 (PST) Received: from pdx-1.yitter.info (unknown [174.140.166.76]) by ietfa.amsl.com (Postfix) with ESMTP id E548521F8698 for ; Wed, 15 Feb 2012 08:56:20 -0800 (PST) Received: from crankycanuck.ca (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: ajs@crankycanuck.ca) by pdx-1.yitter.info (Postfix) with ESMTPSA id 55C6DA358092 for ; Wed, 15 Feb 2012 08:56:19 -0800 (PST) Date: Wed, 15 Feb 2012 11:56:11 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120215165610.GA25702@crankycanuck.ca> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <4F3B7C81.8010404@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F3B7C81.8010404@knipp.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 16:56:21 -0000 On Wed, Feb 15, 2012 at 10:36:01AM +0100, Klaus Malorny wrote: > where is this stated, if I may ask? Can't find this in RFC 5730/5731 > or in the RFC 5891 which was mentioned in a later post. RFC 5731 says, "The syntax for domain and host names described in this document MUST conform to [RFC0952] and [RFC1123]." (See section 2.1.) 952, even as revised by 1123, is where the LDH rule comes from. This means that domain names in the EPP domain name mapping must conform to the LDH rules, which means that if they're IDNs they have to be A-labels. RFC 5891 is about how you handle the A-label and U-label when you get it at registration time. > Of course, it is arguable what kind of Unicode string is expected, The reason I was focussing on U-labels rather than any old Unicode string is in line with what others have said. If a registry gets a Unicode string in NFD, or gets a string with upper case characters, or a whole host of other possible mistakes under IDNA2008, I wouldn't expec that to be accepted. What goes in a slot intended for a U-label ought to be a real U-label. The only question is whether the U-label and the A-label match one another. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From Klaus.Malorny@knipp.de Wed Feb 22 06:27:30 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1352D21F869A for ; Wed, 22 Feb 2012 06:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87Wl-lPRamCq for ; Wed, 22 Feb 2012 06:27:29 -0800 (PST) Received: from kmx10a.knipp.de (clust3b-eth0-0.bbone.knipp.de [195.253.6.85]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6A821F86C9 for ; Wed, 22 Feb 2012 06:27:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 174DF59; Wed, 22 Feb 2012 15:27:27 +0100 (MEZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id 98KAPeBVgjuq; Wed, 22 Feb 2012 15:27:21 +0100 (MEZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 55F7B58; Wed, 22 Feb 2012 15:27:21 +0100 (MEZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id q1MERJkJ016666; Wed, 22 Feb 2012 15:27:20 +0100 (MEZ) Message-ID: <4F44FB47.4090504@knipp.de> Date: Wed, 22 Feb 2012 15:27:19 +0100 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120221 Thunderbird/13.0a1 MIME-Version: 1.0 To: Andrew Sullivan References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <4F3B7C81.8010404@knipp.de> <20120215165610.GA25702@crankycanuck.ca> In-Reply-To: <20120215165610.GA25702@crankycanuck.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: provreg@ietf.org Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 14:27:30 -0000 On 15/02/12 17:56, Andrew Sullivan wrote: > On Wed, Feb 15, 2012 at 10:36:01AM +0100, Klaus Malorny wrote: >> where is this stated, if I may ask? Can't find this in RFC 5730/5731 >> or in the RFC 5891 which was mentioned in a later post. > > RFC 5731 says, "The syntax for domain and host names described in > this document MUST conform to [RFC0952] and [RFC1123]." (See section > 2.1.) 952, even as revised by 1123, is where the LDH rule comes > from. This means that domain names in the EPP domain name mapping > must conform to the LDH rules, which means that if they're IDNs they > have to be A-labels. > Ok, accepted, thanks. I should better re-read RFC 5730 et seqq. to see whether it still contains more backward-looking rules that have been overcome elsewhere ;-) > RFC 5891 is about how you handle the A-label and U-label when you get > it at registration time. > >> Of course, it is arguable what kind of Unicode string is expected, > > The reason I was focusing on U-labels rather than any old Unicode > string is in line with what others have said. If a registry gets a > Unicode string in NFD, or gets a string with upper case characters, or > a whole host of other possible mistakes under IDNA2008, I wouldn't > expect that to be accepted. What goes in a slot intended for a U-label > ought to be a real U-label. The only question is whether the U-label > and the A-label match one another. > > Best regards, > > A > So you suggest that upper case domain names should be better rejected, consequentially? And for both non-IDNs and IDN A-labels? While it makes life easier for the registries, I have the feeling that a few registrars would get some trouble with this. Regards, Klaus From ajs@anvilwalrusden.com Wed Feb 22 07:05:29 2012 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BA121F87B7 for ; Wed, 22 Feb 2012 07:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8rYeAXjm2ps for ; Wed, 22 Feb 2012 07:05:28 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id BC01D21F8759 for ; Wed, 22 Feb 2012 07:05:28 -0800 (PST) Received: from mail.yitter.info (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id E689C1ECB41D for ; Wed, 22 Feb 2012 15:05:27 +0000 (UTC) Date: Wed, 22 Feb 2012 10:05:26 -0500 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20120222150525.GJ34608@mail.yitter.info> References: <20120214212504.GD22144@mail.yitter.info> <77904F9A-D8C4-4815-86E4-B426BA824540@frobbit.se> <20120215035845.GA1537@mail.yitter.info> <4F3B7C81.8010404@knipp.de> <20120215165610.GA25702@crankycanuck.ca> <4F44FB47.4090504@knipp.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F44FB47.4090504@knipp.de> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] U-labels and draft-obispo-epp-idn-00 X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:05:29 -0000 On Wed, Feb 22, 2012 at 03:27:19PM +0100, Klaus Malorny wrote: > So you suggest that upper case domain names should be better > rejected, consequentially? And for both non-IDNs and IDN A-labels? > While it makes life easier for the registries, I have the feeling > that a few registrars would get some trouble with this. For LDH-labels, of course, it doesn't matter. I think for users it would be nice if we trained people to expect only lower case in domain names (more on why below), but I wasn't intending to advocate that. For U-labels, though, of course, an upper case character is DISALLOWED. This extends even to ASCII-range code points that would be accepted in LDH: "CaféCrème" is not a U-label, even though "CafeCreme" is a perfectly good LDH-label. Those need to be lower case for sure. In the case of A-labels, I _thought_ we issued a clarification about Appendix A in RFC 3492. That appendix has some remarks about mixed case, and the issue is that, since no U-label may have mixed case, therefore Punycode can't either. But I can't find the clarification right now. It nevertheless seems a consequence, and therefore I think A-labels should always be in lower case. Because U-labels can't ever have upper case, RFC 5895 and some other documents (prominently UTS 46) suggest always mapping upper to lower case. I think that's a good idea, but any time there's a mapping step in between user input and what the application actually uses I get nervous. Therefore, I think it would be better for everyone if we gradually trained people to use lower case for DNS labels everywhere. Yes, I'm aware that that will suck in places where CamelCase has helped clarify what ExpertsExchange is really about. But "the application knows your intention" has not been, I suggest, a universal success. This goal is probably tilting at windmills, however, since many registries I know of often spell their domain names in capital letters in running text. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com