7.  The "action" Element

   The purpose of an action is to assign a disposition to a label in
   response to being triggered by the label meeting a specified
   condition.  Often, the action simply results in blocking or
   invalidating a label that does not match a rule.  An example of an
   action invalidating a label because it does not match a rule named
   "leading-letter" is as follows:

       <action disp="invalid" not-match="leading-letter"/>

   If an action is to be triggered on matching a rule, a "match"
   attribute is used instead.  Actions are evaluated in the order that
   they appear in the XML file.  Once an action is triggered by a label,
   the disposition defined in the "disp" attribute is assigned to the
   label and no other actions are evaluated for that label.

   The goal of the LGR is to identify all labels and variant labels and
   to assign them disposition values.  These dispositions are then fed
   into a further process that ultimately implements all aspects of
   policy.  To allow this specification to be used with the widest range

   of policies, the permissible values for the "disp" attribute are
   neither defined nor restricted.  Nevertheless, a set of commonly used
   disposition values is RECOMMENDED.  (See Section 7.3.)

7.1.  The "match" and "not-match" Attributes

   An OPTIONAL "match" or "not-match" attribute specifies a rule that
   must be matched or not matched as a condition for triggering an
   action.  Only a single rule may be named as the value of a "match" or
   "not-match" attribute.  Because rules may be composed of other rules,
   this restriction to a single attribute value does not impose any
   limitation on the contexts that can trigger an action.

   An action MUST NOT contain both a "match" and a "not-match"
   attribute, and the value of either attribute MUST be the name of a
   previously defined rule; otherwise, the document MUST be rejected.
   An action without any attributes is triggered by all labels
   unconditionally.  For a very simple LGR, the following action would
   allocate all labels that match the repertoire:

       <action disp="allocatable" />

   Since rules are evaluated for all labels, whether they are the
   original label or computed by permuting the defined and valid variant
   mappings for the label's code points, actions based on matching or
   not matching a rule may be triggered for both original and variant
   labels, but the rules are not affected by the disposition attributes
   of the variant mappings.  To trigger any actions based on these
   dispositions requires the use of additional optional attributes for
   actions described next.

7.2.  Actions with Variant Type Triggers

7.2.1.  The "any-variant", "all-variants", and "only-variants"
        Attributes

   An action may contain one of the OPTIONAL attributes "any-variant",
   "all-variants", or "only-variants" defining triggers based on variant
   types.  The permitted value for these attributes consists of one or
   more variant type values, separated by spaces.  These MAY include
   type values that are not used in any "var" element in the LGR.  When
   a variant label is generated, these variant type values are compared
   to the set of type values on the variant mappings used to generate
   the particular variant label (see Section 8).

   Any single match may trigger an action that contains an "any-variant"
   attribute, while for an "all-variants" or "only-variants" attribute,
   the variant type for all variant code points must match one or

   several of the type values specified in the attribute to trigger the
   action.  There is no requirement that the entire list of variant type
   values be matched, as long as all variant code points match at least
   one of the values.

   An "only-variants" attribute will trigger the action only if all code
   points of the variant label have variant mappings from the original
   code points.  In other words, the label contains no original code
   points other than those with a reflexive mapping (see Section 5.3.4).

       <char cp="0078" comment="x">
           <var cp="0078" type="allocatable" comment="reflexive" />
           <var cp="0079" type="blocked" />
       </char>
       <char cp="0079" comment="y">
           <var cp="0078" type="allocatable" />
       </char>
       ...
       <action disp="blocked" any-variant="blocked" />
       <action disp="allocatable" only-variants="allocatable" />
       <action disp="some-disp" any-variant="allocatable" />

   In the example above, the label "xx" would have variant labels "xx",
   "xy", "yx", and "yy".  The first action would result in blocking any
   variant label containing "y", because the variant mapping from "x" to
   "y" is of type "blocked", triggering the "any-variant" condition.
   Because in this example "x" has a reflexive variant mapping to itself
   of type "allocatable", the original label "xx" has a reflexive
   variant "xx" that would trigger the "only-variants" condition on the
   second action.

   A label "yy" would have the variants "xy", "yx", and "xx".  Because
   the variant mapping from "y" to "x" is of type "allocatable" and a
   mapping from "y" to "y" is not defined, the labels "xy" and "yx"
   trigger the "any-variant" condition on the third label.  The variant
   "xx", being generated using the mapping from "y" to "x" of type
   "allocatable", would trigger the "only-variants" condition on the
   section action.  As there is no reflexive variant "yy", the original
   label "yy" cannot trigger any variant type triggers.  However, it
   could still trigger an action defined as matching or not matching
   a rule.

   In each action, one variant type trigger may be present by itself or
   in conjunction with an attribute matching or not matching a rule.  If
   variant triggers and rule-matching triggers are used together, the
   label MUST "match" or respectively "not-match" the specified rule AND
   satisfy the conditions on the variant type values given by the
   "any-variant", "all-variants", or "only-variants" attribute.

   A useful convention combines the "any-variant" trigger with reflexive
   variant mappings (Section 5.3.4).  This convention is used, for
   example, when multiple LGRs are defined within the same registry and
   for overlapping repertoire.  In some cases, the delegation of a label
   from one LGR must prohibit the delegation of another label in some
   other LGR.  This can be done using a variant of type "blocked" as in
   this example from an Armenian LGR, where the Armenian, Latin, and
   Cyrillic letters all look identical:

       <char cp="0570" comment="ARMENIAN SMALL LETTER HO">
         <var cp="0068" type="blocked" comment="LATIN SMALL LETTER H" />
         <var cp="04BB" type="blocked"
              comment="CYRILLIC SMALL LETTER SHHA" />
       </char>

   The issue is that the target code points for these two variants are
   both outside the Armenian repertoire.  By using a reflexive variant
   with the following convention:

       <char cp="0068" comment="not part of repertoire">
         <var cp="0068" type="out-of-repertoire-var"
              comment="reflexive mapping" />
         <var cp="04BB" type="blocked" />
         <var cp="0570" type="blocked" />
       </char>
         ...

   and associating this with an action of the form:

       <action disp="invalid" any-variant="out-of-repertoire-var" />

   it is possible to list the symmetric and transitive variant mappings
   in the LGR even where they involve out-of-repertoire code points.  By
   associating the action shown with the special type for these
   reflexive mappings, any original labels containing one or more of the
   out-of-repertoire code points are filtered out, just as if these code
   points had not been listed in the LGR in the first place.
   Nevertheless, they do participate in the permutation of variant
   labels for n-repertoire labels (Armenian in the example), and these
   permuted variants can be used to detect collisions with out-of-
   repertoire labels (see Section 8).

7.2.2.  Example from Tables in the Style of RFC 3743

   This section gives an example of using variant type triggers,
   combined with variants with reflexive mappings (Section 5.3.4), to
   achieve LGRs that implement tables like those defined according to
   [RFC3743] where the goal is to allow as variants only labels that
   consist entirely of simplified or traditional variants, in addition
   to the original label.

   This example assumes an LGR where all variants have been given
   suitable "type" attributes of "blocked", "simplified", "traditional",
   or "both", similar to the ones discussed in Appendix B.  Given such
   an LGR, the following example actions evaluate the disposition for
   the variant label:

       <action disp="blocked" any-variant="blocked" />
       <action disp="allocatable" only-variants="simplified both" />
       <action disp="allocatable" only-variants="traditional both" />
       <action disp="blocked" all-variants="simplified traditional" />
       <action disp="allocatable" />

   The first action matches any variant label for which at least one of
   the code point variants is of type "blocked".  The second matches any
   variant label for which all of the code point variants are of type
   "simplified" or "both" -- in other words, an all-simplified label.
   The third matches any label for which all variants are of type
   "traditional" or "both" -- that is, all traditional.  These two
   actions are not triggered by any variant labels containing some
   original code points, unless each of those code points has a variant
   defined with a reflexive mapping (Section 5.3.4).

   The final two actions rely on the fact that actions are evaluated in
   sequence and that the first action triggered also defines the final
   disposition for a variant label (see Section 7.4).  They further rely
   on the assumption that the only variants with type "both" are also
   reflexive variants.

   Given these assumptions, any remaining simplified or traditional
   variants must then be part of a mixed label and so are blocked; all
   labels surviving to the last action are original code points only
   (that is, the original label).  The example assumes that an original
   label may be a mixed label; if that is not the case, the disposition
   for the last action would be set to "blocked".

   There are exceptions where the assumption on reflexive mappings made
   above does not hold, so this basic scheme needs some refinements to
   cover all cases.  For a more complete example, see Appendix B.

7.3.  Recommended Disposition Values

   The precise nature of the policy action taken in response to a
   disposition and the name of the corresponding "disp" attributes are
   only partially defined here.  It is strongly RECOMMENDED to use the
   following dispositions only in their conventional sense.

   invalid  The resulting string is not a valid label.  This disposition
        may be assigned implicitly; see Section 7.5.  No variant labels
        should be generated from a variant mapping with this type.

   blocked  The resulting string is a valid label but should be blocked
        from registration.  This would typically apply for a derived
        variant that is undesirable due to having no practical use or
        being confusingly similar to some other label.

   allocatable  The resulting string should be reserved for use by the
        same operator of the origin string but not automatically
        allocated for use.

   activated  The resulting string should be activated for use.  (This
        is the same as a Preferred Variant [RFC3743].)

   valid  The resultant string is a valid label.  (This is the typical
        default action if no dispositions are defined.)

7.4.  Precedence

   Actions are applied in the order of their appearance in the file.
   This defines their relative precedence.  The first action triggered
   by a label defines the disposition for that label.  To define the
   order of precedence, list the actions in the desired order.  The
   conventional order of precedence for the actions defined in
   Section 7.3 is "invalid", "blocked", "allocatable", "activated", and
   then "valid".  This default precedence is used for the default
   actions defined in Section 7.6.

7.5.  Implied Actions

   The context rules on code points ("not-when" or "when" rules) carry
   an implied action with a disposition of "invalid" (not eligible) if a
   "when" context is not satisfied or a "not-when" context is matched,
   respectively.  These rules are evaluated at the time the code points
   for a label or its variant labels are checked for validity (see
   Section 8).  In other words, they are evaluated before any of the
   actions are applied, and with higher precedence.  The context rules
   for variant mappings are evaluated when variants are generated and/or
   when variant tables are made symmetric and transitive.  They have an

   implied action with a disposition of "invalid", which means that a
   putative variant mapping does not exist whenever the given context
   matches a "not-when" rule or fails to match a "when" rule specified
   for that mapping.  The result of that disposition is that the variant
   mapping is ignored in generating variant labels and the value is
   therefore not accessible to trigger any explicit actions.

   Note that such non-existing variant mapping is different from a
   blocked variant, which is a variant code point mapping that exists
   but results in a label that may not be allocated.

7.6.  Default Actions

   If a label does not trigger any of the actions defined explicitly in
   the LGR, the following implicitly defined default actions are
   evaluated.  They are shown below in their relative order of
   precedence (see Section 7.4).  Default actions have a lower order of
   precedence than explicit actions (see Section 8.3).

   The default actions for variant labels are defined as follows.  The
   first set is triggered based on the standard variant type values of
   "invalid", "blocked", "allocatable", and "activated":

       <action disp="invalid" any-variant="invalid"/>
       <action disp="blocked" any-variant="blocked"/>
       <action disp="allocatable" any-variant="allocatable"/>
       <action disp="activated" all-variants="activated"/>

   A final default action sets the disposition to "valid" for any label
   matching the repertoire for which no other action has been triggered.
   This "catch-all" action also matches all remaining variant labels
   from variants that do not have a type value.

       <action disp="valid" comment="Catch-all if other rules not met"/>

   Conceptually, the implicitly defined default actions act just like a
   block of "action" elements that is added (virtually) beyond the last
   of the user-supplied actions.  Any label not processed by the
   user-supplied actions would thus be processed by the default actions
   as if they were present in the LGR.  As the last default action is a
   "catch-all", all processing is guaranteed to end with a definite
   disposition for the label.

8.  Processing a Label against an LGR

8.1.  Determining Eligibility for a Label

   In order to test a given label for membership in the LGR, a consumer
   of the LGR must iterate through each code point within a given label
   and test that each instance of a code point is a member of the LGR.
   If any instance of a code point is not a member of the LGR, the label
   shall be deemed invalid.

   An individual instance of a code point is deemed a member of the LGR
   when it is listed using a "char" element, or is part of a range
   defined with a "range" element, and all necessary conditions in any
   "when" or "not-when" attributes are correctly satisfied for that
   instance.

   Alternatively, an instance of a code point is also deemed a member of
   the LGR when it forms part of a sequence that corresponds to a
   sequence listed using a "char" element for which the "cp" attribute
   defines a sequence, and all necessary conditions in any "when" or
   "not-when" attributes are correctly satisfied for that instance of
   the sequence.

   In determining eligibility, at each position the longest possible
   sequence of code points is evaluated first.  If that sequence matches
   a sequence defined in the LGR and satisfies any required context at
   that position, the instances of its constituent code points are
   deemed members of the LGR and evaluation proceeds with the next code
   point following the sequence.  If the sequence does not match a
   defined sequence or does not satisfy the required context,
   successively shorter sequences are evaluated until only a single code
   point remains.  The eligibility of that code point is determined as
   described above for an individual code point instance.

   A label must also not trigger any action that results in a
   disposition of "invalid"; otherwise, it is deemed not eligible.
   (This step may need to be deferred until variant code point
   dispositions have been determined.)

8.1.1.  Determining Eligibility Using Reflexive Variant Mappings

   For LGRs that contain reflexive variant mappings (defined in
   Section 5.3.4), the final evaluation of eligibility for the label
   must be deferred until variants are generated.  In essence, LGRs that
   use this feature treat the original label as the (identity) variant
   of itself.  For such LGRs, the ordinary determination of eligibility
   described here is but a first step that generally excludes only a
   subset of invalid labels.

   To further check the validity of a label with reflexive mappings, it
   is not necessary to generate all variant labels.  Only a single
   variant needs to be created, where any reflexive variants are applied
   for each code point, and the label disposition is evaluated (as
   described in Section 8.3).  A disposition of "invalid" results in the
   label being not eligible.  (In the exceptional case where context
   rules are present on reflexive mappings, multiple reflexive variants
   may be defined, but for each original label, at most one of these can
   be valid at each code position.  However, see Section 8.4.)

8.2.  Determining Variants for a Label

   For a given eligible label, the set of variant labels is deemed to
   consist of each possible permutation of original code points and
   substituted code points or sequences defined in "var" elements,
   whereby all "when" and "not-when" attributes are correctly satisfied
   for each "char" or "var" element in the given permutation and all
   applicable whole label rules are satisfied as follows:

   1.  Create each possible permutation of a label by substituting each
       code point or code point sequence in turn by any defined variant
       mapping (including any reflexive mappings).

   2.  Apply variant mappings with "when" or "not-when" attributes only
       if the conditions are satisfied; otherwise, they are not defined.

   3.  Record each of the "type" values on the variant mappings used in
       creating a given variant label in a disposition set; for any
       unmapped code point, record the "type" value of any reflexive
       variant (see Section 5.3.4).

   4.  Determine the disposition for each variant label per Section 8.3.

   5.  If the disposition is "invalid", remove the label from the set.

   6.  If final evaluation of the disposition for the unpermuted label
       per Section 8.3 results in a disposition of "invalid", remove all
       associated variant labels from the set.

   The number of potential permutations can be very large.  In practice,
   implementations would use suitable optimizations to avoid having to
   actually create all permutations (see Section 8.5).

   In determining the permuted set of variant labels in step (1) above,
   all eligible partitions into sequences must be evaluated.  A label
   "ab" that matches a sequence "ab" defined in the LGR but also matches

   the sequence of individual code points "a" and "b" (both defined in
   the LGR) must be permuted using any defined variant mappings for both
   the sequence "ab" and the code points "a" and "b" individually.

8.3.  Determining a Disposition for a Label or Variant Label

   For a given label (variant or original), its disposition is
   determined by evaluating, in order of their appearance, all actions
   for which the label or variant label satisfies the conditions.

   1.  For any label that contains code points or sequences not defined
       in the repertoire, or does not satisfy the context rules on all
       of its code points and variants, the disposition is "invalid".

   2.  For all other labels, the disposition is given by the value of
       the "disp" attribute for the first action triggered by the label.
       An action is triggered if all of the following are true:

       *  the label matches the whole label rule given in the "match"
          attribute for that action;

       *  the label does not match the whole label rule given in the
          "not-match" attribute for that action;

       *  any of the recorded variant types for a variant label match
          the types given in the "any-variant" attribute for that
          action;

       *  all of the recorded variant types for a variant label match
          the types given in the "all-variants" or "only-variants"
          attribute given for that action;

       *  in case of an "only-variants" attribute, the label contains
          only code points that are the target of applied variant
          mappings;

       or

       *  the action does not contain any "match", "not-match",
          "any-variant", "all-variants", or "only-variants" attributes:
          catch-all.

   3.  For any remaining variant label, assign the variant label the
       disposition using the default actions defined in Section 7.6.
       For this step, variant types outside the predefined recommended
       set (see Section 7.3) are ignored.

   4.  For any remaining label, set the disposition to "valid".

8.4.  Duplicate Variant Labels

   For a poorly designed LGR, it is possible to generate duplicate
   variant labels from the same input label, but with different, and
   potentially conflicting, dispositions.  Implementations MUST treat
   any duplicate variant labels encountered as an error, irrespective of
   their dispositions.

   This situation can arise in two ways.  One is described in
   Section 5.3.5 and involves defining the same variant mapping with two
   context rules that are formally distinct but nevertheless overlap so
   that they are not mutually exclusive for the same label.

   The other case involves variants defined for sequences, where one
   sequence is a prefix of another (see Section 5.3.1).  The following
   shows such an example resulting in conflicting reflexive variants:

       <char cp="0061">
         <var cp="0061" type="allocatable"/>
       </char>
       <char cp="0062"/>
       <char cp="0061 0062">
         <var cp="0061 0062" type="blocked"/>
       </char>

   A label "ab" would generate the variant labels "{a}{b}" and "{ab}"
   where the curly braces show the sequence boundaries as they were
   applied during variant mapping.  The result is a duplicate variant
   label "ab", one based on a variant of type "allocatable" plus an
   original code point "b" that has no variant, and another one based on
   a single variant of type "blocked", thus creating two variant labels
   with conflicting dispositions.

   In the general case, it is difficult to impossible to prove by
   mechanical inspection of the LGR that duplicate variant labels will
   never occur, so implementations have to be prepared to detect this
   error during variant label generation.  The condition is easily
   avoided by careful design of context rules and special attention to
   the relation among code point sequences with variants.

8.5.  Checking Labels for Collision

   The obvious method for checking for collision between labels is to
   generate the fully permuted set of variants for one of them and see
   whether it contains the other label as a member.  As discussed above,
   this can be prohibitive and is not necessary.

   Because of symmetry and transitivity, all variant mappings form
   disjoint sets.  In each of these sets, the source and target of each
   mapping are also variants of the sources and targets of all the other
   mappings.  However, members of two different sets are never variants
   of each other.

   If two labels have code points at the same position that are members
   of two different variant mapping sets, any variant labels of one
   cannot be variant labels of the other: the sets of their variant
   labels are likewise disjoint.  Instead of generating all permutations
   to compare all possible variants, it is enough to find out whether
   code points at the same position belong to the same variant set
   or not.

   For that, it is sufficient to substitute an "index" mapping that
   identifies the set.  This index mapping could be, for example, the
   variant mapping for which the target code point (or sequence) comes
   first in some sorting order.  This index mapping would, in effect,
   identify the set of variant mappings for that position.

   To check for collision then means generating a single variant label
   from the original by substituting the respective "index" value for
   each code point.  This results in an "index label".  Two labels
   collide whenever the index labels for them are the same.

9.  Conversion to and from Other Formats

   Both [RFC3743] and [RFC4290] provide different grammars for IDN
   tables.  The formats in those documents are unable to fully support
   the increased requirements of contemporary IDN variant policies.

   This specification is a superset of functionality provided by the
   older IDN table formats; thus, any table expressed in those formats
   can be expressed in this new format.  Automated conversion can be
   conducted between tables conformant with the grammar specified in
   each document.

   For notes on how to translate a table in the style of RFC 3743, see
   Appendix B.

10.  Media Type

   Well-formed LGRs that comply with this specification SHOULD be
   transmitted with a media type of "application/lgr+xml".  This media
   type will signal to an LGR-aware client that the content is designed
   to be interpreted as an LGR.

11.  IANA Considerations

   IANA has completed the following actions:

11.1.  Media Type Registration

   The media type "application/lgr+xml" has been registered to denote
   transmission of LGRs that are compliant with this specification, in
   accordance with [RFC6838].

   Type name: application

   Subtype name: lgr+xml

   Required parameters: N/A

   Optional parameters: charset (as for application/xml per [RFC7303])

   Security considerations:  See the security considerations for
      application/xml in [RFC7303] and the specific security
      considerations for Label Generation Rulesets (LGRs) in RFC 7940

   Interoperability considerations:  As for application/xml per
      [RFC7303]

   Published specification:  See RFC 7940

   Applications that use this media type:  Software using LGRs for
      international identifiers, such as IDNs, including registry
      applications and client validators.

   Additional information:

      Deprecated alias names for this type: N/A

      Magic number(s): N/A

      File extension(s): .lgr

      Macintosh file type code(s): N/A

   Person & email address to contact for further information:

      Kim Davies <kim.davies@icann.org>

      Asmus Freytag <asmus@unicode.org>

   Intended usage: COMMON

   Restrictions on usage: N/A

   Author:

      Kim Davies <kim.davies@icann.org>

      Asmus Freytag <asmus@unicode.org>

   Change controller: IESG

   Provisional registration? (standards tree only): No

11.2.  URN Registration

   This specification uses a URN to describe the XML namespace, in
   accordance with [RFC3688].

   URI: urn:ietf:params:xml:ns:lgr-1.0

   Registrant Contact: See the Authors of this document.

   XML: None.

11.3.  Disposition Registry

   This document establishes a vocabulary of "Label Generation Ruleset
   Dispositions", which has been reflected as a new IANA registry.  This
   registry is divided into two subregistries:

   o  Standard Dispositions - This registry lists dispositions that have
      been defined in published specifications, i.e., the eligibility
      for such registrations is "Specification Required" [RFC5226].  The
      initial set of registrations are the five dispositions in this
      document described in Section 7.3.

   o  Private Dispositions - This registry lists dispositions that have
      been registered "First Come First Served" [RFC5226] by third
      parties with the IANA.  Such dispositions must take the form
      "entity:disposition" where the entity is a domain name that
      uniquely identifies the private user of the namespace.  For
      example, "example.org:reserved" could be a private extension used
      by the example organization to denote a disposition relating to
      reserved labels.  These extensions are not intended to be
      interoperable, but registration is designed to minimize potential
      conflicts.  It is strongly recommended that any new dispositions
      that require interoperability and have applicability beyond a
      single organization be defined as Standard Dispositions.

   In order to distinguish them from Private Dispositions, Standard
   Dispositions MUST NOT contain the ":" character.  All disposition
   names shall be in lowercase ASCII.

   The IANA registry provides data on the name of the disposition, the
   intended purposes, and the registrant or defining specification for
   the disposition.

12.  Security Considerations

12.1.  LGRs Are Only a Partial Remedy for Problem Space

   Substantially unrestricted use of non-ASCII characters in security-
   relevant identifiers such as domain name labels may cause user
   confusion and invite various types of attacks.  In many languages, in
   particular those using complex or large scripts, an attacker has an
   opportunity to divert or confuse users as a result of different code
   points with identical appearance or similar semantics.

   The use of an LGR provides a partial remedy for these risks by
   supplying a framework for prohibiting inappropriate code points or
   sequences from being registered at all and for permitting "variant"
   code points to be grouped together so that labels containing them may
   be mutually exclusive or registered only to the same owner.

   In addition, by being fully machine processable the format may enable
   automated checks for known weaknesses in label generation rules.
   However, the use of this format, or compliance with this
   specification, by itself does not ensure that the LGRs expressed in
   this format are free of risk.  Additional approaches may be
   considered, depending on the acceptable trade-off between flexibility
   and risk for a given application.  One method of managing risk may
   involve a case-by-case evaluation of a proposed label in context with
   already-registered labels -- for example, when reviewing labels for
   their degree of visual confusability.

12.2.  Computational Expense of Complex Tables

   A naive implementation attempting to generate all variant labels for
   a given label could lead to the possibility of exhausting the
   resources on the machine running the LGR processor, potentially
   causing denial-of-service consequences.  For many operations,
   brute-force generation can be avoided by optimization, and if needed,
   the number of permuted labels can be estimated more cheaply ahead
   of time.

   The implementation of WLE rules, using certain backtracking
   algorithms, can take exponential time for pathological rules or
   labels and exhaust stack resources.  This can be mitigated by
   proper implementation and enforcing the restrictions on permissible
   label length.

13.  References

13.1.  Normative References

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <http://www.rfc-editor.org/info/rfc2045>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3339]  Klyne, G. and C. Newman, "Date and Time on the Internet:
              Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
              <http://www.rfc-editor.org/info/rfc3339>.

   [RFC5646]  Phillips, A., Ed., and M. Davis, Ed., "Tags for
              Identifying Languages", BCP 47, RFC 5646,
              DOI 10.17487/RFC5646, September 2009,
              <http://www.rfc-editor.org/info/rfc5646>.

   [UAX42]    The Unicode Consortium, "Unicode Character Database in
              XML", May 2016, <http://unicode.org/reports/tr42/>.

   [Unicode-Stability]
              The Unicode Consortium, "Unicode Encoding Stability
              Policy, Property Value Stability", April 2015,
              <http://www.unicode.org/policies/
              stability_policy.html#Property_Value>.

   [Unicode-Versions]
              The Unicode Consortium, "Unicode Version Numbering",
              June 2016,
              <http://unicode.org/versions/#Version_Numbering>.

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium, November 2008,
              <http://www.w3.org/TR/REC-xml/>.

13.2.  Informative References

   [ASIA-TABLE]
              DotAsia Organisation, ".ASIA ZH IDN Language Table",
              February 2012,
              <http://www.dot.asia/policies/ASIA-ZH-1.2.pdf>.

   [LGR-PROCEDURE]
              Internet Corporation for Assigned Names and Numbers,
              "Procedure to Develop and Maintain the Label Generation
              Rules for the Root Zone in Respect of IDNA Labels",
              December 2012, <http://www.icann.org/en/resources/idn/
              draft-lgr-procedure-07dec12-en.pdf>.

   [RELAX-NG] The Organization for the Advancement of Structured
              Information Standards (OASIS), "RELAX NG Compact Syntax",
              November 2002, <https://www.oasis-open.org/committees/
              relax-ng/compact-20021121.html>.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              DOI 10.17487/RFC3688, January 2004,
              <http://www.rfc-editor.org/info/rfc3688>.

   [RFC3743]  Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint
              Engineering Team (JET) Guidelines for Internationalized
              Domain Names (IDN) Registration and Administration for
              Chinese, Japanese, and Korean", RFC 3743,
              DOI 10.17487/RFC3743, April 2004,
              <http://www.rfc-editor.org/info/rfc3743>.

   [RFC4290]  Klensin, J., "Suggested Practices for Registration of
              Internationalized Domain Names (IDN)", RFC 4290,
              DOI 10.17487/RFC4290, December 2005,
              <http://www.rfc-editor.org/info/rfc4290>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5564]  El-Sherbiny, A., Farah, M., Oueichek, I., and A. Al-Zoman,
              "Linguistic Guidelines for the Use of the Arabic Language
              in Internet Domains", RFC 5564, DOI 10.17487/RFC5564,
              February 2010, <http://www.rfc-editor.org/info/rfc5564>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <http://www.rfc-editor.org/info/rfc5891>.

   [RFC5892]  Faltstrom, P., Ed., "The Unicode Code Points and
              Internationalized Domain Names for Applications (IDNA)",
              RFC 5892, DOI 10.17487/RFC5892, August 2010,
              <http://www.rfc-editor.org/info/rfc5892>.

   [RFC6838]  Freed, N., Klensin, J., and T. Hansen, "Media Type
              Specifications and Registration Procedures", BCP 13,
              RFC 6838, DOI 10.17487/RFC6838, January 2013,
              <http://www.rfc-editor.org/info/rfc6838>.

   [RFC7303]  Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
              DOI 10.17487/RFC7303, July 2014,
              <http://www.rfc-editor.org/info/rfc7303>.

   [TDIL-HINDI]
              Technology Development for Indian Languages (TDIL)
              Programme, "Devanagari Script Behaviour for Hindi Ver2.0",
              <http://tdil-dc.in/index.php?option=com_download&task=show
              resourceDetails&toolid=1625&lang=en>.

   [UAX44]    The Unicode Consortium, "Unicode Character Database",
              June 2016, <http://unicode.org/reports/tr44/>.

   [WLE-RULES]
              Internet Corporation for Assigned Names and Numbers,
              "Whole Label Evaluation (WLE) Rules", August 2016,
              <https://community.icann.org/download/
              attachments/43989034/WLE-Rules.pdf>.

Appendix A.  Example Tables

   The following presents a minimal LGR table defining the lowercase LDH
   (letters, digits, hyphen) repertoire and containing no rules or
   metadata elements.  Many simple LGR tables will look quite similar,
   except that they would contain some metadata.

   <?xml version="1.0" encoding="utf-8"?>
   <lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
   <data>
       <char cp="002D" comment="HYPHEN (-)" />
       <range first-cp="0030" last-cp="0039"
         comment="DIGIT ZERO - DIGIT NINE" />
       <range first-cp="0061" last-cp="007A"
         comment="LATIN SMALL LETTER A - LATIN SMALL LETTER Z" />
   </data>
   </lgr>

   In practice, any LGR that includes the hyphen might also contain
   rules invalidating any labels beginning with a hyphen, ending with a
   hyphen, and containing consecutive hyphens in the third and fourth
   positions as required by [RFC5891].

   <?xml version="1.0" encoding="utf-8"?>
   <lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
   <data>
       <char cp="002D"
             not-when="hyphen-minus-disallowed" />
       <range first-cp="0030" last-cp="0039" />
       <range first-cp="0061" last-cp="007A" />
   </data>
   <rules>
       <rule name="hyphen-minus-disallowed"
             comment="RFC5891 restrictions on U+002D">
         <choice>
           <rule comment="no leading hyphen">
             <look-behind>
               <start />
             </look-behind>
             <anchor />
           </rule>
           <rule comment="no trailing hyphen">
             <anchor />
             <look-ahead>
               <end />
             </look-ahead>
           </rule>

           <rule comment="no consecutive hyphens
                   in third and fourth positions">
             <look-behind>
               <start />
               <any />
               <any />
               <char cp="002D" comment="hyphen-minus" />
             </look-behind>
             <anchor />
           </rule>
         </choice>
       </rule>
   </rules>
   </lgr>

   The following sample LGR shows a more complete collection of the
   elements and attributes defined in this specification in a somewhat
   typical context.

   <?xml version="1.0" encoding="utf-8"?>

   <!-- This example uses a large subset of the features of this
        specification.  It does not include every set operator,
        match operator element, or action trigger attribute, their
        use being largely parallel to the ones demonstrated. -->

   <lgr xmlns="urn:ietf:params:xml:ns:lgr-1.0">
   <!-- meta element with all optional elements -->
   <meta>
       <version comment="initial version">1</version>
       <date>2010-01-01</date>
       <language>sv</language>
       <scope type="domain">example.com</scope>
       <validity-start>2010-01-01</validity-start>
       <validity-end>2013-12-31</validity-end>
       <description type="text/html">
           <![CDATA[
           This language table was developed with the
           <a href="http://swedish.example/">Swedish
           examples institute</a>.
           ]]>
       </description>

       <unicode-version>6.3.0</unicode-version>
       <references>
         <reference id="0" comment="the most recent" >The
               Unicode Standard 9.0</reference>
         <reference id="1" >RFC 5892</reference>
         <reference id="2" >Big-5: Computer Chinese Glyph
            and Character Code Mapping Table, Technical Report
            C-26, 1984</reference>
       </references>
    </meta>

    <!-- the "data" section describing the repertoire -->
    <data>
       <!-- single code point "char" element -->
       <char cp="002D" ref="1" comment="HYPHEN" />

       <!-- "range" elements for contiguous code points, with tags -->
       <range first-cp="0030" last-cp="0039" ref="1" tag="digit" />
       <range first-cp="0061" last-cp="007A" ref ="1" tag="letter" />

       <!-- code point sequence -->
       <char cp="006C 00B7 006C" comment="Catalan middle dot" />

       <!-- alternatively, use a When Rule -->
       <char cp="00B7" when="catalan-middle-dot" />

        <!-- code point with context rule -->
       <char cp="200D" when="joiner" ref="2" />

       <!-- code points with variants -->
       <char cp="4E16" tag="preferred" ref="0">
         <var cp="4E17" type="blocked" ref="2" />
         <var cp="534B" type="allocatable" ref="2" />
       </char>
       <char cp="4E17" ref="0">
         <var cp="4E16" type="allocatable" ref="2" />
         <var cp="534B" type="allocatable" ref="2" />
       </char>
       <char cp="534B" ref="0">
         <var cp="4E16" type="allocatable" ref="2" />
         <var cp="4E17" type="blocked" ref="2" />
       </char>
     </data>

     <!-- Context and whole label rules -->
     <rules>
       <!-- Require the given code point to be between two 006C
            code points -->
       <rule name="catalan-middle-dot" ref="0">
           <look-behind>
               <char cp="006C" />
           </look-behind>
           <anchor />
           <look-ahead>
               <char cp="006C" />
           </look-ahead>
       </rule>

       <!-- example of a context rule based on property -->
       <class name="virama" property="ccc:9" />
       <rule name="joiner"  ref="1" >
           <look-behind>
               <class by-ref="virama" />
           </look-behind>
           <anchor />
       </rule>

       <!-- example of using set operators -->

       <!-- Subtract vowels from letters to get
            consonant, demonstrating the different
            set notations and the difference operator -->
        <difference name="consonants">
            <class comment="all letters">0061-007A</class>
            <class comment="all vowels">
                    0061 0065 0069 006F 0075
            </class>
        </difference>

        <!-- by using the start and end, rule matches whole label -->
        <rule name="three-or-more-consonants">
            <start />
            <!-- reference the class defined by the difference,
                 and require three or more matches -->
            <class by-ref="consonants" count="3+" />
            <end />
       </rule>

       <!-- rule for negative matching -->
       <rule name="non-preferred"
             comment="matches any non-preferred code point">
           <complement comment="non-preferred" >
               <class from-tag="preferred" />
           </complement>
       </rule>

      <!-- actions triggered by matching rules and/or
           variant types -->
       <action disp="invalid"
               match="three-or-more-consonants" />
       <action disp="blocked" any-variant="blocked" />
       <action disp="allocatable" all-variants="allocatable"
               not-match="non-preferred" />
     </rules>
   </lgr>