<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
Got it. Sounds good
<div><br>
</div>
<div>Thanks,</div>
<div>Dennis <br>
<br>
<div dir="ltr">Sent from my iPhone</div>
<div dir="ltr"><br>
<blockquote type="cite">On Dec 10, 2019, at 5:00 PM, Bill Jouris <bill.jouris@insidethestack.com> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">Hi Dennis, 
<div id="yMail_cursorElementTracker_1576015159977"><br>
</div>
<div id="yMail_cursorElementTracker_1576015160324">That was my intention.  I figured to put sample tables (probably just headers) in, just so the IP is clear that we are not ignoring their comments.  But that's it. </div>
<div id="yMail_cursorElementTracker_1576015233695"><br>
</div>
<div id="yMail_cursorElementTracker_1576015234077">Bill <br id="yMail_cursorElementTracker_1576015148556">
<br>
<div id="ymail_android_signature"><a id="ymail_android_signature_link" href="https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature">Sent
 from Yahoo Mail on Android</a></div>
<br>
<blockquote style="margin: 0 0 20px 0;">
<div style="font-family:Roboto, sans-serif; color:#6D00F6;">
<div>On Tue, Dec 10, 2019 at 1:04 PM, Tan Tanaka, Dennis via Latingp</div>
<div><latingp@icann.org> wrote:</div>
</div>
<div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;">
Michael is correct. We register Latin's view of variants (in-script and cross-script) and produce well-formed variant sets. We don't need to worry about those relationships created by other GPs. IP will do this during integration and call out any issues, as
 they have.<br clear="none">
<br clear="none">
Bill - I would suggest leaving the task of creating variant set tables until the end. The LGR tool can help with that and alleviate the time consuming task of doing this by hand. Note that this is necessary for our own proposal before submitting to IP as well.
 As a panel we need to make certain all variant sets are well formed. The LGR tool make this easier.<br clear="none">
<br clear="none">
Dennis <br clear="none">
<br clear="none">
On 12/9/19, 6:11 AM, "Latingp on behalf of Michael Bauland" <<a shape="rect" ymailto="mailto:latingp-bounces@icann.org" href="mailto:latingp-bounces@icann.org">latingp-bounces@icann.org</a> on behalf of
<a shape="rect" ymailto="mailto:Michael.Bauland@knipp.de" href="mailto:Michael.Bauland@knipp.de">
Michael.Bauland@knipp.de</a>> wrote:<br clear="none">
<br clear="none">
    Hi Bill,<br clear="none">
    <br clear="none">
    On 07.12.2019 20:42, Bill Jouris wrote:<br clear="none">
    > This task appears to have two separate parts. <br clear="none">
    > <br clear="none">
    > 1) *ASCII variants resulting from Transitivity* <br clear="none">
    > <br clear="none">
    > At the meeting with the Armenian, Cyrillic, Greek, and Latin GPs in<br clear="none">
    > Montreal, the IP noted that cross-script variants and transitivity<br clear="none">
    > resulted in Latin Small Letter V and Latin Small Letter Y being variants<br clear="none">
    > -- which, since they are ASCII characters, is not allowed.  The cause<br clear="none">
    > (at least part of the cause) was determined to be the Greek GP's finding<br clear="none">
    > that Greek Small Letter Nu and Greek Small Letter Gamma are variants. <br clear="none">
    > That finding also resulted in an in-script Cyrillic variant which the<br clear="none">
    > Cyrillic GP found unacceptable.  <br clear="none">
    > <br clear="none">
    > The result of discussion between the  GPs was that the Greek GP would<br clear="none">
    > reconsider their finding regarding Nu and Gamma.  Thus no action is<br clear="none">
    > required of the Latin GP. <br clear="none">
    <br clear="none">
    yes, that is also what I remember from the discussion. The Greek did not<br clear="none">
    seem to mind too much to lose that variant relationship.<br clear="none">
    <br clear="none">
    > <br clear="none">
    > 2) *Variants due to Transitivity*<br clear="none">
    > <br clear="none">
    > A complete listing will, of course, await finalizing our decisions on<br clear="none">
    > Latin in-script variants.  But I have started creating tables for them. <br clear="none">
    > For example, for Cyrillic cross-script variants, each case we found will<br clear="none">
    > also require a new transitivity listing for each of the Latin in-script<br clear="none">
    > variants we find for the Latin element in the cross-script variant. <br clear="none">
    > Tedious to generate, or course, but not calling for any particular<br clear="none">
    > decision process by us.<br clear="none">
    <br clear="none">
    I agree. Let's have two examples.<br clear="none">
    Let's say Lx are Latin characters and Cx are Cyrillic ones.<br clear="none">
    <br clear="none">
    Example 1:<br clear="none">
    ----------<br clear="none">
    If we then have have the following:<br clear="none">
    L1 a variant of C1.<br clear="none">
    L1 a variant of L2.<br clear="none">
    L2 a variant of L3.<br clear="none">
    C2 a variant of L4.<br clear="none">
    <br clear="none">
    And the Cyrillic also have<br clear="none">
    C1 a variant of C2.<br clear="none">
    <br clear="none">
    In that case, as I understand it, we have to list the following variant<br clear="none">
    sets:<br clear="none">
    {L1, L2, L3, C1}<br clear="none">
    {L4, C2}<br clear="none">
    <br clear="none">
    The IP will then in a second step realise that C2 and C1 are variants<br clear="none">
    and therefore combine the two sets to one:<br clear="none">
    {L1, L2, L3, L4, C1, C2}<br clear="none">
    <br clear="none">
    But that is out of our scope, as I understand it. We don't have to look<br clear="none">
    at any in-script variants within other scripts.<br clear="none">
    <br clear="none">
    Example 2:<br clear="none">
    ----------<br clear="none">
    If we have<br clear="none">
    L1 a variant of L2<br clear="none">
    but not<br clear="none">
    L1 a variant of C1<br clear="none">
    <br clear="none">
    And the Cyrillic team has<br clear="none">
    C1 a variant of L1<br clear="none">
    <br clear="none">
    Then we don't have to put C1 into our {L1, L2} variant set. That's the<br clear="none">
    task of the Cyrillic team. They do {C1, L1} and the IP will then<br clear="none">
    generate {L1, L2, C1} from this.<br clear="none">
    <br clear="none">
    <br clear="none">
    We always just look at the variant relationships we think are valid and<br clear="none">
    generate the transitive closure for those, ignoring any results from<br clear="none">
    other teams.<br clear="none">
    <br clear="none">
    Cheers,<br clear="none">
    <br clear="none">
    Michael<br clear="none">
    <br clear="none">
    -- <br clear="none">
    ____________________________________________________________________<br clear="none">
        |      |<br clear="none">
        | knipp |            Knipp  Medien und Kommunikation GmbH<br clear="none">
          -------                    Technologiepark<br clear="none">
                                    Martin-Schmeißer-Weg 9<br clear="none">
                                    44227 Dortmund<br clear="none">
                                    Deutschland<br clear="none">
    <br clear="none">
        Dipl.-Informatiker          Tel:    +49 231 9703-0<br clear="none">
                                    Fax:    +49 231 9703-200<br clear="none">
        Dr. Michael Bauland        SIP:    <a shape="rect" ymailto="mailto:Michael.Bauland@knipp.de" href="mailto:Michael.Bauland@knipp.de">
Michael.Bauland@knipp.de</a><br clear="none">
        Software-Entwicklung        E-Mail: <a shape="rect" ymailto="mailto:Michael.Bauland@knipp.de" href="mailto:Michael.Bauland@knipp.de">
Michael.Bauland@knipp.de</a><br clear="none">
    <br clear="none">
                                    Registereintrag:<br clear="none">
                                    Amtsgericht Dortmund, HRB 13728<br clear="none">
    <br clear="none">
                                    Geschäftsführer:<br clear="none">
                                    Dietmar Knipp, Elmar Knipp<br clear="none">
    _______________________________________________<br clear="none">
    Latingp mailing list<br clear="none">
    <a shape="rect" ymailto="mailto:Latingp@icann.org" href="mailto:Latingp@icann.org">
Latingp@icann.org</a><br clear="none">
    <a shape="rect" href="https://mm.icann.org/mailman/listinfo/latingp" target="_blank">
https://mm.icann.org/mailman/listinfo/latingp</a><br clear="none">
    <br clear="none">
    _______________________________________________<br clear="none">
    By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a shape="rect" href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a shape="rect" href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing,
 setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
<div class="yqt6586414807 yQTDBase" id="yqtfd49321"><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
Latingp mailing list<br clear="none">
<a shape="rect" ymailto="mailto:Latingp@icann.org" href="mailto:Latingp@icann.org">Latingp@icann.org</a><br clear="none">
<a shape="rect" href="https://mm.icann.org/mailman/listinfo/latingp" target="_blank">https://mm.icann.org/mailman/listinfo/latingp</a><br clear="none">
<br clear="none">
_______________________________________________<br clear="none">
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a shape="rect" href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a shape="rect" href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing,
 setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</body>
</html>