[Top] [All Lists]

Re: non-UTF-8 sequences in Sieve scripts

2006-09-15 07:44:50

Hi everyone,

I think there is rough consensus to have an extension that would
introduce new strings with proper escaping mechanism. The new strings
will allow for UTF-8 (as is) + non-UTF-8 can be escaped. As nobody
volunteered to do this, I will write a short proposal on this.

But I would like to get general feeling of the Working Group about
non-UTF-8 sequences in existing 3028bis strings.
draft-ietf-sieve-3028bis-09.txt doesn't prohibit them. However, what
should our long term solution be? I see two choices:

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.

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.

So basically 2) would state the desire to deprecate use of unescaped
non-UTF-8 sequences in scripts, while 1) would allow for them indefinitely.

Do people see other choices?

First of all, I think we need to describe whatever escaping mechanism we decide
on, preferably in the base document. I don't think it is reasonable to suggest
abandoning a capability, let alone forbidding it, unless we have the
alternative in place.

Once we have the alternative defined I think the right approach is somewhere
between (1) and (2). (2) goes too far IMO by saying that deprecation will
happen in the future. I think the correct course is to say that the
ability to use non-UTF-8 _may_ be abandoned in the future and to plan