Comments on draft-ietf-idnabis-tables-06
Patrik Fältström
patrik at frobbit.se
Thu Sep 10 22:15:37 CEST 2009
On 26 aug 2009, at 16.35, Andrew Sullivan wrote:
> To begin with, I should note that I am not a Unicode expert. Further,
> I have not implemented any test to check that the algorithms defined
> here actually produce the expected results. I did run through the
> rules in §3 and they seem sensible to me, but without checking the
> results for a large number of characters, it's hard to say that with
> much authority. I emphasise this for the purposes of the Chair, who
> will have to evaluate the quality of the review the document received.
We do have three implementations of the algorithm. I have done two (in
two different programming languages), and we have verified we reach
the same result (the same derived values). So I think we are safe.
We do not have multiple implementations of the algorithms of the
context rules.
> As will be obvious from my comments below, I think this document is
> ready to go. It's in very good shape, in my opinion.
>
> In §2.8, we have this:
>
> 2.8. JoinControl (H)
>
> H: Join_Control(cp) = True
>
> This category consists of Join Control characters (i.e., they are
> not
> in LetterDigits (Section 2.1)) but are still required in IDN labels
> under some circumstances. They require extended special treatment
> in
> Lookup and Resolution.
>
> I think we previously agreed just to call the action "lookup".
> Strictly, all the special treatment is part of the lookup process, but
> not the resolution process (which is a straight DNS activity that
> happens to be using an A-label as its QNAME). As I've argued before,
> I want the documents to stay very far away from any suggestion that
> they are changing the operation of the DNS as such.
I removed the last sentence.
> As I have with other documents in the set, I object strongly to the
> inclusion of the sentence, " As is usual with IETF specifications,
> while the document represents rough consensus, it should not be
> assumed that all participants and contributors agree with all
> provisions." I'll spare participants my speech on why this is a bad
> thing this time.
Removed.
> In Appendix A, this paragraph
>
> Note that "Before" and "After" do not refer to the visual display
> order of the character in a label, which may be reversed or
> otherwise
> modified by the bidirectional algorithm for labels including
> characters from scripts written right-to-left.
>
> might benefit from the addition of another sentence, "Instead,
> 'Before' and 'After' refer to the network order of the character in
> the label."
Added.
> In
>
> Appendix A.7. KATAKANA MIDDLE DOT
> Code point:
> U+30FB
> Overview:
> Note that the Script of Katakana Middle Dot is not any of
> "Hiragana", "Katakana" or "Han". The effect of this rule is to
> require at least one character in the label to be in one of those
> scripts.
> Lookup:
> False
> Rule Set:
> False;
> For All Characters:
> If Script(cp) .in. {Hiragana, Katakana, Han} Then True;
>
> there is no "End For" as called for in the pseudocode definition.
Added.
> Thanks to the editor for a good job on this document.
Thanks for the good comments!
Patrik
More information about the Idna-update
mailing list