Subject: Re: FW: "Unicode" vs "ISO 10646"

From: Philip Guenther <[email-masked]>
Date: Thu, 03 Nov 2005 09:26:33 -0800

Kjetil Torgrim Homme <[email-masked]> writes:
...
>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.

Could you be more specific about what this profile would be used for in
[SIEVE]?  If it's 'just' a comparator, then it belongs in the collation
doc, but that already defines defines a *nameprep* based collation
(i;nameprep;v=1;uv=3.2) as well as collations using the Unicode
Collation Algorithm, so I suspect you have more in mind that just using
it as a comparator.

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 04 Nov 2005 03:10:59 +0100

> Collation Algorithm, so I suspect you have more in mind that just using

well, by using a nameprep profile, quite a few normal characters are
prohibited, in particular U+00A0 (&nbsp;) is way too common in e-mail to
be disallowed, IMHO.  but I'm not quite clear what prohibiting a
character really means for Sieve.

I just want something which makes sense for matching in base Sieve, but
I also want a :lower and :upper which works in "variables".  using the
nameprep profile is certainly better than locking it to US-ASCII,
though.
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Sat, 05 Nov 2005 10:11:54 -0800 (PST)

> 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:[email-masked]]
> > >>
> > >>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.

> 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