Comments on draft-ietf-idnabis-tables-06

[Patrik Fältström]

Thanks Andrew. I hereby ack that I received this.

    Patrik

On 26 aug 2009, at 16.35, Andrew Sullivan wrote:

> 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.
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://www.alvestrand.no/pipermail/idna-update/attachments/20090826/c27a07ae/attachment.pgp