[Top] [All Lists]

Re: non-UTF-8 sequences in Sieve scripts

2006-09-30 14:33:12

Ned Freed wrote:

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.


> 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

Ok, if (2) is replaced with what you've proposed, which choice would you

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

Thinking more about this. I think replacing existing ABNF in 3028bis to only allow for valid UTF-8 sequences would be a drastic change at this point, as it will pretty much declare all existing implementations non compliant. I've already suggested some warning text about phasing out non-UTF-8 sequences and you agreed with my text. I think the suggested text is sufficient for this round of work on 3028bis.