Stephan Bosch wrote:
Op 3-8-2010 18:56, Jeffrey Hutzelman schreef:
--On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch
<stephan(_at_)rename-it(_dot_)nl> wrote:
Hmm, well.... why not? I suggest we make it an error only when the list
has no explicit use for it, meaning that implementors MAY accept
comparators for an external list, but MUST trigger an error when the
list
does not use the specified comparator or the comparator is incompatible
somehow.
I guess the main question is: what would be the disadvantage of
providing
more flexibility to the implementor for the interaction of :list with
comparators?
This sounds like an interoperability nightmare. You describe a
situation where a SIEVE implementation has the option to accept
comparators or not, but if not, then providing them is an error, and
there is no way for the producer of the sieve script to know in
advance what will happen.
Hmm. Good point. My version would require each and every list type to
be specified, at least in terms of their comparator behavior...
undesirable. Well, with that in mind, providing a warning is the best
an implementation can do I guess.
This is _not_ analogous to comparators that work with :is but not
with :matches or :contains, because you can know from the
specifications which combinations are acceptable and which will
produce errors.
Agreed.
Any thoughts on the issue of whether comparators should be disallowed
in general for the :list match-type?
I personally think that comparators should be allowed with :list, but I
don't have a strong opinion.
I also think that making Sieve scripts fail because an implementation
decides that a particular comparator can't be used with :list would be a
bad idea. If we want to go this route, then we need to define how a
particular comparator works for a particular external list URI type.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve