[Gen-art] LC review: draft-ietf-idnabis-bidi-06.txt
Joel M. Halpern
jmh at joelhalpern.com
Mon Oct 5 18:17:31 CEST 2009
Probably the simplest solution for the first part of the "major" problem
is to add text at the front of the rules section (section 2), that
states something like:
The rules about character properties given here are additional
restrictions on what characters are permitted in specific DNS labels,
augmenting the basic rules as defined in [ref...]
That would make clear that "." is not allowed just because it is flagged
CS, and would tell the reader where to look if they are reading in other
than the recommended order, or if it has been too long since they read
the other document.
However, that still leaves the confusion about the fact that section 3
states that CS is prohibited, when section 2 says that CS is permitted.
I do not know enough about what is being intended to suggest
clarifying text for the paranethetical in section 3.
Yours,
Joel
John C Klensin wrote:
> Joel,
>
> Speaking for myself only...
>
> It may or may not have been wise for the Gen-ART group to parcel
> this documents out to different reviewers. On the one hand, it
> reduces the burden but, on the other, they are closely related
> and, without seeing the relationship, confusion is not only
> possible but likely. Realistically, no one should ever
> implement "bidi" without implementing all of IDNA2008; to try to
> do so will lead to all sorts of "interesting" problems.
>
> You have spotted one of those. When the bidi document says that
> characters from particular categories are allowed, that is not
> an assertion that _all_ code points falling into any of those
> categories are allowed, only that the categories are allowed
> (and need to be treated in bidi-specific ways). Which
> characters are actually allowed is specified by application of
> the rules in "Tables" as invoked and selected from "Protocol".
>
> There was extensive discussion in the WG about how, and whether,
> to split the documents up the way they are divided and
> reasonably strong (I personally believe stronger than just
> "rough") consensus that the current arrangement represents the
> best balance we could arrive upon.
>
> If you can suggest ways to make the relationships and, in
> particular, the relationship of the categories used in Bidi and
> the character and code-point selections and restrictions in
> Tables and Protocol, more clear, I assume that the document
> authors and WG would welcome those suggestions.
>
> regards,
> john
>
>
>
>
> --On Monday, October 05, 2009 10:43 -0400 "Joel M. Halpern"
> <jmh at joelhalpern.com> wrote:
>
>> I have been selected as the General Area Review Team (Gen-ART)
>> reviewer for this draft (for background on Gen-ART, please see
>> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html ).
>>
>> Please resolve these comments along with any other Last Call
>> comments you may receive.
>>
>> Document: draft-ietf-idnabis-bidi-06.txt
>> Right-to-left scripts for IDNA
>> Reviewer: Joel M. Halpern
>> Review Date: 5-Oct-2009
>> IETF LC End Date: 14-Oct-2009
>> IESG Telechat date: N/A
>>
>> Summary: This document is nearly ready for publication as a
>> proposed standard.
>> There is one comment I have marked as Major. I presume that
>> the actual problem is not a defect in the intent of the spec,
>> but a defect in this readers understanding. Presuming such,
>> I would ask that clarifying text be added.
>>
>> Major issues:
>> In section 2, when describing the rules for what is allowed in
>> labels, CS is allowed in labels. It is not allowed to start
>> RTL labels. This looks fine, until I realized that CS
>> includes ".", which I am pretty sure is not allowed in a
>> label.
>> This gets further complicated in section 3, when talking about
>> "The Character Trouping requirement", the text talks about
>> "Delimiterchars" being CS, WS, or ON. A parenthetical then
>> says "They are not allowed in domain labels."
>> Since the normative text said that CS is allowed, there seems
>> to be a problem.
>
>
>
>
>
More information about the Idna-update
mailing list