Subject: [Lager] Fwd: Re: when sequences are valid in the LGR

From: Asmus Freytag <[email-masked]>
Date: Fri, 29 Jan 2016 12:10:11 -0800

Final forwarded message with final proposed text.

I will add this text in the tracker and integrate it in the sources for 
the next revision of the draft.

A./

-------- Forwarded Message --------
Subject: 	Re: when sequences are valid in the LGR
Date: 	Wed, 27 Jan 2016 08:51:41 -0800
From: 	Asmus Freytag <[email-masked]>
To: 	Wil Tan <[email-masked]>, Kim Davies <[email-masked]>

Wil,

I like your suggestion. The alternative would have been to refer to "at 
that position" a lot. Please have a look at this suggested text and see 
whether it's ready to go to the lager group. (I've marked changes 
manually with color).

A./

  7.1.
  <mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.2&filename=draft-ietf-lager-specification-07-AF2.html>
  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 
<mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.3&filename=draft-ietf-lager-specification-07-AF2.html>), 
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 
<mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.4&filename=draft-ietf-lager-specification-07-AF2.html>).

  7.2.
  <mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.5&filename=draft-ietf-lager-specification-07-AF2.html>
  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:

 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 4.3.4
    <mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.3&filename=draft-ietf-lager-specification-07-AF2.html>)
 4. Determine the disposition for each variant label per Section 7.3
    <mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.6&filename=draft-ietf-lager-specification-07-AF2.html>

 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 7.3
    <mailbox:///C:/Users/asmusf/AppData/Roaming/Thunderbird/Profiles/965oo05j.default/Mail/Local%20Folders/Sent?number=1433369495&part=1.2.6&filename=draft-ietf-lager-specification-07-AF2.html>
    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".