Preparation for IDNABIS Stockholm
Vint Cerf
vint at google.com
Mon Jul 20 07:10:49 CEST 2009
mark,
thanks for this useful summary.
vint
On Jul 20, 2009, at 12:33 AM, Mark Davis ⌛ wrote:
> 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.
>
> I think the key issues are:
>
> A. Whether the mapping should be (a) MUST, (b) SHOULD, (c) MAY, or
> (d) removed.
>
> 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).
>
> C. Stability (from earlier email; you agreed, but these are not in
> the documents)
> We strictly forbid, for stability's sake, any changes in the
> following direction: PVALID => CONTEXT* => DISALLOWED.
> Changes in the other direction require IETF-level intervention:
> DISALLOWED => CONTEXT* => PVALID
> 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.**
> D.1. Whether the Tables are ok except for the Exceptions.
> D.2. Whether the Table Exceptions are ok. (see below)
>
> 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 materially changed 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.
>
> Mark
>
> ** 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.
>
> Mark
>
> On Sat, Jul 18, 2009 at 12:02, Vint Cerf <vint at google.com> wrote:
> Folks,
>
>
> We must achieve consensus on our documents and submit them to the AD
> at or shortly after our WG meeting in Stockholm.
>
>
> here is where I think we are:
>
>
> 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). Bidi and Tables have expired as I-
> Ds and need to be re-issued.
>
>
> "Internationalized Domain Names for Applications (IDNA): Background,
>
> Explanation, and Rationale", John Klensin, 18-Jun-09,
>
> <draft-ietf-idnabis-rationale-10.txt>
>
>
> "Internationalized Domain Names in Applications (IDNA): Protocol",
> John
>
> Klensin, 13-Jul-09, <draft-ietf-idnabis-protocol-13.txt>
>
>
> "Internationalized Domain Names for Applications (IDNA):
> Definitions and
>
> Document Framework", John Klensin, 22-Jun-09,
>
> <draft-ietf-idnabis-defs-09.txt>
>
>
> "An updated IDNA criterion for right-to-left scripts", H.
> Alvestrand, C. Karp, 30-Nov-2008
>
> < draft-ietf-idnabis-bidi-03.txt>
>
>
> "The Unicode code points and IDNA", Patrik Faltstrom, 22-Dec-2008,
>
> <draft-ietf-idnabis-tables-05.txt>
>
>
>
> "Mapping Characters in IDNA", Pete Resnick, Paul Hoffman, 3-Jul-09,
>
> <draft-ietf-idnabis-mappings-01.txt>
>
>
>
>
> Assuming we want to make reference to the mapping document in
> rationale (and perhaps in protocol), we need to conclude how to do
> that.
>
>
> 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.
>
>
> 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.
>
>
> 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.
>
>
> I would like to propose the following ideas for discussion:
>
>
> 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.”
>
>
> 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.
>
>
> 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 the WG has already reached consensus.
>
>
> Specifically, Eszett(sharp S) is PVALID. ZWJ and ZWNJ are CONTEXTJ,
> TATWHEEL is DISALLOWED, Hangul JAMO are DISALLOWED, Final Sigma is
> PVALID.
>
>
> Regarding Tables, Mark Davis appears to have captured section F
> (exceptions) as follows:
>
>
>
> PVALID: // would otherwise have been DISALLOWED
>
>
> 00DF; PVALID # LATIN SMALL LETTER SHARP S
>
> 03C2; PVALID # GREEK SMALL LETTER FINAL SIGMA
>
> 06FD; PVALID # ARABIC SIGN SINDHI AMPERSAND
>
> 06FE; PVALID # ARABIC SIGN SINDHI POSTPOSITION MEN
>
> 0F0B; PVALID # TIBETAN MARK INTERSYLLABIC TSHEG
>
> 3007; PVALID # IDEOGRAPHIC NUMBER ZERO
>
>
> CONTEXTO: // would otherwise have been DISALLOWED
>
>
> 00B7; CONTEXTO # MIDDLE DOT
>
> 0375; CONTEXTO # GREEK LOWER NUMERAL SIGN (KERAIA)
>
> 05F3; CONTEXTO # HEBREW PUNCTUATION GERESH
>
> 05F4; CONTEXTO # HEBREW PUNCTUATION GERSHAYIM
>
> 30FB; CONTEXTO # KATAKANA MIDDLE DOT
>
>
> CONTEXTO: // would otherwise have been PVALID
>
>
> U+002D; CONTEXTO # HYPHEN-MINUS
>
> U+02B9; CONTEXTO # MODIFIER LETTER PRIME
>
> U+0660; CONTEXTO # ARABIC-INDIC DIGIT ZERO
>
> U+0661; CONTEXTO # ARABIC-INDIC DIGIT ONE
>
> U+0662; CONTEXTO # ARABIC-INDIC DIGIT TWO
>
> U+0663; CONTEXTO # ARABIC-INDIC DIGIT THREE
>
> U+0664; CONTEXTO # ARABIC-INDIC DIGIT FOUR
>
> U+0665; CONTEXTO # ARABIC-INDIC DIGIT FIVE
>
> U+0666; CONTEXTO # ARABIC-INDIC DIGIT SIX
>
> U+0667; CONTEXTO # ARABIC-INDIC DIGIT SEVEN
>
> U+0668; CONTEXTO # ARABIC-INDIC DIGIT EIGHT
>
> U+0669; CONTEXTO # ARABIC-INDIC DIGIT NINE
>
> U+06F0; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ZERO
>
> U+06F1; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT ONE
>
> U+06F2; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT TWO
>
> U+06F3; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT THREE
>
> U+06F4; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FOUR
>
> U+06F5; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT FIVE
>
> U+06F6; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SIX
>
> U+06F7; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT SEVEN
>
> U+06F8; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT EIGHT
>
> U+06F9; CONTEXTO # EXTENDED ARABIC-INDIC DIGIT NINE
>
> U+0483; CONTEXTO # COMBINING CYRILLIC TITLO
>
> U+3005; CONTEXTO # IDEOGRAPHIC ITERATION MARK
>
>
> DISALLOWED: // would otherwise have been PVALID
>
>
> U+302E; DISALLOWED # HANGUL SINGLE DOT TONE MARK
>
> U+302F; DISALLOWED # HANGUL DOUBLE DOT TONE MARK
>
>
> In addition it has been proposed to DISALLOW the following vertical
> formatting characters:
>
>
> U+3031: Lm: VERTICAL KANA REPEAT MARK
>
> U+3032: Lm: VERTICAL KANA REPEAT WITH VOICED SOUND MARK
>
> U+3033: Lm: VERTICAL KANA REPEAT MARK UPPER HALF
>
> U+3034: Lm: VERTICAL KANA REPEAT WITH VOICED SOUND MARK UPPER HALF
>
> U+3035: Lm: VERTICAL KANA REPEAT MARK LOWER HALF
>
> U+303B: Lm: VERTICAL IDEOGRAPHIC ITERATION MARK
>
> U+07FA: Lm: NKO LAJANYALAN
>
> 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!
>
>
> See you in Stockholm!
>
>
> Vint
>
>
>
>
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090720/1c01e2e5/attachment.htm
More information about the Idna-update
mailing list