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

From: Stephan Bosch <[email-masked]>
Date: Tue, 03 Aug 2010 10:34:46 +0200

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.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 03 Aug 2010 12:56:00 -0400

--On Tuesday, August 03, 2010 10:34:46 AM +0200 Stephan Bosch 
<[email-masked]> wrote:

> 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.

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.

-- Jeff

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 03 Aug 2010 19:11:45 +0200

Op 3-8-2010 18:56, Jeffrey Hutzelman schreef:
>> list
>> providing
> 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.

> :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?

Regards,

Stephan.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Aug 2010 11:45:58 +0200

> which combinations are acceptable and which will produce errors.
Good point. Before I saw your message Stephan almost got me convinced 
otherwise.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 04 Aug 2010 11:53:37 +0200

Stephan Bosch wrote:
> 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.

---

From: [email-masked]
Date: Wed, 04 Aug 2010 16:00:36 -0700 (PDT)

> don't have a strong opinion.

Given the points that have been raised, I'm starting to think this is the right
answer. In the rare cases where a compprator does make sense to use with an
external list, it can be encoded into the list name.

> particular comparator works for a particular external list URI type.

Yeah, but the problem there is what to do about tag: URLs. I don't know what
other implementations have planned, but we're not exactly keen on letting users
specify arbitrary LDAP URLs or anything similar. Instead, the mail admin sets
up whatever tag: URLs (incuding families of them) they want, and these are then
mapped to LDAP, database queries, code callouts, whatever.

As it happens we have no exiting or planned external list mechanisms where a
comparator makes sense, so right now we can simply reject the combination
outright. But suppose this were to change. Given the mapping involved we'd
basically be counting on the admin to specify the handling of comparators, and
this means the admin is going to be responsible for setting it up so an unused
comparator results in an error. Of course we can arrange the defaults so that
the "right" think happens most of the time, but even so this doesn't sound
like all that great of an idea...

				Ned