Did this issue get resolved?
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Paul
Hoffman
Sent: Tuesday, August 14, 2007 6:38 PM
To: Simon Josefsson
Cc: Timothy J. Miller; Russ Housley; ietf-smime(_at_)imc(_dot_)org;
tim(_dot_)polk(_at_)nist(_dot_)gov; phoffman(_at_)vpnc(_dot_)org
Subject: Re: UTF8 vs. Punycode
At 12:05 AM +0200 8/15/07, Simon Josefsson wrote:
Paul Hoffman <paul(_dot_)hoffman(_at_)vpnc(_dot_)org> writes:
At 11:30 AM +0200 8/14/07, Simon Josefsson wrote:
One risk is that the specification cannot use Unicode code points
from a newer Unicode version than IDNA ToASCII supports, right now
that means Unicode 3.2.
That is not necessarily true. The current version of IDNA
supports
Unicode version 3.2. A future version of IDNA may support later
versions of Unicode.
I believe the assumption here is that the document would
reference the
current IDNA version. Or are you suggesting that this
document should
wait until the IDNAbis effort is done?
The former. But that does not change what I said: a later
version of IDNA that has the additional characters you were
talking about could be replaced in the spec with near-zero effort.
>>Some IETF protocols can easily negotiate support for UTF-8 on
both sides, and using UTF-8 rather than Punycode seems more robust
and like better engineering to me.
Un-normalized fails miserably when exact matching is
needed, such as
it is in IBE.
Sending UTF-8 does not preclude normalizing from happening when it is
needed.
Ah, I misunderstood your proposal. I thought you meant "send
UTF-8", not "do some normalization that is not specified here,
then send UTF-8". It would be good if you could give your
complete proposal so people can compare them fully.
--Paul Hoffman, Director
--VPN Consortium