[Top] [All Lists]

Re: [sieve] Question about draft-ietf-sieve-external-lists-02

2010-08-03 03:35:06
 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

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.

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

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?



sieve mailing list