Comments on draft-ietf-idnabis-tables-06
Patrik Fältström
patrik at frobbit.se
Wed Aug 26 16:50:20 CEST 2009
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
More information about the Idna-update
mailing list