Comments on draft-ietf-idnabis-tables-06

[Andrew Sullivan]

Dear colleagues,

I have read draft-ietf-idnabis-tables-06.  These are my comments.  I
will send nits to the editor directly.

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.

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.

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.

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."  

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.

Thanks to the editor for a good job on this document.

Best regards,

A


-- 
Andrew Sullivan
ajs at shinkuro.com
Shinkuro, Inc.