Subject: [sieve] I-D Action:draft-ietf-sieve-external-lists-04.txt

From: [email-masked]
Date: Mon, 08 Nov 2010 18:15:29 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title           : Sieve Extension: Externally Stored Lists
	Author(s)       : A. Melnikov, B. Leiba
	Filename        : draft-ietf-sieve-external-lists-04.txt
	Pages           : 12
	Date            : 2010-11-08

The Sieve scripting language can be used to implement whitelisting,
blacklisting, personal distribution lists, and other sorts of list
matching.  Currently, this requires that all members of such lists be
hardcoded in the script itself.  Whenever a member of a list is added
or deleted, the script needs to be updated and possibly uploaded to a
mail server.

This document defines a Sieve extension for accessing externally
stored lists -- lists whose members are stored externally to the
script, such as using LDAP (RFC 4510), ACAP (RFC 2244), or relational
databases.

ToDo

o  Do we need support for URI schemes in ihave?  From IETF 77

minutes: "Can use ihave to test if a URI is valid, both that the

scheme is supported and that the URI can be retrieved/queried."

o  Do we need to say anything about comparators?  We can be silent

(as now), we can say that comparators MAY be ignored as a list-

specific thing, or we can say that comparators MUST NOT be used.

o  Should we add a mandatory-to-implement tag?  Ned suggests (and I

agree) that it might be good to add a registry of well-defined

strings that can be used instead of URIs, and define the initial

string "pab" to represent the user's personal address book.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 9 Nov 2010 16:11:24 +0800

I have posted a new rev of external-lists, for everyone's reviewing
pleasure.  I would like to finish up this document, and there's still
a bit of a to-do list.  Please, all, give it a review, and
particularly address the to-do list just below the abstract.

Thanks,
Barry

---

From: [email-masked]
Date: Tue, 09 Nov 2010 06:39:02 -0800 (PST)

> particularly address the to-do list just below the abstract.

It looks fine, modulo the to-do list of course.

> scheme is supported and that the URI can be retrieved/queried."

I'll again repeat that if you want to allow this in ihave, the way you
do it is to define it for require. ihave is defined to piggyback on
require - it has no independent argument of its own.

And I have a problem with allowing this in require. List validity and
accessibility is not something I can always properly check at compile time.

So if we want this, it really needs to be a separate test, just like it is in
notify.

> specific thing, or we can say that comparators MUST NOT be used.

My preference is to disallow the combination, but ignoring it would
also be acceptable.

> string "pab" to represent the user's personal address book.

My thinking on this has changed - it would be better to define a pab:
pseudo-URL so there can be an argument specifying which of the user's
address books to use. 

There's one addition I'd like to make to the list. I've proposed saying
that if variables are enabled ${0} should return the thing that matched
in a :list match, just like it does for :matches. ${1} and so on would
return optional, list-specific information. In the case of pab: URLs
I'd suggest defining ${1} to be a sort of status for the entry returned.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 09 Nov 2010 09:16:28 -0500

Hi [email-masked],

> pseudo-URL so there can be an argument specifying which of the user's

URNs might be an option. i.e., we could define "urn:ietf:params:sieve:pab", 
then we can use that as a URI too. Of course there are a lot of characters 
in that, which is one disadvantage.

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Tue, 09 Nov 2010 09:30:26 -0800 (PST)

> in that, which is one disadvantage.

I have to say, that's a bit long...

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Nov 2010 13:28:51 +0800

> require - it has no independent argument of its own.
Right.
> accessibility is not something I can always properly check at compile time.
Agreed.
> So if we want this, it really needs to be a separate test, just like it is in
I am personally happy with this. Anybody else wants to weight in?
> My preference is to disallow the combination, but ignoring it would
I have no preferences, so let's do what you suggest, unless others have 
other opinions.
> pseudo-URL so there can be an argument specifying which of the user's
Can you think of any use for pab: URLs outside of Sieve external list?
If you can, then that would suggest that that is the best way forward.
> I'd suggest defining ${1} to be a sort of status for the entry returned.
Can you elaborate on what you mean by "status" here and how would this 
work for other types of URIs?

---

From: [email-masked]
Date: Sat, 27 Nov 2010 10:54:53 -0800 (PST)

> Can you think of any use for pab: URLs outside of Sieve external list?

No, not really. I can come up with hypothetical uses of course, but
I don't see another existing protocol where a pab: URL makes sense.

> work for other types of URIs?

It's a status the user has associated with the entry. We seem to be
assuming whitelist-only sorts of applications here. I could just as easily
want to use pab entries to separate work from personal mail based on whether
the originator is someone I work with. Or I might want to have blacklist
entries. And I might not want to use separate address books for this purpose.

				Ned