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

From: Stephan Bosch <[email-masked]>
Date: Wed, 28 Jul 2010 12:47:15 +0200

Hi,

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. However, the 
document does not describe how this new match type interacts with a 
specified comparator. For example, when I remember correctly, the LDAP 
schema internally defines how, i.e. with what collation, attribute 
values are to be matched. So, will the specified comparator be ignored 
for LDAP URIs or will it trigger an error? How about other list/db/URI 
types? 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.

Regards,

Stephan.

---

From: [email-masked]
Date: Sat, 31 Jul 2010 10:09:09 -0700 (PDT)

> generic match type. This is, I think, a very good idea.

I'm glad you agree.

> However, the
> 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
> 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
> types?

Same issue there as well.

> What to do in situations where specifying an explicit comparator

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