On Fri, Sep 15, 2006 at 12:34:16AM +0100, Alexey Melnikov wrote:
1). draft-ietf-sieve-3028bis stays as it is now, i.e. it allows for
non-UTF-8 sequences, but recommends UTF-8. Eventually implementations
will implement new strings with proper escaping mechanism, but existing
strings will stay as described till the end of time.
I dislike allowing non-UTF-8 sequences very strongly, because it forbids
to convert a Sieve filter to other character sets without scanning it
for strings.
2). draft-ietf-sieve-3028bis gets updated to only describe UTF-8
sequences with no escaping (*). The draft can describe existing
situation with non-UTF-8 sequences, or it can remain completely silent
on the issue. This wouldn't affect existing implementations, as long as
non-UTF-8 sequences in scripts are not explicitly prohibited. The draft
will also explicitly state that future revisions of this document would
not allow for non-UTF-8 sequences.
I prefer that the base spec continues to only describe UTF-8, staying
silent on implementations that take the freedom to violate RFC 3028,
which says in 2.1:
The language is represented in UTF-8, as specified in [UTF-8].
Whoever decides to leave UTF-8 knows the risks of doing so.
We decided "envelope-auth" should be introduced as extension, although
implementations simply offered it before. I see a similar situation now:
Some implementations offer a super set of RFC 3028. To me, that is not a
reason to extend the base spec, but a reason to introduce an extension.
That way, we can be sure all Sieve implementations will conform to the
new spec.
On the other side, I don't think we gain something by saying: "You MUST
not use anything but UTF-8, or you MUST NOT stick the Sieve logo on your
implementation." ;-)
An extension to introduce arbitrary octet sequences encoded as UTF-8
(or ASCII) character sequences is fine with me, but I doubt its use
for the base specification, as it is most useful when working with
raw data, which the base spec does not offer.
Michael