Subject: [Lager] [lager] #32 (specification): Remove ambiguity about processing sequences

From: "lager issue tracker" <[email-masked]>
Date: Fri, 29 Jan 2016 20:12:16 -0000

#32: Remove ambiguity about processing sequences

 The existing text of sections 7.1 and 7.2 can be interpreted ambiguously,
 as regards the processing of code point sequences defined in an LGR.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-lager-
  [email-masked]   |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:               |    Version:
  specification          |   Keywords:
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/32>
lager <https://tools.ietf.org/lager/>

---

From: "lager issue tracker" <[email-masked]>
Date: Fri, 29 Jan 2016 20:15:18 -0000

Comment (by [email-masked]):

 This proposed text removes the ambiguity. The fourth paragraph of 7.1 and
 the last paragraph of 7.2 are new text. The remaining text in 7.1 has been
 modified to refer to "instances of" code points and sequences, to clarify
 that what matters is a particular code point value at a particular
 position in the label.

 7.1. Determining Eligibility for a Label

 In order to test a specific 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 as invalid.

 An individual instance of a code point is deemed a member of the LGR when
 the code point is listed using a "char" element, or is part of a range
 defined with a "range" element, and all necessary condition 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 condition 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 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).

 For LGRs that contain reflexive variant mappings (defined in Section
 4.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 iteration over code points would generally only exclude a subset
 of invalid labels, but it could be used effectively as a pre-screening.

 To 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 for each code point, any reflexive variants are applied,
 and the label disposition is evaluated. 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 7.4).
 7.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 evaluation
 rules are satisfied as follows:

     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)
     Apply variant mappings with "when" or "not-when" attributes only if
 the conditions are satisfied; otherwise they are not defined
     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 4.3.4)
     Determine the disposition for each variant label per Section 7.3
     If the disposition is "invalid", remove the label from the set
     If final evaluation of the disposition for the unpermuted label per
 Section 7.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.

 In determining the permuted set of variant labels in step (1) above, all
 eligible partitions into sequences must be evalluated. A label "ab", that
 matches a sequence "ab" defined in the LGR as well as the sequence of
 individual code points "a" and "b" (both defined in the LGR), must be
 permuted using any defined variant mappings for "ab", "a" and "b".

  specification          |  Resolution:
 Keywords:               |

Ticket URL: <https://trac.tools.ietf.org/wg/lager/trac/ticket/32#comment:1>
lager <https://tools.ietf.org/lager/>