Preparation for IDNABIS Stockholm
Mark Davis ⌛
mark at macchiato.com
Mon Jul 20 06:33:26 CEST 2009
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/20090719/f1c546ef/attachment-0001.htm
More information about the Idna-update
mailing list