Subject: [Gen-art] A *new* batch of IETF LC reviews - 4 Oct 2009

From: "Mary Barnes" <[email-masked]>
Date: Sun, 4 Oct 2009 14:45:08 -0500

Hi all,
 
Here's the link to the new LC assignments for last week: 
http://www.softarmor.com/rai/temp-gen-art/reviewers-091001-lc.html

The assignments (along with the telechat assignments and recent reviews)
are captured in the spreadsheets: 
http://www.softarmor.com/rai/temp-gen-art/gen-art.html 
http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html 

The standard template is included below. 

Thanks, 
Mary. 

------------------------------------------------------------------- 
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: 
Reviewer: 
Review Date: 
IETF LC End Date: 
IESG Telechat date: (if known) 

Summary: 

Major issues: 

Minor issues: 

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Oct 2009 10:43:59 -0400

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

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.

Minor issues:
Rule 6 in section 2 talks about the requirements on the termination of 
an LTR (left-to-right) label.  This requirement is much tighter than 
just "don't end with an RTL character", since rule 5 already said "don't 
use any RTL characters."
However, the non-normative introductory text says roughly that this 
document does not put constraints on labels which do not use RTL characters.
My guess, as a person who is neither a DNS expert nor a Unicode expert, 
is that rules 6 is not a new rule.
If rule 6 is equivalent to existing rules in other documents, shouldn't 
there be an explanation of the fact that it is a restatement of existing 
rules?  If it is not just a restatement, then how can you get away with 
it in this document?

At the end of section 2, there is a reference to LDH-labels.  That is 
the only occurrence of the string LDH in the document.  I presume it is 
a typo for something?

Nits/editorial comments:

---

From: John C Klensin <[email-masked]>
Date: Mon, 05 Oct 2009 12:00:42 -0400

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"
<[email-masked]> wrote:

> Please resolve these comments along with any other Last Call
> comments you may receive.
> 
> 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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 05 Oct 2009 12:17:31 -0400

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 05 Oct 2009 19:00:50 +0200

Joel M. Halpern wrote:
> 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:
> 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.
>
> 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.
Thanks for catching this.

The full set of CS characters is:

002C;COMMA;Po;0;CS;;;;;N;;;;;
002E;FULL STOP;Po;0;CS;;;;;N;PERIOD;;;;
002F;SOLIDUS;Po;0;CS;;;;;N;SLASH;;;;
003A;COLON;Po;0;CS;;;;;N;;;;;
00A0;NO-BREAK SPACE;Zs;0;CS;<noBreak> 0020;;;;N;NON-BREAKING SPACE;;;;
060C;ARABIC COMMA;Po;0;CS;;;;;N;;;;;
202F;NARROW NO-BREAK SPACE;Zs;0;CS;<noBreak> 0020;;;;N;;;;;
2044;FRACTION SLASH;Sm;0;CS;;;;;N;;;;;
FE50;SMALL COMMA;Po;0;CS;<small> 002C;;;;N;;;;;
FE52;SMALL FULL STOP;Po;0;CS;<small> 002E;;;;N;SMALL PERIOD;;;;
FE55;SMALL COLON;Po;0;CS;<small> 003A;;;;N;;;;;
FF0C;FULLWIDTH COMMA;Po;0;CS;<wide> 002C;;;;N;;;;;
FF0E;FULLWIDTH FULL STOP;Po;0;CS;<wide> 002E;;;;N;FULLWIDTH PERIOD;;;;
FF0F;FULLWIDTH SOLIDUS;Po;0;CS;<wide> 002F;;;;N;FULLWIDTH SLASH;;;;
FF1A;FULLWIDTH COLON;Po;0;CS;<wide> 003A;;;;N;;;;;

At the moment, I can't reconstruct what we were thnking when we decided 
to allow it.
The parenthetical remark can go without great loss; nothing depends on 
it. But I wondre why we are allowing CS at all.

                     Harald

---

From: Vint Cerf <[email-masked]>
Date: Mon, 5 Oct 2009 12:57:06 -0400

thanks Joel - we will work on resolving these matters - as you see  
some of the editors have already engaged.

v

On Oct 5, 2009, at 10:43 AM, Joel M. Halpern wrote:

> _______________________________________________
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update