Comments on draft-ietf-idnabis-tables-06

[Patrik Fältström]

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