--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman
<paul.hoffman@xxxxxxxx> wrote:
>...
>> (2) In Section 4.4.2, note that there are definitional and
>> procedural problems if one tries to talk about a single rule
>> for full domain names. It is possible, and has been the only
>> option until very recently, for a fully-qualified IDN to
>> contain both "traditional" and "internationalized" labels.
>> IDNA2008 avoided a number of definitional problems by being
>> defined strictly in terms of labels for just that reason.
>> In particular, conversion of an all-ASCII label to an A-label
>> is undefined and meaningless: such a label is not a U-label
>> and hence cannot be converted. One needs to parse the string
>> into labels, determine for each label whether it is
>> "traditional" or
>> "internationalized", and then apply the appropriate rule. I'd
>> recommend rewriting 4.4.1 and 4.4.2 in terms of labels, not
>> FQDNs.
>
> Here we (may) disagree. 4.4.2 is already in terms of labels:
> If the source domain of a reference identifier is an
> internationalized domain name, then an implementation MUST
> convert every label in the domain name to an A-label before
> checking the domain name.
> Are you saying that the correct wording should elide "If the
> source domain of a reference identifier is an
> internationalized domain name, then" and just start at "An
> implementation MUST"? That would work for me.
That would probably be an improvement. But my problem was with
"every label" and a sticky detail of IDNA2008: the only things
that can be converted to A-labels are U-labels. One cannot
convert an LDH label to an A-label, nor can one convert
something that was already an A-label into an A-label. Those
operations are just not defined. So I think this should be
"every internationalized label" or (probably better) "every
non-traditional label" or something to that effect.
>> (3) Note that anything that requires that an application
>> program parse a FQDN that might be an IDN into labels should
>> probably have a Security Considerations note about the risks
>> if various dotoids leak into the relevant environment.
>
> Errrr, why should this document be forced to have such a
> warning when the IDNA2008 documents don't?
The IDNA2008 base document sort of dodge the problem by dealing
with labels, not FQDNs. If I recall, you have some "beware of
leaks" language in Mapping, but I might be wrong. In any event,
the reason it occurred to me as something that might be useful
to say here is that the functions of this document would be,
IMO, particularly sensitive to having someone want to store a
name with the local label separator convention and that would be
a problem. Possibly not more serious than other places, but
still possibly worth mentioning.
In any event, I consider the topic worth mentioning but
definitely not a showstopper.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf