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.
The alternative is to use UTF8, which cannot be operated on using the
usual subroutines to handle copy, compare, and such.
I understand that the authors are receiving conflicting advice on
this point from Jim Schaad and myself. I have sent email to Jim to
try and understand his point of view, but Jim has not responded. The
text in the most revision of this document was updated to use UTF8,
without requiring punycode. I think this was the wrong way to
resolve this one. I would prefer to retain the use of punycode and
carry the email address in an IA5 string. The reason that I prefer
this solution is that traditional character comparison routines can be used.
What do others think?
Russ