At 5:22 AM -0400 7/17/10, John C Klensin wrote: >(1) In Section 4.4.1, the reference should be to the IDNA2008 >discussion. The explanations are a little better vis-a-vis the >DNS specs and it is a bad idea to reference an obsolete spec.
+1. I accept blame on this one, since I was tasked on an earlier version to bring the IDNA discussion up to date. >(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 anme. 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. >(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? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
