Michael Haardt wrote:
On Mon, Sep 18, 2006 at 10:05:19AM -0400, Cyrus Daboo wrote:
But it also says:
2.4.2.4. MIME Parts
In a few places, [MIME] body parts are represented as strings. These
parts include MIME headers and the body. This provides a way of
embedding typed data within a Sieve script so that, among other
things, character sets other than UTF-8 can be used for output
messages.
i.e. there is ambiguity here, but the bottom line is non-utf-8 data can be
used in current sieve scripts without violating the spec. That is the
problem we want to solve, but we cannot outlaw non-utf-8 now without making
many implementations non-compliant. What we want to do in the long run is
deprecate use of non-utf-8 strings in favor of escaped utf-8 strings, which
is what Alexey's strawman is leading to.
I don't see the ambiguity. MIME encodes the data in US-ASCII, and the
script only contains the MIME-encoded data.
What about 8bit and binary content transfer encodings?
Sieve knows nothing about
the MIME-encoding of content passed e.g. to vacation: Its _type_ may be
a Klingon sound file, not even text data, but MIME-encoded Sieve only
sees US-ASCII.
We are looking at non-UTF-8 data that Sieve sees as such.
I don't mean to outlaw non-UTF-8 in Sieve scripts, because I see no
purpose in doing so. But I don't want to legalise it either. If many
(how many?) implementations decided to implement a superset of RFC 3028,
that's their decision. I prefer to stay silent about that, and use a
regular extension to offer that functionality.
You opinion is noted. So basically you want a variant of option (2) from
my poll.