ietf-mta-filters
[Top] [All Lists]

Re: base-spec issue #1: character escapes

2005-03-08 09:43:12

Philip Guenther <guenther+mtafilters(_at_)sendmail(_dot_)com> writes:
...
0) do nothing; just repeat that \x means x, period.
1) change the base spec to define \xFF, \uXXXX, etc
2) change the base spec to say the \x maps to x unless overriden
  by an extension; extensions may redefine any \x except \\ and
  \".  Scripts SHOULD NOT contain extraneous escapes.  Then, create
  an extension which defines \xFF, \uXXXX, etc
3) define an extension to variables that implicitly creates variables
  (in a namespace) for each unicode codepoint and octet value whose
  values are the name codepoints/octets
4) define an extension that covers all the changes in the base spec
  that are incompatible with RFC 3028.  Option (1) would be done
  under that extension.  If there are no other incompatible changes
  then this reduces to (2)


With my editor hat off now...

I dislike (4) the most.  Versioning the base spec like that is too
open-ended in my view.  Servers would have to continue to support
the old behavior as well as the updated/fixed behavior.  Are we
here to clarify the base-spec or create Sieve v2?

As much as the simplicity of (1) is tempting, breaking backward
compatibility just because the tweak was easy when there's a
straightforward means to do it via an extension is a bad policy.
This would be neither a clarification nor the removal of an ambiguity.
If it's still an acceptable change, then what's the line for just
rolling changes into the base spec?

Oh, and (1) shouldn't be that complex to implement for anyone who
has already done variables, as they already have the code to change
the interpretation of strings based on the use of an extension.

While (3) is a cleaner design, introducing a dependency on variable
create the possibility that some implmentation that doesn't want
to implement variables but needs access to NUL, etc will do (1) or
(2) instead, thus defeating the goal of interoperability.  If that
is a plausible risk, then (2) or (1) should be picked from the
start.

I therefore would prefer (2).


Philip Guenther