--On Saturday, July 17, 2010 08:42 -0700 Paul Hoffman
<paul(_dot_)hoffman(_at_)vpnc(_dot_)org> 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf