I just gave the latest specification (ietf-02) of the extlists extension
a quick read. The last version I read was ietf-00 and since then the
:list argument for the various test commands was changed into an actual
generic match type. This is, I think, a very good idea.
I'm glad you agree.
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 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.
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.
So, will the specified comparator be ignored
for LDAP URIs or will it trigger an error? How about other list/db/URI
types?
Same issue there as well.
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?
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve