At 3:35 PM -0400 8/13/07, Russ Housley wrote:
This issue was raised by my review of
http://www.ietf.org/internet-drafts/draft-ietf-smime-bfibecms-03.txt
However, I think that the issue goes beyond this document. The
decision made here ought to set a precedent.
My original comment was:
1) Section 2 defines EmailIdentitySchema as a UTF8String. The text says:
E-mail addresses that contain non-ASCII
characters MUST be encoded using punycode [RFC3492].
Therefore, the result of the encoding should always be ASCII. Why
is an UTF8 String needed?
I think that the use of punycode in an IA5String was the correct
approach. This approach uses the ToASCII algorithm to generate an
ASCII string from the Unicode string. The punycode can then be
operated on using the usual subroutines to handle copy, compare, and
such.
Fully agree.
The alternative is to use UTF8, which cannot be operated on using
the usual subroutines to handle copy, compare, and such.
The last part is not really correct (there are "usual" subroutines in
all languages for copying and comparing UTF-8 strings), but it is
still much better to use Punycode-encoded domain names for
interoperability.
Using IA5String to hold the Punycode would prevent a sloppy
implementer from stuffing UTF-8 into the field. That is a good enough
reason to use it as the holder.
--Paul Hoffman, Director
--VPN Consortium