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