Representing Label Generation Rulesets using XML
draft-ietf-lager-specification-11

" />
       </char>
       <char cp="636E">
       <var cp="636E" type="simp" comment="reflexive, but not both" />
       <var cp="64DA" type="trad" />
       <var cp="62E0" type="blocked" />
       </char>
       <char cp="64DA">
       <var cp="636E" type="simp" />
       <var cp="64DA" type="trad" comment="reflexive" />
       <var cp="62E0" type="blocked" />
       </char>

   To make such variant sets work requires a way to selectively trigger
   an action based on whether a variant type is associated with an
   identity or reflexive mapping, or is associated with an ordinary
   variant mapping.  This can be done by adding a prefix "r-" to the
   "type" attribute on reflexive variant mappings.  For example the
   "trad" for code point U+64DA in the preceding figure would become
   "r-trad".

   With the dispositions prepared in this way, only a slight
   modification to the actions is needed to yield the correct set of
   allocatable labels:

   <action disp="blocked" any-variant="blocked" />
   <action disp="allocatable" only-variants="simp r-simp both r-both" />
   <action disp="allocatable" only-variants="trad r-trad both r-both" />
   <action disp="blocked" all-variants="simp trad both" />
   <action disp="allocatable" />

   The first three actions get triggered by the same labels as before.

   The fourth action blocks any label that combines an original code
   point with any mix of ordinary variant mappings; however no labels
   that are a combination of only original code points (code points
   having either no variant mappings or a reflexive mapping) would be

Davies & Freytag       Expires September 21, 2016              [Page 62]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   affected.  These are the original labels and they are allocated in
   the last action.

   Using this scheme of assigning types to ordinary and reflexive
   variants, all RFC 3743-style tables can be converted to XML.  By
   defining a set of actions as outlined above, the LGR will yield the
   correct set of allocatable variants: all variants consisting
   completely of variant code points preferred for simplified or
   traditional, respectively, will be allocated, as will be the original
   label.  All other variant labels will be blocked.

Appendix C.  Indic Syllable Structure Example

   In LGRs for Indic scripts it may be desirable to restrict valid
   labels to sequences of valid Indic syllables, or aksharas.  This
   appendix gives a sample set of rules designed to enforce this
   restriction.

   An example of a BNF from for an akshara which has been published in
   "Devanagari Script Behavior for Hindi" [TDIL-HINDI].  The rules for
   other languages and scripts used in India are expected to be
   generally similar.

   For Hindi, the BNF has the form:

       V[m]|{C[N]H}C[N](H|[v][m])

   Where:

   V    (upper case) is any independent vowel

   m    is any vowel modifier (Devanagari Anusvara, Visarga, and
        Candrabindu)

   C    is any consonant (with inherent vowel)

   N    is Nukta

   H    is a Halant (or Virama)

   v    (lower case) is any dependent vowel sign (matra)

   {}   encloses items which may be repeated one or more times

   [ ]  encloses items which may or may not be present

   |    separates items, out of which only one can be present

Davies & Freytag       Expires September 21, 2016              [Page 63]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   By using the Unicode character property "InSC" or
   "Indic_Syllabic_Category" which corresponds rather directly to the
   classification of characters in the BNF above, we can translate the
   BNF into a set of WLE rules matching the definition of an akshara.

    <rules>
       <!--Character Class Definitions go here-->
       <class name="halant" property="InSC:Virama" />
       <union name="vowel-modifier">
         <class property="InSC:Visarga" />
         <class property="InSC:Bindu" comment="includes anusvara" />
       </union>
       <!--Whole label evaluation and Context rules go here-->
       <rule name="consonant-with-optional-nukta">
           <class by-ref="InSC:Consonant" />
           <class by-ref="InSC:Nukta"  count="0:1"/>
       </rule>
       <rule name="independent-vowel-with-optional-modifier">
           <class by-ref="InSC:Vowel_Independent" />
           <class by-ref="vowel-modifier"  count="0:1" />
       </rule>
       <rule name="optional-dependent-vowel-with-opt-modifier" >
         <class by-ref="InSC:Vowel_Dependent" count="0:1" />
         <class by-ref="vowel-modifier" count="0:1"  />
       </rule>
       <rule name="consonant-cluster">
         <rule count="0+">
           <rule by-ref="consonant-with-optional-nukta" />
           <class by-ref="halant" />
         </rule>
         <rule by-ref="consonant-with-optional-nukta" />
         <choice>
           <class by-ref="halant" />
           <rule by-ref="optional-dependent-vowel-with-opt-modifier" />
         </choice>
       </rule>
       <rule name="akshara">
         <choice>
           <rule by-ref="independent-vowel-with-optional-modifier" />
           <rule by-ref="consonant-cluster" />
         </choice>
       </rule>
       <rule name="WLE-akshara-or-other" comment="series of one or
           more aksharas, possibly alternating with other types of
           code points such as digits">
         <start />
         <choice count="1+">
           <class property="InSC:other"  />

Davies & Freytag       Expires September 21, 2016              [Page 64]
Internet-Draft      Label Generation Rulesets in XML          March 2016

           <rule by-ref="akshara"  />
         </choice>
         <end />
       </rule>
       <!--Action elements go here - order defines precedence-->
       <action disp="invalid" not-match="WLE-akshara-or-other" />
     </rules>

   With the rules and classes as defined above, the final action assigns
   a disposition of "invalid" to all labels that are not composed of a
   sequence of well-formed aksharas, optionally interspersed with other
   characters, perhaps digits, for example.

   The relevant Unicode character property could be replicated by
   tagging repertoire values directly in the LGR which would remove the
   dependency on any specific version of the Unicode Standard.

   Generally, dependent vowels may only follow consonant expressions,
   however, for some scripts, like Bengali, the Unicode standard
   supports sequences of dependent vowels or their application on
   independent vowels.  This makes the definition of akshara less
   restrictive.

   It is possible to reduce the complexity of these rules by defining
   alternate rules which simply define the permissible pair-wise context
   of adjacent code points by character class--such as the rule that a
   Halant can only follow a (nuktated) consonant.  (See the example in
   [WLE-RULES]).

Appendix D.  RelaxNG Compact Schema

   <CODE BEGINS>
   #
   # LGR XML Schema 1.0
   #

   default namespace = "urn:ietf:params:xml:ns:lgr-1.0"

   #
   # SIMPLE TYPES
   #

   # RFC 5646 language tag (e.g. "de", "und-Latn", etc.)
   language-tag = xsd:token

   # The scope to which the LGR applies. For the "domain" scope type it
   # should be a fully qualified domain name.
   scope-value = xsd:token {

Davies & Freytag       Expires September 21, 2016              [Page 65]
Internet-Draft      Label Generation Rulesets in XML          March 2016

       minLength = "1"
   }

   ## a single code point
   code-point = xsd:token {
       pattern = "[0-9A-F]{4,6}"
   }

   ## a space-separated sequence of code points
   code-point-sequence = xsd:token {
       pattern = "[0-9A-F]{4,6}( [0-9A-F]{4,6})+"
   }

   ## single code point, or a sequence of code points, or empty string
   code-point-literal = code-point | code-point-sequence | ""

   ## code point or sequence only
   non-empty-code-point-literal = code-point | code-point-sequence

   ## code point sent represented in short form
   code-point-set-shorthand = xsd:token {
       pattern = "([0-9A-F]{4,6}|[0-9A-F]{4,6}-[0-9A-F]{4,6})"
                 ~ "( ([0-9A-F]{4,6}|[0-9A-F]{4,6}-[0-9A-F]{4,6}))*"
   }

   ## dates are used in information fields in the meta
   ## section ("YYYY-MM-DD")
   date-pattern = xsd:token {
       pattern = "\d{4}-\d\d-\d\d"
   }

   ## variant type
   ## the variant type MUST be non-emtpy and MUST NOT
   ## start with a "_", using xsd:NMTOKEN here because
   ## we need space-separated lists of them
   variant-type = xsd:NMTOKEN

   ## variant type list for action triggers
   ## the list MUST NOT be empty and entries MUST NOT
   ## start with a "_"
   variant-type-list = xsd:NMTOKENS

   ## reference to a rule name (used in "when" and "not-when"
   ## attributes, as well as the "by-ref" attribute of the "rule"
   ## element.)
   rule-ref = xsd:IDREF

   ## a space-separated list of tags. Tags should generally follow

Davies & Freytag       Expires September 21, 2016              [Page 66]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   ## xsd:Name syntax. However, we are using the xsd:NMTOKENS here
   ## because there is no native XSD datatype for space-separated
   ## xsd:Name
   tags = xsd:NMTOKENS

   ## The value space of a "from-tag" attribute. Although it is closer
   ## to xsd:IDREF lexically and semantically, tags are not unique in
   ## the document. As such, we are unable to take advantage of
   ## facilities provided by a validator. xsd:NMTOKEN is used instead of
   ## the stricter xsd:Names here so as to be consistent with the above.
   tag-ref = xsd:NMTOKEN

   ## an identifier type (used by "name" attributes).
   identifier = xsd:ID

   ## used in the class "by-ref" attribute to reference another class of
   ## the same "name" attribute value.
   class-ref = xsd:IDREF

   ## count attribute pattern ("n", "n+" or "n:m")
   count-pattern = xsd:token {
       pattern = "\d+(\+|:\d+)?"
   }

   ## ref attribute pattern
   ## space separated list of id attribute valiues for
   ## reference elements. These reference ids
   ## must be declared in a reference element
   ## before they can be used in a ref attribute
   ref-pattern = xsd:token {
       pattern = "[\-_.:0-9A-Z]+( [\-_.:0-9A-Z]+)*"
   }

   #
   # STRUCTURES
   #

   ## Representation of a single code point, or a sequence of code
   ## points
   char = element char {
       attribute cp { code-point-literal },
       attribute comment { text }?,
       attribute when { rule-ref }?,
       attribute not-when { rule-ref }?,
       attribute tag { tags }?,
       attribute ref { ref-pattern }?,
         variant*
   }

Davies & Freytag       Expires September 21, 2016              [Page 67]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   ## Representation of a range of code points
   range = element range {
       attribute first-cp { code-point },
       attribute last-cp { code-point },
       attribute comment { text }?,
       attribute when { rule-ref }?,
       attribute not-when { rule-ref }?,
       attribute tag { tags }?,
       attribute ref { ref-pattern }?
   }

   ## Representation of a variant code point or sequence
   variant = element var {
       attribute cp { code-point-literal },
       attribute type { xsd:NMTOKEN }?,
       attribute when { rule-ref }?,
       attribute not-when { rule-ref }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?
   }

   #
   # Classes
   #

   ## a "class" element that references the name of another "class"
   ## (or set-operator like "union") defined elsewhere.
   ## If used as a matcher (appearing under a "rule" element),
   ## the "count" attribute may be present.
   class-invocation = element class {
       attribute by-ref { class-ref },
       attribute count { count-pattern }?,
       attribute comment { text }?
   }

   ## defines a new class (set of code points) using Unicode property
   ## or code points of the same tag value or code point literals
   class-declaration = element class {
       # "name" attribute MUST be present if this is a "top-level"
       # class declaration, i.e. appearing directly under the "rules"
       # element. Otherwise, it MUST be absent.
       attribute name { identifier }?,
       # If used as a matcher (appearing in a "rule" element, but not
       # when nested inside a set operator or class), the "count"
       # attribute may be present. Otherwise, it MUST be absent.
       attribute count { count-pattern }?,

Davies & Freytag       Expires September 21, 2016              [Page 68]
Internet-Draft      Label Generation Rulesets in XML          March 2016

       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       (
         # define the class by property (e.g. property="sc:Latn"), OR
         attribute property { xsd:NMTOKEN }
         # define the class by tagged code points, OR
         | attribute from-tag { tag-ref }
         # text node to allow for shorthand notation
         # e.g. "0061 0062-0063"
         | code-point-set-shorthand
       )
     }

   class-or-set-operator-nested =
     class-invocation | class-declaration | set-operator

   class-or-set-operator-declaration =
     # a "class" element or set operator (effectively defining a class)
     # directly in the "rules" element.
     class-declaration | set-operator

   #
   # Set operators
   #

   complement-operator = element complement {
       attribute name { identifier }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # "count" attribute MUST only be used when this set-operator is
       # used as a matcher (i.e. nested in a <rule> element but not
       # inside a set-operator or class)
       attribute count { count-pattern }?,
       class-or-set-operator-nested
   }

   union-operator = element union {
       attribute name { identifier }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # "count" attribute MUST only be used when this set-operator is
       # used as a matcher (i.e. nested in a <rule> element but not
       # inside a set-operator or class)
       attribute count { count-pattern }?,
       class-or-set-operator-nested,
       # needs two or more child elements
       class-or-set-operator-nested+

Davies & Freytag       Expires September 21, 2016              [Page 69]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   }

   intersection-operator = element intersection {
       attribute name { identifier }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # "count" attribute MUST only be used when this set-operator is
       # used as a matcher (i.e. nested in a <rule> element but not
       # inside a set-operator or class)
       attribute count { count-pattern }?,
       class-or-set-operator-nested,
       class-or-set-operator-nested
   }

   difference-operator = element difference {
       attribute name { identifier }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # "count" attribute MUST only be used when this set-operator is
       # used as a matcher (i.e. nested in a <rule> element but not
       # inside a set-operator or class)
       attribute count { count-pattern }?,
       class-or-set-operator-nested,
       class-or-set-operator-nested
   }

   symmetric-difference-operator = element symmetric-difference {
       attribute name { identifier }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # "count" attribute MUST only be used when this set-operator is
       # used as a matcher (i.e. nested in a <rule> element but not
       # inside a set-operator or class)
       attribute count { count-pattern }?,
       class-or-set-operator-nested,
       class-or-set-operator-nested
   }

   ## operators that transform class(es) into a new class.
   set-operator = complement-operator
                  | union-operator
                  | intersection-operator
                  | difference-operator
                  | symmetric-difference-operator

   #
   # Match operators (matchers)
   #

Davies & Freytag       Expires September 21, 2016              [Page 70]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   any-matcher = element any {
       attribute count { count-pattern }?,
       attribute comment { text }?
   }

   choice-matcher = element choice {
       ## "count attribute MUST only be used when the choice-matcher
       ## contains no nested "start", "end", "anchor", "look-behind"
       ## or "look-ahead" operators and no nested rule-matchers
       ## containing any of these elements
       attribute count { count-pattern }?,
       attribute comment { text }?,
       # two or more match operators
       match-operator-choice,
       match-operator-choice+
   }

   char-matcher =
     # for use as a matcher - like "char" but without a "tag" attribute
     element char {
       attribute cp { non-empty-code-point-literal },
       # If used as a matcher (appearing in a "rule" element), the
       # "count" attribute may be present. Otherwise, it MUST be
       # absent.
       attribute count { count-pattern }?,
       attribute comment { text }?,
       attribute ref { ref-pattern }?
   }

   start-matcher = element start {
       attribute comment { text }?
   }

   end-matcher = element end {
       attribute comment { text }?
   }

   anchor-matcher = element anchor {
       attribute comment { text }?
   }

   look-ahead-matcher = element look-ahead {
       attribute comment { text }?,
       match-operators-non-pos
   }
   look-behind-matcher = element look-behind {
       attribute comment { text }?,
       match-operators-non-pos

Davies & Freytag       Expires September 21, 2016              [Page 71]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   }

   ## non-positional match operator that can be used as a direct child
   ## element of the choice matcher.
   match-operator-choice = (
     any-matcher | choice-matcher | start-matcher | end-matcher
     | char-matcher | class-or-set-operator-nested | rule-matcher
   )

   ## non-positional match operators do not contain any anchor,
   ## look-behind or look-ahead elements.
   match-operators-non-pos = (
     start-matcher?,
     (any-matcher | choice-matcher | char-matcher
      | class-or-set-operator-nested | rule-matcher)*,
     end-matcher?
   )

   ## positional match operators have an anchor element, which may be
   ## preceeded by a look-behind element, or followed by a look-ahead
   ## element, or both.
   match-operators-pos =
     look-behind-matcher?, anchor-matcher, look-ahead-matcher?

   match-operators = match-operators-non-pos | match-operators-pos

   #
   # Rules
   #

   # top-level rule must have "name" attribute
   rule-declaration-top = element rule {
       attribute name { identifier },
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       match-operators
   }

   ## rule element used as a matcher (either by-ref or contains other
   ## match operators itself)
   rule-matcher =
     element rule {
       ## "count attribute MUST only be used when the rule-matcher
       ## contains no nested "start", "end", "anchor", "look-behind"
       ## or "look-ahead" operators and no nested rule-matchers
       ## containing any of these elements
       attribute count { count-pattern }?,

Davies & Freytag       Expires September 21, 2016              [Page 72]
Internet-Draft      Label Generation Rulesets in XML          March 2016

       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       (attribute by-ref { rule-ref } | match-operators)
     }

   #
   # Actions
   #

   action-declaration = element action {
       attribute comment { text }?,
       attribute ref { ref-pattern }?,
       # dispositions are often named after variant types or vice versa
       attribute disp { variant-type },
       ( attribute match { rule-ref }
         | attribute not-match { rule-ref } )?,
       ( attribute any-variant { variant-type-list }
         | attribute all-variants { variant-type-list }
         | attribute only-variants { variant-type-list } )?
   }

   # DOCUMENT STRUCTURE

   start = lgr
   lgr = element lgr {
       meta-section?,
       data-section,
       rules-section?
   }

   ## Meta section - information recorded with an label
   ## generation ruleset that generally does not affect machine
   ## processing (except for unicode-version).
   ## However, if any "class-declaration" uses the "property" attribute
   ## a unicode-version MUST be present.
   meta-section = element meta {
       element version {
           attribute comment { text }?,
           text
       }?
       & element date { date-pattern }?
       & element language { language-tag }*
       & element scope {
           # type may by "domain" or an application-defined value
           attribute type { xsd:NCName },
           scope-value
       }*

Davies & Freytag       Expires September 21, 2016              [Page 73]
Internet-Draft      Label Generation Rulesets in XML          March 2016

       & element validity-start { date-pattern }?
       & element validity-end { date-pattern }?
       & element unicode-version {
           xsd:token {
               pattern = "\d+\.\d+\.\d+"
           }
       }?
       & element description {
           # this SHOULD be a valid MIME type
           attribute type { text }?,
           text
       }?
       & element references {
           element reference {
               attribute id {
                   xsd:token {
                       # limit id attribute to uppercase letters,
                       # digits and a few punctuation marks; use of
                       # integers is RECOMMENDED
                       pattern = "[\-_.:0-9A-Z]*"
                       minLength = "1"
                   }
                },
                attribute comment { text }?,
                text
           }*
       }?
   }

   data-section = element data { (char | range)+ }

   ## Note that action declarations are strictly order dependent.
   ## class-or-set-operator-declaration and rule-declaration-top
   ## are weakly order dependent, they must precede first use of the
   ## identifier via by-ref.
   rules-section = element rules {
     ( class-or-set-operator-declaration
       | rule-declaration-top
       | action-declaration)*
   }

   <CODE ENDS>

Appendix E.  Acknowledgements

   This format builds upon the work on documenting IDN tables by many
   different registry operators.  Notably, a comprehensive language
   table for Chinese, Japanese and Korean was developed by the "Joint

Davies & Freytag       Expires September 21, 2016              [Page 74]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   Engineering Team" [RFC3743] that is the basis of many registry
   policies; and a set of guidelines for Arabic script registrations
   [RFC5564] was published by the Arabic-language community.

   Contributions that have shaped this document have been provided by
   Francisco Arias, Julien Bernard, Mark Davis, Martin Duerst, Paul
   Hoffman, Sarmad Hussain, Barry Leiba, Alexander Mayrhofer, Nicholas
   Ostler, Thomas Roessler, Audric Schiltknecht, Steve Sheng, Michel
   Suignard, Andrew Sullivan, Wil Tan and John Yunker.

Appendix F.  Change History

   This appendix to be removed prior to final publication.

   draft-davies-idntables-00  Initial draft.

   draft-davies-idntables-01  Add an XML Namespace, and fix other XML
        nits.  Add support for sequences of code points.  Improve on
        consistently using Unicode nomenclature.

   draft-davies-idntables-02  Add support for validity periods.

   draft-davies-idntables-03  Incorporate requirements from the Label
        Generation Ruleset Procedure for the DNS Root Zone.  These
        requirements include a detailed grammar for specifying whole-
        label variants, and the ability to explicitly declare of the
        actions associated with a specific variant.  The document also
        consistently applies the term "Label Generation Ruleset", rather
        than "IDN table", to reflect the policy term now being used to
        describe these.

   draft-davies-idntables-04  Support reference information per
        [RFC3743].  Update description in response to feedback.  Extend
        the context rules to "char" elements and allow for inverse
        matching ("not-when").  Extend the description of label
        processing and implied actions, and allow for actions that
        reference disposition attributes on any or all variant mappings
        used in the generation of a variant label.

   draft-davies-idntables-05  Change the name of the "disposition"
        attribute to "disp".  Add comment attribute on version and
        reference elements.  Allow empty "cp" attributes in char
        elements to support expressing symmetric mapping of null
        variants.  Describe use of variants that map identically.
        Clarify how actions are triggered, in particular based on
        variant dispositions, as well as description of default actions.
        Revise description of processing a label and its variants.  Move
        example table at the head of appendices.  Add "only-variants"

Davies & Freytag       Expires September 21, 2016              [Page 75]
Internet-Draft      Label Generation Rulesets in XML          March 2016

        attribute.  Change "name" attribute to "by-ref" attribute for
        referencing named classes and rules.  Change "not" to
        "complement".  Remove "match" attribute on rules as redundant if
        "start" and "end" are supported.  Rename "match" element to
        "anchor" as better fitting its function and removing confusion
        with both the "match" attribute on actions as well as the
        generic term Match Operator.  Augmented the examples relevant to
        [RFC3743].

   draft-davies-idntables-06  Extend the discussion of reflexive
        variants and their use; includes update of the appendix on
        converting tables in the style of [RFC3743].  Improve
        description of tagging and clarify that it doesn't apply to
        sequences.  Specify that root zone uses ".".  Add an appendix
        with an Indic Syllable Structure example.  Extend count
        attribute to allow maximal counts.

   draft-davies-idntables-07  Change "byref" to "by-ref".  Add list of
        recommended properties.  Change "location" to "positional" for
        collective name of start/end match operators.  Use from-tag
        instead of by-ref for tag-based classes.  Made optional or
        mutually exclusive nature of some attributes more explicit.
        Allowing "comment" attributes on all child elements of "rules"
        except "char" and "range" elements used as child elements of
        "class".  Recast the design goals and requirements at the start
        of the document.  Reword aspects of the document to make it
        clear the format's application is not limited only to domain
        names.

   draft-davies-idntables-08  Change "domain" to scope with
        type="domain".  Reword in several places for clarity.  Flesh out
        note on security.  Change "disp" to "type" for variants, to mark
        that these attributes do not necessarily correspond one-to-one
        to variant label dispositions.  Add example of variant type
        triggers.  Remove "long form" of class definition.

   draft-davies-idntables-09  Grammatical updates, clarity improvements.
        Altered some DNS-specific terminology.

   draft-davies-idntables-10  Added convention for out-of-repertoire
        variants, additional examples of when rules in the context of
        symmetry, isolated minor copy editing.  Use a URN as the XML
        namespace (provisional).  Specify a media type for the file.

   draft-ietf-lager-specification-00  Update to reflect adoption as a
        work item by the IETF LAGER working group.

Davies & Freytag       Expires September 21, 2016              [Page 76]
Internet-Draft      Label Generation Rulesets in XML          March 2016

   draft-ietf-lager-specification-01  Update to reflect decisions in
        first interim meeting of IETF LAGER working group.  Correcting a
        number of typos, added section on contextual conditions,
        clarified language on how actions are triggered, and changed
        "block", "allocate" and "activate" to "blocked", "allocatable".
        and "activated".  Other minor changes.

   draft-ietf-lager-specification-02  Minor changes.

   draft-ietf-lager-specification-03  Update to fix a typo in the
        schema, and clarify the use of reflexive variants in checking
        label validity.  Added security consideration for naive
        implementations of permuted labels and WLE rules.  Added
        discussion of error conditions under which duplicate variant
        labels might be created.  Other minor changes.

   draft-ietf-lager-specification-04  Updated XML namespace in the
        RelaxNG schema.

   draft-ietf-lager-specification-05  Add IANA Considerations for media
        type registration, URN registration and instantiating a
        dispositions registry.  Split references into normative and
        informative.  Describe a tighter restriction on permissible
        values for "ref" attributes.  Clarify when "count" attributes
        are permitted.  Typos fixed.  Checked the schema against the
        specification and made corrections as well as replaced the
        "text" datatype with less permissive types for most attributes.

   draft-ietf-lager-specification-06  Change eligibility required for
        disposition registration to be Specification Required, rather
        than Standards Track.  Restore schema in appendix.  Move
        registration related procedures to informative references.

   draft-ietf-lager-specification-07  Clarify the way the values of the
        "property" attribute are constructed from the attribute name and
        value in [UAX42].  Minor fixes to examples and wording for a few
        of the match operators and the description for reflexive
        variants.  Clarified default action, added new disposition named
        "valid" and changed "catch-all" action to a disposition of
        "valid".  Removed an ambiguity in the evaluation of labels for
        LGRs that define sequences of code points as elements.  Added
        change controller for media type.

   draft-ietf-lager-specification-08  Minor typographical fixes.

   draft-ietf-lager-specification-09  Incorporated feedback from LAGER
        WG Last Call.  Fixed examples in 4.4.1 and 5.2.1.  Reviewed
        usage of RFC 2119 language, and other editorial suggestions.

Davies & Freytag       Expires September 21, 2016              [Page 77]
Internet-Draft      Label Generation Rulesets in XML          March 2016

        Removed "und-Jpan" example as "ja" would suffice in normal
        cases.  Document approach to expanding "scope" element.

   draft-ietf-lager-specification-10  Minor ID-nits related edits.
        Integrate feedback on media type registration.

   draft-ietf-lager-specification-11  Integrate feedback from AD review.

Authors' Addresses

   Kim Davies
   Internet Corporation for Assigned Names and Numbers
   12025 Waterfront Drive
   Los Angeles, CA  90094
   US

   Phone: +1 310 301 5800
   Email: kim.davies@icann.org
   URI:   http://www.icann.org/

   Asmus Freytag
   ASMUS Inc.

   Email: asmus@unicode.org

Davies & Freytag       Expires September 21, 2016              [Page 78]