Ned Freed wrote:
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.
Right. I will post a proposal next week.
I am not sure I want to have it in the base spec, as it will mean
delaying its publications, but we can argue this point separately later.
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.
Right. In general case it is not possible to put requirements on future
specs.
Ok, if (2) is replaced with what you've proposed, which choice would you
prefer?