<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">mark,<div><br></div><div>thanks for this useful summary.</div><div><br></div><div>vint</div><div><br></div><div><br><div><div>On Jul 20, 2009, at 12:33 AM, Mark Davis ⌛ wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">I agree that we need to come to consensus on the key remaining issues. I'd suggest, for clarity, that you issue a separate Consensus Call on each of these, allowing for discussion and then all interested stating their opinions, as you did before.<br> <br>I think the key issues are:<br><br>A. Whether the mapping should be (a) MUST, (b) SHOULD, (c) MAY, or (d) removed.<br><br>B. Whether we agree on the proposed mapping (with the amendments suggested on the list - unfortunately we don't have a rolled-up document to consider).<br> <br>C. Stability (from earlier email; you agreed, but these are not in the documents)<br><ul><li>We strictly forbid, for stability's sake, any changes in the following direction: PVALID => CONTEXT* => DISALLOWED.</li> <li>Changes in the other direction require IETF-level intervention: DISALLOWED => CONTEXT* => PVALID</li></ul>D. What the final Tables should be. I suggest this be in two parts; I think E.1. can be settled affirmatively without issue. E.2 we might be able to settle this week, if everyone works at it.**<br> <div style="margin-left: 40px;">D.1. Whether the Tables are ok except for the Exceptions.<br>D.2. Whether the Table Exceptions are ok. (see below)<br></div><br>E. Eszett/Sigma. I realize that you disagree here, but as I've said, the previous consensus was reached without a Mapping phase; the specification has <i>materially changed</i> since then by the addition of a mapping phase. To be very clear, with no question in anyone's mind about any procedural issues, it would be far cleaner to issue a Consensus Call for this as well.<br> <br clear="all">Mark<br><br>** The Exception issues will unfortunately need to be to be settled in a rush -- although the issues were raise back in November, then again in April, it was only in the last week or so that there was any serious discussion. However, we appear to be making good progress.<br> <br>Mark<br><br><div class="gmail_quote">On Sat, Jul 18, 2009 at 12:02, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style="word-wrap: break-word;"><p style="">Folks,</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">We must achieve consensus on our documents and submit them to the AD at or shortly after our WG meeting in Stockholm.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">here is where I think we are:</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">We have essential consensus on the five primary documents (rationale, defs, bidi and protocol). There are ongoing discussions about some specifics in Tables. We are also discussing the language of the sixth document (mapping).<span> </span>Bidi and Tables have expired as I-Ds and need to be re-issued.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">"Internationalized Domain Names for Applications (IDNA): Background,</p><p style=""> Explanation, and Rationale", John Klensin, 18-Jun-09,</p><p style=""> <draft-ietf-idnabis-rationale-10.txt></p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> "Internationalized Domain Names in Applications (IDNA): Protocol", John</p><p style=""> Klensin, 13-Jul-09, <draft-ietf-idnabis-protocol-13.txt></p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> "Internationalized Domain Names for Applications (IDNA): Definitions and</p><p style=""> Document Framework", John Klensin, 22-Jun-09,</p><p style=""> <draft-ietf-idnabis-defs-09.txt></p><div style=""> <br class="webkit-block-placeholder"></div><p style="">"An updated IDNA criterion for right-to-left scripts", H. Alvestrand, C. Karp, 30-Nov-2008</p><p style=""> < draft-ietf-idnabis-bidi-03.txt></p><div style=""> <br class="webkit-block-placeholder"></div><p style="">"The Unicode code points and IDNA", Patrik Faltstrom, 22-Dec-2008,</p><p style=""> <draft-ietf-idnabis-tables-05.txt></p><div style=""> <br class="webkit-block-placeholder"></div><div style=""> <br class="webkit-block-placeholder"></div><p style=""> "Mapping Characters in IDNA", Pete Resnick, Paul Hoffman, 3-Jul-09,</p><p style=""> <draft-ietf-idnabis-mappings-01.txt></p><div style=""> <br class="webkit-block-placeholder"></div><div style=""> <br class="webkit-block-placeholder"></div><div style=""> <br class="webkit-block-placeholder"></div><p style="">Assuming we want to make reference to the mapping document in rationale (and perhaps in protocol), we need to conclude how to do that.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">We also need to modify the mapping document to perform the sequence of mappings in an order that puts NFC mapping last and yet still reduce user surprise. Editors Hoffman and Resnick have this responsibility after the WG decides on which steps in which order are to be used.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">We have already concluded (cf at IETF 74 and subsequently) that the strings that are actually registered must be in U-Label form (or A-Label form or both, assuming equivalence under the bidirectional punycoding mechanism). How ever these strings are arrived at, the registrant should have a clear understanding of the actual domain names that will be registered. I think this implies that there should not be implicit mappings undertaken by the zone registrar (using the term zone here in its most general sense, not just at TLD or SLD levels) that might make it ambiguous exactly what domain name will be found in the name server.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">The procedure outlined in the mapping document is intended to provide a means of reducing user surprise in part by emulating prior to look up the behavior case insensitive behavior of the pure ASCII Domain Name regime of the past. It is also intended to assure that the labels used in the lookup process have characters expressed in Unicode Normal Form C. </p><div style=""> <br class="webkit-block-placeholder"></div><p style="">I would like to propose the following ideas for discussion:</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">1. Mapping should NOT be a MUST on lookup, to allow for the fact that a substantial range of transformations may take place from the time a possible DNS reference is input into an application to the point where a DNS query is made. This suggests that RFC 2119 conformant language could read “mapping MAY be performed on lookup.”</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">2. There has been discussion whether the mapping document should be silent with regard to RFC 2119 language. There is a range of opinions. Unless the WG comes to consensus on wording that meets the RFC 2119 requirements, the document will remain the same. There remains a question of how the mapping document should be referred from the protocol document. The WG needs to come to consensus on that, applying the same requirements on meeting the RFC 2119 requirements.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">3. We need to finalize the Tables document. The WG mailing list has been very active with discussions on this point. We must come to closure at this meeting on the content of Tables. It would be appreciated and the chair will attempt to enforce that we do not re-open matters upon which<span> </span>the WG has already reached consensus.</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">Specifically, Eszett(sharp S) is PVALID. ZWJ and ZWNJ are CONTEXTJ, TATWHEEL is DISALLOWED, Hangul JAMO are DISALLOWED, Final Sigma is PVALID. </p><div style=""> <br class="webkit-block-placeholder"></div><p style="">Regarding Tables, Mark Davis appears to have captured section F (exceptions) as follows:</p><div style=""> <br class="webkit-block-placeholder"></div><div style=""> <br class="webkit-block-placeholder"></div><p style="">PVALID: // would otherwise have been DISALLOWED</p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> 00DF; PVALID # LATIN SMALL LETTER SHARP S</p><p style=""> 03C2; PVALID # GREEK SMALL LETTER FINAL SIGMA</p><p style=""> 06FD; PVALID # ARABIC SIGN SINDHI AMPERSAND</p><p style=""> 06FE; PVALID # ARABIC SIGN SINDHI POSTPOSITION MEN</p><p style=""> 0F0B; PVALID # TIBETAN MARK INTERSYLLABIC TSHEG</p><p style=""> 3007; PVALID # IDEOGRAPHIC NUMBER ZERO</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">CONTEXTO: // would otherwise have been DISALLOWED</p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> 00B7; CONTEXTO # MIDDLE DOT</p><p style=""> 0375; CONTEXTO # GREEK LOWER NUMERAL SIGN (KERAIA)</p><p style=""> 05F3; CONTEXTO # HEBREW PUNCTUATION GERESH</p><p style=""> 05F4; CONTEXTO # HEBREW PUNCTUATION GERSHAYIM</p><p style=""> 30FB; CONTEXTO # KATAKANA MIDDLE DOT</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">CONTEXTO: // would otherwise have been PVALID</p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> U+002D; CONTEXTO # HYPHEN-MINUS</p><p style=""> <span> </span>U+02B9; CONTEXTO # MODIFIER LETTER PRIME</p><p style=""> U+0660; CONTEXTO # ARABIC-INDIC DIGIT ZERO</p><p style=""> U+0661; CONTEXTO # ARABIC-INDIC DIGIT ONE</p><p style=""> U+0662; CONTEXTO # ARABIC-INDIC DIGIT TWO</p><p style=""> U+0663; CONTEXTO # ARABIC-INDIC DIGIT THREE</p><p style=""> U+0664; CONTEXTO # ARABIC-INDIC DIGIT FOUR</p><p style=""> U+0665; CONTEXTO # ARABIC-INDIC DIGIT FIVE</p><p style=""> U+0666; CONTEXTO # ARABIC-INDIC DIGIT SIX</p><p style=""> U+0667; CONTEXTO # ARABIC-INDIC DIGIT SEVEN</p><p style=""><span> </span>U+0668; CONTEXTO # ARABIC-INDIC DIGIT EIGHT</p><p style=""> U+0669; CONTEXTO # ARABIC-INDIC DIGIT NINE</p><p style=""> U+06F0; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ZERO</p><p style=""> U+06F1; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ONE</p><p style=""> U+06F2; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT TWO</p><p style=""> U+06F3; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT THREE</p><p style=""> U+06F4; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FOUR</p><p style=""> U+06F5; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FIVE</p><p style=""> U+06F6; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SIX</p><p style=""> U+06F7; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SEVEN</p><p style=""> U+06F8; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT EIGHT</p><p style=""> U+06F9; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT NINE</p><p style=""> U+0483; CONTEXTO # COMBINING CYRILLIC TITLO</p><p style=""> U+3005; CONTEXTO # IDEOGRAPHIC ITERATION MARK</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">DISALLOWED: // would otherwise have been PVALID</p><div style=""> <br class="webkit-block-placeholder"></div><p style=""> U+302E; DISALLOWED # HANGUL SINGLE DOT TONE MARK</p><p style=""> U+302F; DISALLOWED # HANGUL DOUBLE DOT TONE MARK</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">In addition it has been proposed to DISALLOW the following vertical formatting characters:</p><div style=""> <br class="webkit-block-placeholder"></div><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+3031: Lm: VERTICAL KANA REPEAT MARK</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+3032: Lm: VERTICAL KANA REPEAT WITH VOICED SOUND MARK</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+3033: Lm: VERTICAL KANA REPEAT MARK UPPER HALF</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+3034: Lm: VERTICAL KANA REPEAT WITH VOICED SOUND MARK UPPER HALF</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+3035: Lm: VERTICAL KANA REPEAT MARK LOWER HALF</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+303B: Lm: VERTICAL IDEOGRAPHIC ITERATION MARK</span></p><p style=""><span style="font-size: 12pt; font-family: Helvetica;">U+07FA: Lm:<span> </span>NKO LAJANYALAN</span></p><p style="">I propose that we come prepared to resolve all of these matters on the first day of the IETF meeting (Monday). If there are other matters that WG members believe need to be addressed, please speak up!</p><div style=""> <br class="webkit-block-placeholder"></div><p style="">See you in Stockholm!</p><div style=""> <br class="webkit-block-placeholder"></div><font color="#888888"><p style="">Vint</p></font></div><br><div style="word-wrap: break-word;"><div style=""><br class="webkit-block-placeholder"></div></div><br>_______________________________________________<br> Idna-update mailing list<br> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br> <br></blockquote></div><br></blockquote></div><br></div></body></html>