Representing Label Generation Rulesets Using XML

Code points are encoded as hexadecimal strings rather than native Unicode characters in XML. The rationale (per UAX42) is that hexadecimal notation is unambiguous across implementations and avoids encoding-related issues with XML character data.

Prior to this specification, LGRs were published as ASCII text or HTML loosely based on RFC 3743 format. These formats were inconsistent across implementations because the evaluation algorithms were implicit. A structured XML format improves machine readability, consistency, reusability, and maintainability.

The relation between variant 'type' attribute values and resulting label dispositions is made fully explicit via 'action' elements, rather than relying on built-in algorithms. This allows generalized resolution policies beyond the default 'most restrictive disposition wins' behavior.

Variant symmetry (if A is a variant of B, then B is a variant of A) and transitivity are NOT automatically implied; they must be spelled out explicitly in the LGR. This was a deliberate choice to make symmetry verifiable mechanically and to avoid hidden assumptions in implementations.

Existing IDN tables based on RFC 3743 and RFC 4290 formats can be translated into the LGR XML format. Appendix B provides a detailed guide for performing this translation, preserving all applicable interpretation logic.

A document MUST contain exactly one 'lgr' element. Each 'lgr' element MUST contain zero or one 'meta' element, exactly one 'data' element, and zero or one 'rules' element; these three elements MUST appear in that order.

All 'char' elements in the 'data' section MUST have distinct 'cp' attributes. 'range' elements MUST NOT specify code point ranges that overlap another range or any single 'char' element. An LGR defining the same code point more than once MUST be rejected.

All implementations processing LGR files SHOULD provide support for at minimum the Unicode properties: General Category (gc), Script (sc), Canonical Combining Class (ccc), Bidi Class (bc), Arabic Joining Type (jt), Indic Syllabic Category (InSC), and Deprecated (Dep).

An LGR MUST be expressed as a well-formed XML document conforming to the schema defined in Appendix D. A document that is not well-formed, is non-conforming, or violates other constraints MUST be rejected.

registry

Any duplicate variant labels encountered MUST be treated as an error. Conditional variants where more than one context condition is simultaneously met for the same mapping also produce duplicate variant labels and MUST be treated as errors.

Code points MUST be represented in uppercase hexadecimal and zero-padded to a minimum of 4 digits, without the 'U+' prefix.

If a program using an LGR encounters a Unicode property that it does not support, it MUST abort with an error.

It is explicitly not possible to define recursive rules or class definitions. A reference to a named rule or class for which the complete definition has not yet been seen is an error.

Rules containing an 'anchor' element MUST only be invoked via the 'when' or 'not-when' attributes on code points or variants; they cannot be used as standalone whole-label rules.

The 'meta' element SHOULD be included so that associated metadata are available as part of the LGR and cannot become disassociated from it.

The 'when' and 'not-when' attributes are mutually exclusive; a 'var' element MUST NOT contain multiple conditions (only a single 'when' or 'not-when' is allowed).

Whenever an LGR depends on Unicode character properties, the unicode-version used in creating the LGR MUST be listed. If software does not have access to character property data of the requisite version, it MUST NOT perform any whole-label evaluation relying on Unicode character properties.

XML element names MUST be in lowercase as described in this specification, and matching of attribute values is only performed in a case-sensitive manner.

Character classes can be defined four ways: tag-based ('from-tag'), Unicode property-based ('property'), explicit code point list, or as set combinations (complement, union, intersection, difference, symmetric-difference). Named classes are referenced via an empty 'class' element with 'by-ref'.

Parameterized context rules use the 'anchor' element as a placeholder for the triggering code point, combined with 'look-behind' and 'look-ahead' elements to specify the surrounding context. This enables position-sensitive variant or eligibility conditions.

The 'action' element assigns a disposition to a label triggered by a rule match ('match' attribute) or non-match ('not-match' attribute), or by variant type qualifiers ('any-variant', 'all-variants', 'only-variants'). Actions are evaluated in document order and the first matching action wins.

The 'char' element declares a permissible code point or code point sequence using the 'cp' attribute in hexadecimal. Optional child 'var' elements specify variant mappings. Optional 'when'/'not-when' attributes reference context rules for conditional inclusion.

The 'var' element, nested inside a 'char' element, specifies a variant mapping using the 'cp' attribute as the target. An optional 'type' attribute tags the variant for use by action elements in determining label disposition.

IANA created a new 'Label Generation Ruleset Disposition Values' registry. Predefined values include 'allocatable', 'activate', 'blocked', and 'invalid'. New values require Expert Review and must be registered with a description and reference.

registry

IANA registered the media type 'application/lgr+xml' for LGR documents. The registration includes a structured syntax suffix '+xml' and references RFC 7940.

registry

IANA registered the URN namespace 'urn:ietf:params:xml:ns:lgr-1.0' in the IETF XML registry to identify the LGR XML namespace.

registry

Evaluating complex LGRs with large numbers of variant mappings or intricate rules can be computationally expensive. An attacker supplying or requesting evaluation of such labels could cause denial-of-service conditions.

security

LGRs address only part of the problem space for confusable labels. They do not prevent all forms of homograph or look-alike label attacks, particularly those arising from cross-script similarities or labels not included in the same registry.

security

Label processing proceeds in three steps: (1) determine eligibility by checking each code point against the repertoire and context rules; (2) generate all variant labels by permuting variant mappings; (3) determine disposition for each label/variant via action evaluation. Duplicate variant labels trigger an error state.

The 'count' attribute on match operators specifies repetition: 'n' for exact count, 'n+' for at least n, 'n:m' for a range. Absent 'count' means exactly once. Greedy matching is used as in regular expressions.

The LGR XML namespace URI is 'urn:ietf:params:xml:ns:lgr-1.0'. The root element is 'lgr' with this namespace declared. Code point values in 'cp', 'first-cp', and 'last-cp' attributes are uppercase hexadecimal integers, zero-padded to at least 4 digits.