Op 31-7-2010 19:09, Ned Freed schreef:
However, the
document does not describe how this new match type interacts with a
specified comparator.
Yes, and I'm of two minds as to how to fix it. The simplest thing to
do is to
simply declare that comparators have no effect on :list. (We can make
them a
no-op or an error to even specify.) The alternative is to allow
comparators to
be an input, but for the use of that input to be implementation and
list-specific. (Again, whether or not it would be an error to specify a
comparator on a :list that doesn't consume it would need to be
determined.)
I think it is always a good idea to make sure the user gets to know that
the combination of match-type and comparator isn't valid. If it is
obvious at compile time, a compile error would be appropriate. At
runtime I am not sure. A fatal error seems harsh. But, simply ignoring a
specified comparator is in my opinion not a good idea either.
The base spec already specifies something that is somewhat analogous to
the :list situation:
Section 2.7.3 Comparators:
Some comparators may not be usable with substring matches; that is,
they may only work with ":is". It is an error to try to use a
comparator with ":matches" or ":contains" that is not compatible with
it.
I guess that it is sufficient to declare that it is an error to try to
use a comparator with :list when the specified list-uri is not
compatible with that comparator or does not accept/use comparators at all.
I guess what I'd like to see is a use-case where comparators can be
useful
with :list. If such cases exists I'm inclined to allow the
combination, if not
I'm inclined to disallow it.
I don't see a good one right now. One may have use for comparators for
the very simple external lookups, like a flat file.
For example, when I remember correctly, the LDAP
schema internally defines how, i.e. with what collation, attribute
values are to be matched.
Exactly so. And it isn't just LDAP - database keys are generally
typed, so
:list mapping onto a database is likely to encounter similar issues.
Yes.
What to do in situations where specifying an explicit comparator
is inappropriate? I think this is an important issue that should be
adressed in the specification.
There's also the possibility of doing something akin to how the
current regex
draft uses comparators - as a means of identifying a canonicalization
and what
constitutes a unit of comparison. Do we want to allow that sort of use
with
:list?
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?
Regards,
Stephan.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve