[Top] [All Lists]

Re: non-UTF-8 sequences in Sieve scripts

2006-09-18 07:47:49

On Mon, Sep 18, 2006 at 10:05:19AM -0400, Cyrus Daboo wrote:
But it also says: 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

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.  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.