On Tue, 8 Mar 2005, Philip Guenther wrote:
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?
I agree. The changes aren't substantial enough to warrant this (even
allowing tests to have side effects wouldn't require this).
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.
Also agree.
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.
I think you mean (2) here.
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).
Same here.
-Rob
-------------------------------------------------------------------------
Rob Siemborski | PGP:0x5CE32FCC | rjs3(_at_)andrew(_dot_)cmu(_dot_)edu
-----BEGIN GEEK CODE BLOCK----
Version: 3.12
GCS/IT/CM/PA d- s+: a-- C++++$ ULS++++$ P+++$ L+++ E W+ N(-) o? K- w-- O-
M-- V-- PS+ PE+ Y+ PGP+ t+@ 5+++ X- R@ tv-- b+ DI+++ D++ G e++ h+ r- y?
------END GEEK CODE BLOCK-----