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

From: [email-masked]
Date: Mon, 09 May 2011 19:00:03 -0700

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-08.txt
	Pages           : 18
	Date            : 2011-05-09

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), CardDAV (work
in progress), or relational databases.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-08.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: Mon, 9 May 2011 22:07:45 -0400

>        Filename        : draft-ietf-sieve-external-lists-08.txt
...
> http://www.ietf.org/internet-drafts/draft-ietf-sieve-external-lists-08.txt

This is the update that implements the changes discussed in this thread:
http://www.ietf.org/mail-archive/web/sieve/current/msg04981.html

Please review it carefully, because I had to split what had formerly
been the URI scheme registration into four parts:

1. Section 4.5, which registers the "sieve" IETF URN sub-namespace
(defines "urn:ietf:params:sieve").

2. Section 4.3, which creates a Sieve URN parameter registry.

3. Section 4.4, which registers "addrbook" as the first Sieve URN parameter.

4. Section 2.6, which specifies the details for the "addrbook" URN parameter.

There are also significant changes in section 2.5 (Syntax of an
Externally Stored List Name).  And everywhere else that "addrbook:"
was used I replaced it with ":addrbook:" (mostly, that's the examples
and the Security Considerations).

So let's make sure I got it all right, OK?  Thanks.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 22:19:48 -0400

...
> So let's make sure I got it all right, OK?  Thanks.

Damn: I already found one thing I'd missed.  Replace the beginning of
section 4.3 with this:

    The following requests IANA to create a new registry under "Sieve
Extensions"
    for Sieve URN Parameters.  Registration into this registry is according to
    the "Specification Required" policy [RFC5226].

(And I added a normative reference to RFC 5226.)

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 May 2011 12:04:42 +0100

>So let's make sure I got it all right, OK?  Thanks.
You changes seem Ok. One nit:

In Section 3:

    Applications SHOULD ensure appropriate restrictions are in place to	
    protect sensitive information that might be revealed by "addrbook"	
    URIs from access or modification by untrusted sources.

Should this be "URNs"?

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 May 2011 09:10:14 -0400

>   URIs from access or modification by untrusted sources.

I actually thought about that in every place where I talk about them.
URNs are URIs, after all, and I'm not sure when I should say "URN" and
when "URI".  Is that the only place that "addrbook URI" is left?  If
so, I guess I should change it.

Barry

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 12 May 2011 15:02:47 +0100

Barry Leiba wrote:

>URNs are URIs, after all,
>
Yes, but strictly speaking '"addrbook" URI' is not correct.

>and I'm not sure when I should say "URN" and
>when "URI".  Is that the only place that "addrbook URI" is left?
>
That is the only place I've noticed.

>If so, I guess I should change it.
>  
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 May 2011 14:14:03 -0400

...
> That is the only place I've noticed.

Changed in my working copy.

Cyrus, Ned -- can you review soon?  Thanks.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 12 May 2011 21:36:43 -0400

Hi Barry,

> Cyrus, Ned -- can you review soon?  Thanks.

I had a look early on and the basics seemed fine. I just need to 
double-check the urn registration procedures then I will be happy. Is there 
any "expert" reviewer for URNs (beyond the IESG)? I don't see anything 
obvious.

It might also be worth posting a note back to the URI review list to let 
them know the direction we have taken. Some of those folks may want to 
review the new approach.

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 May 2011 22:20:57 -0400

> any "expert" reviewer for URNs (beyond the IESG)? I don't see anything

No... as I read 3553, it's just the IESG and IANA.

> them know the direction we have taken. Some of those folks may want to

I don't think they have any standing to review it.  We're out of their
jurisdiction at this point.

Barry

---

From: [email-masked]
Date: Thu, 19 May 2011 10:38:59 -0700 (PDT)

> Cyrus, Ned -- can you review soon?  Thanks.

I just did a complete review of -09, and also updated our implementation to
match. The one thing I wanted to point out is that section 2.6 is going to end
up in the IANA registry in it's entirety, including the text about the example
parameter values. I think this is OK, but want to be sure nobody else thinks it
might confuse people into thinking all these names actually need to be
implemented.

The only other thing that occurred to me is that we could add a variant
of example 2 showing how to use string :list if currentdate doesn't
support :list directly. Something like:

       require ["extlists", "date", "enotify", "variables"];
       if currentdate :matches "date" *" {
         set "cd" "${0}";
         if string :list "${cd}" "date"
            "tag:example.com,2011-01-01:localHolidays" {
            notify "xmpp:[email-masked]";
         }
       }

I certainly don't insist on this addition but I thought it might be helpful.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 May 2011 14:13:46 -0400

> The one thing I wanted to point out is that section 2.6 is going to end

I don't think so (first sentence), and I can certainly make sure it
doesn't when we get the IANA actions note.  The intent is that the
only thing in the registry is "addrbook" and the reference to section
2.6 of RFC xxxx as where the doc lives.  The stuff in sec 2.6 is
simply the documentation that has to exist, as required by the reg
template.

Section 4.3 says that the registry has "URN parameter name" and
"Reference".  Under "reference", it goes on to say what information
MUST exist in the *reference*, but not in the *registry*.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 19 May 2011 15:05:43 -0400

Hi,

--On May 19, 2011 10:38:59 AM -0700 [email-masked] wrote:

> I just did a complete review of -09, and also updated our implementation
> to match.

I'll take this as a reply to my question about implementations - thanks!

-- 
Cyrus Daboo

---

From: [email-masked]
Date: Thu, 19 May 2011 12:46:39 -0700 (PDT)

> MUST exist in the *reference*, but not in the *registry*.

OK, then is shouldn't be an issue.

				Ned