--On Friday, October 16, 2009 18:23 -0400 Suresh Krishnan
<[email protected]> wrote:
> I am the assigned Gen-ART reviewer for
> draft-ietf-idnabis-defs-11.txt
>...
> Minor
> =====
>
> * Section 2.3.1 Page 8
>
> ==> "XN-labels are further divided in those whose remaining
> characters (after the "xn--") are valid output of the
> Punycode algorithm."
>
> ... and what else?
Fixed, but not very well. Given the xml2rfc difficulties in
making intra-document cross-references, to anything but a
section, I had to resort to a vague forward pointer. But at
least the sentence no longer leaves one hanging.
> ==> U-labels are used before their definition
Well, not really because the reference I think you are referring
to is preceded by a forward pointer in bullet 5 of Section 1.3.
While it would be really good to have all of these definitions
sorted into strict order, the WG has tried that in rewrite after
rewrite. The experience has been that it cannot be done, or
cannot be done in a way that doesn't reduce clarity. What makes
this equally problematic is that the WG sorted out terminology
and got it consistent across the document set at great pain.
Because of the risk of causing unintentional side-effects, I
believe that we should avoid trying to re-tune terminology --or
terminology organization-- changes unless they are clearly
required to make things clear. In this area, "requires some
skipping forward in the document" is not, IMO, sufficient
justification for incurring those risks. Of course, if the WG
or IESG disagree, I'll try to do it.
> ==> Since -- is already implied for R-LDH labels shouldn't
> this text
>
> "Labels within the class of R-LDH labels that are not prefixed
> with "xn--" are also not valid IDNA-labels."
>
> be replaced with
>
> "Labels within the class of R-LDH labels that are not prefixed
> with "xn" are also not valid IDNA-labels."
Maybe, but the terminology used throughout the IDNA materials
(both this set of documents and the 2003 ones) has been that the
"prefix" is "xn--". That statement in the document is still
true, so, while your correction might be an improvement in
isolation, I think is might create more confusion than it
eliminates (see the comments above about trying to re-tune
terminology).
> * Section 2.3.2.4
>
> "Equivalence between a U-label and an A-label determined by
> translating the U-label form into an A-label form and then
> testing
> for an exact match between the A-labels."
>
> Given that the transformation in the other direction (A-label
> to U-label and then compare) is going to give the same result,
> is there a specific reason for picking this direction for the
> transformation? i.e. is Punycode encoding more efficient than
> decoding?
There are two reasons. One is that IDNA2003 supported a great
many mapping arrangements, so that (using IDNA2008 terminology)
converting from a Unicode string to an A-label and then to a
U-label might not yield the original string. Doing things in
the order specified provides some backward compatibility
protections. The other is that the WG was considering requiring
some small set of mappings until extremely late in the process.
Converting to A-labels and then comparing would be stable
regardless of the outcome of those discussions; converting to
U-labels might not be.
> * 4.4 Security considerations
>
> Should this section mention issues with visually similar
> domain names causing issues with non-matching certificates. If
> this happens the user is probably going to get very confused.
The confusable character issue is covered in the Protocol
document (with cross-references there improved in the
post-last-call version). The specific flavor of that issue with
certificates seemed to be out of scope, however, as a general
observation, as long as everyone is careful to keep strings in
canonical form (a different problem from visual confusability)
the certificate problem with IDNs is really no different from
possible mismatches between ASCII strings like "abcld" and
"abc1d": if you are looking closely and have fonts that lend
themselves to discrimination, then there will be no problem. If
not... IDNs change the magnitude of the problem by shifting it
from perhaps three or four sets of confusable characters (note,
for example, that "rn" in some fonts, and especially if the
typesize is small, may not be easily distinguished from "m") to
thousands. But the difference is one of scale, not kind.
thanks,
john
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
