Re: [provreg] Publishing of the IDN Table EPP Mapping IETF Draft

Kim Davies <kim.davies@icann.org> Fri, 13 March 2015 22:26 UTC

Return-Path: <kim.davies@icann.org>
X-Original-To: provreg@ietfa.amsl.com
Delivered-To: provreg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50A51A89AE; Fri, 13 Mar 2015 15:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nCn-hFHMcyO; Fri, 13 Mar 2015 15:26:37 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B0E91A87C2; Fri, 13 Mar 2015 15:26:37 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.847.32; Fri, 13 Mar 2015 15:26:35 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Fri, 13 Mar 2015 15:26:35 -0700
From: Kim Davies <kim.davies@icann.org>
To: "Gould, James" <JGould@verisign.com>
Thread-Topic: [provreg] Publishing of the IDN Table EPP Mapping IETF Draft
Thread-Index: AQHQQWJumxRDFmqfz0eXkuVv273QPp0NhymAgA27w4CAAGktAA==
Date: Fri, 13 Mar 2015 22:26:35 +0000
Message-ID: <9687A5E5-ACAC-482F-B422-55B590F909DC@icann.org>
References: <96D1CC17-60A1-445A-8B2F-B56918E4D881@verisign.com> <14D87A78-F5A2-458C-969B-593FE732A822@icann.org> <F22B58EC-84F1-4BD0-9217-0EF7849368B9@verisign.com>
In-Reply-To: <F22B58EC-84F1-4BD0-9217-0EF7849368B9@verisign.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6ADDB020AFC9044EB7A68FB7CE22773A@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/provreg/JzmLrP0A9CzrIC6Xrq2YRxD_gRU>
Cc: "gtld-tech@icann.org" <gtld-tech@icann.org>, "eppext@ietf.org" <eppext@ietf.org>, EPP Provreg <provreg@ietf.org>
Subject: Re: [provreg] Publishing of the IDN Table EPP Mapping IETF Draft
X-BeenThere: provreg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPP discussion list <provreg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/provreg>, <mailto:provreg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/provreg/>
List-Post: <mailto:provreg@ietf.org>
List-Help: <mailto:provreg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/provreg>, <mailto:provreg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 22:26:38 -0000

Hi James,

> Thank you for the feedback.  The main question that I have around draft-davies-idntables is whether it is meant for servers, for clients, or both.  Would the Registrars have the need for the IDN Table code points as defined in draft-gould-idn-table or have the need for the more extensive Label Generation Rules (LGR) as defined in draft-davies-idntables from within EPP?  I will provide separate feedback to draft-davies-idntables from a server perspective, but I would like to know what information the clients would like to have.  Inclusion of the code points in draft-gould-idn-table was based on feedback from a Registrar to support caching, when the idea for draft-gould-idn-table was formed.  

draft-davies-idntables has no specific target in mind with respect to servers or clients, it is just a descriptive format for describing label generation policies. It is silent on where you may choose to use the data. The primary driver is in any context where IDN tables may have been traditionally been used, but we were mindful to make it generic so it may be used in non-IDN contexts, and in fact non-domain contexts.

It would be useful to know what the registrar expectation is for this data. Is the expectation that registrars can use this data to fully ascertain whether a label is within the registry’s rules, or a subset of them? Even if a client could pre-vet a given label against a table/LGR, it will still be for the registry to ultimately determine whether it is willing to allocate it given a table/LGR alone can not tell you if a given label is available for registration.

The risk of using a format that only allows for describing simple code point eligibility as it appears to be undefined what happens if the registry enforces contextual rules? e.g. code point A is only permitted if it appears after code point B. If the EPP extension can only signal part of the policy then the client may be under a mistaken assumption that something is permitted when it is not, or vice versa, that a code point is not eligible but it actually is in the given context.

kim