Page History

ICANN intends to develop a tool to allow the Generation Panels and the community to develop and use Label Generation Ruleset (LGR) in the new machine-readable XML-based format.ICANN‭ is releasing the set of requirements for the development of this LGR tool for public comment, specifically to get feedback on (i) the completeness of current requirements, (ii) the prioritization done in the different phases for development of the tool, and (iii) any other aspects associated with the LGR tool requirements.

Purpose

ICANN is currently developing a Label Generation Ruleset (LGR) for the Root Zone, which will be used to validate top-level domain (TLD) labels and to determine their variants. In addition,ICANN is assisting in the development of a new machine-readable XML-based format to be used for organizing and representing the LGR data. The formal representation is captured in "Representing Label Generation Rulesets using XML (draft-davies-idntables-08)", which is work in progress and available at https://tools.ietf.org/html/draft-davies-idntables (the XML format).

The current public comment is meant to allow community members to provide feedback on the set of requirements ICANN proposes for the development of the LGR Tool. The LGR tool specifications document [PDF, 137 KB] describes the potential users and use cases for the LGRand details the relevant requirements for the development of the LGR Tool.

Following this public review process, ICANN will incorporate relevant suggestions and will seek proposals through a request for proposals (RFPs), from parties that can perform required functions for the development of the LGR tool.

Potential users and high-level use cases

1. Generation Panels and Registries – LGR Creation

   As a first step, before an LGR can be used, the LGR must be created. The LGR may be created for the top-level or for second and other levels. For the top-level, the LGR is being created by a process involving communities organized into Generation Panels (GPs) (see the Procedure [PDF, 771 KB]), who have the necessary expertise to work on the content of the LGR but may not have necessary expertise to author the LGR file in the XML format. Thus, an easy to use interface is needed for the GPs to input linguistic data for an LGR and create it in the XML format. Further, as the use of the XML format is adopted by the DNS industry, other stakeholders, including domain registries at the second and other levels, will also benefit from tools to convert their data into the XML format.

2. TLD applicants and End-Users – LGR Use

   Once an LGR is created, it is intended to be used to validate if a label is allowed per the rules being captured by the LGR. For example, TLD applicants may use a tool supporting the XML format to use the Root LGR to determine (i) if the label being applied for meets the requirements of a TLD label as allowed by the IDNA2008 standard and constrained further by the community through the LGR for the Root Zone, and (ii) what are the variant labels (if any) of the label, along with dispositions of these variants (such as allocatable or blocked). End-users may use the same tool to determine the validity of a label for second or other levels, if the LGR is made available by the relevant registry in the XML format.

3. Integration Panel and Registries – LGR Management

   As the LGR is being created and maintained, there may be additional management operations needed. This includes merging two LGRs into a single combined one, comparing two LGRs to determine similarity (or differences) between them, and other such functions. For example, the Integration Panel tasked to finalize the LGR for the Root Zone (see the Procedure [PDF, 771 KB]), may need to merge LGR proposals by different GPs together or compare and highlight the differences between two different GP proposals which use an overlapping subset of code points. Similarly, registries may require such functions to add support for more languages or scripts over time. Another management function is for the tool to be able to convert the language tables from (some of) the existing formats into the XML format.

To support IDN variants in the Root Zone, the ICANN community, at the direction of the Board, undertook several projects to study and make recommendations on their viability, sustainability and delegation. Work during the development of the Integrated Issues Report [PDF, 2.14 MB] made obvious the lack of a common IDN table and standard implementation, and the need of specifications and a tool to make them machine parseable. The community would benefit from the standardization that would allow software implementers to easily validate labels and generate their variant labels.

ICANN staff has initiated and lead the Label Generation Ruleset Tool Project (P1) to develop a standard tool specification for listing allowed code points, their corresponding variant code points if any, and any additional label level rules. The specifications propose an XML-based format for this purpose. To gather input from interested parties, corresponding Internet Drafts were published through the IETF technical standard body at: http://tools.ietf.org/html/draft-davies-idntables.

The Label Generation Ruleset format and tool is expected to be useful for any registry implementing LGRs at any level in the DNS tree, and therefore is not specific to the Root Zone.

LGR Tool Set specifications document [PDF, 137 KB]

http://tools.ietf.org/html/draft-davies-idntables