On Thu, 2005-10-27 at 13:01 -0400, Scott Hollenbeck wrote:
Here's something to think about that came up during today's IESG evaluation
of draft-ietf-sieve-variables. It might be worth talking about since the
doc needs some other edits before IESG approval.
From: Brian E Carpenter [mailto:brc(_at_)zurich(_dot_)ibm(_dot_)com]
While scanning drafts in Frankfurt airport, I noticed
that two of them (the iris and sieve drafts) refer in the
text to Unicode.
My understanding is that the IETF recommendation is to
use the ISO 10646 coded character set, and I thought there
were good reasons we specified that instead of Unicode.
What should we be looking for in RFCs?
Where is that recommendation?
RFC 2277 = BCP 18
which doesn't even mention Unicode. (Also see RFC 2130).
on the other hand, stringprep (RFC 3454) is quite explicit in that it is
based on Unicode 3.2, rather than "ISO 10646 with amendments".
I haven't checked this, but it might be due to ISO 10646 not containing the
necessary information about normalization procedures.
I
believe this is a more stringent choice, although I'm unsure if an
explicit reference to Unicode 3.2 is the right choice for miscellaneous
other documents.
It is definitely a more stringent choice. Historically ISO 10646 has tracked
changes in Unicode, so saying "ISO 10646 with amendments" has historically
corresponded to "a recent version of Unicode". A reference to Unicode 3.2,
OTOH, means that version and that version only.
I believe it would be very useful to define a stringprep profile for
Sieve. the profile may be defined for more general usage (comparators
too, others?), but something [SIEVE] can refer to would make things a
whole lot clearer. I don't suggest to make it mandatory for Sieve, but
*either* you support US-ASCII only (and use the identity mapping for
other code points) *or* you support the profile.
I really don't see the value in this. You said later that it would be used for
matching and for :upper and :lower. I think sieve is a case where using
a nameprep profile by default in matching could easily cause more problems
than it solves. I suppose there's some value in making :upper and :lower
more versatile, but I don't think having a single, global default profile
for this is the right way to do it.
Ned