On 3/2/10 6:47 PM, John Levine wrote: >>> RFC 4871, top sentence on page 20, in the description of d= >>> >> ... >> >>> RFC 4871, second paragraph on page 21, in the description of i= >>> >> For the bis effort, I'd recommend this clarification. I think it would fall >> within acceptable boundaries of change while going to Draft. >> > I agree the two sentences should say the same thing. Don't feel > strongly about the wording since the way UTF->punycode works is the > same for all domain names everywhere. > Disagree. One should not assume there is a unitary conversion of UTF to punycode. The informational RFC 5242 has changed this one-to-one relationship. As such UTF->punycode will produce a more than one conversion, depending upon conversion rule-sets applied. There is a genuine need for the additional rule-sets, so don't assume there is a unitary conversion of UTF to punycode, or that there are even just two possibilities.
This issue will impact ADSP more than DKIM base. ADSP is based upon what is seen in the From header. Conversions of the From header may not resolve to a specific domain, depending upon the evolving conversion rule-sets. The solution sought to deal with this issue is to use "equivalent" names to intercept these possible conversions. The set of overlapping UTF names can be rather large and evolving. ADSP may consider advising the use of double conversion. Convert UTF into punycode using RFC5242 rules, and then convert punycode to UTF-8. Since there is no definite conversion that might be used, assured compliance may depend upon methods that allow use of third-party signatures, which could apply whenever the conversion rule-sets between sender and receiver are not the same. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
