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

From: Kim Davies <[email-masked]>
Date: Wed, 4 Mar 2015 21:26:42 +0000

Hi James, Hi all,

The first draft of the IDN Table EPP Mapping has been submitted to the IETF.  I co-authored this draft with Francisco Obispo and Luis Muñoz from Uniregistry to provide a mechanism for getting IDN Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension ( draft-ietf-eppext-idnmap ).  We would like this draft to be included in a re-charting of the EPPEXT Working Group.  The draft information is provided below.

URL:            http://www.ietf.org/internet-drafts/draft-gould-idn-table-00.txt
Status:         https://datatracker.ietf.org/doc/draft-gould-idn-table/
Htmlized:       http://tools.ietf.org/html/draft-gould-idn-table-00

Please review the draft and provide any feedback.

I’ve reviewed this draft, and the -01 update, and have some belated feedback on this document.

Along with colleagues in the community, I have been working on draft-davies-idntables (https://tools.ietf.org/html/draft-davies-idntables) and its goal is to document a universal format for “IDN tables”, intended to supersede and be a full superset of the panoply for formats that are out there today. This format has a specific schema, is intended to be fully machine readable, and allow implementation using a generic LGR-capable engine. Based on draft-gould-idn-table I believe it should be fully capable of representing the IDN table data described in the document.

I would recommend recasting this proposed mapping to utilise draft-davies-idntables as the mechanism for describing code point eligibility, and making the <info> verb in the EPP extension a mechanism for transmitting fully-formed label generation rulesets (the term for IDN tables in draft-davies-idntables). It would provide for maximum reuse of the grammar, plus provide the additional benefit that should a registry have a more complex policy than simple codepoint eligibility that it can be accurately conveyed.

Given the term “IDN tables” is being gradually replaced with “label generation rulesets” (LGRs) in ICANN’s work, as a more generic term that is not specific to IDNs, it is worth considering using this terminology elsewhere in this document.

If there are particular considerations that mean draft-davies-idntables wouldn’t be a suitable format, that would be useful feedback to help us iterate the draft-davies-idntables document with additional requirements.

cheers,

kim

---

From: "Gould, James" <[email-masked]>
Date: Fri, 13 Mar 2015 19:11:58 +0000

Kim,

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.

I will discuss draft-gould-idn-table at the Registration Operations Workshop ( http://www.regiops.net ), that is being held immediately prior to IETF-92, on March 22nd.  We hopefully can discuss this and other feedback there.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On Mar 4, 2015, at 4:26 PM, Kim Davies <[email-masked]<mailto:[email-masked]>> wrote:

Hi James, Hi all,

cheers,

kim

---

From: Kim Davies <[email-masked]>
Date: Fri, 13 Mar 2015 22:26:35 +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 Ta…

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