[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-UTF-8 sequences in Sieve scripts




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?


Definitely (2). People need to be warned that this may change in the future.

				Ned