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

From: [email-masked]
Date: Thu, 21 Apr 2011 07:45:01 -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-07.txt
	Pages           : 15
	Date            : 2011-04-21

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-07.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: Thu, 21 Apr 2011 10:54:57 -0400

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

This version has all the changes from WGLC comments, and is ready to
go to the IESG.  Will the chairs please do a PROTO write-up and send
it on?  SM, will you please assign an apps review team member who does
not already participate in Sieve to do a review?

Thanks, all.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 21 Apr 2011 11:00:21 -0400

Hi Barry,

> not already participate in Sieve to do a review?

Given that this is the product of a working group, why is an apps area 
review needed?

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Apr 2011 11:06:00 -0400

> Given that this is the product of a working group, why is an apps area

Alexey and I thought we'd like a separate review, to get different
eyes on it.  It's just like any other last-call review, of course.

Barry

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 21 Apr 2011 11:19:46 -0400

Hi Barry,

> eyes on it.  It's just like any other last-call review, of course.

OK, but I thought apps review was primarily for review of work generated in 
other areas or perhaps individual submissions (though appsawg covers that 
one now). Plus I thought the point was to have a "domain" expert actually 
review it rather than a general "does this look OK".

Anyway, I have no objection to a separate review (the more the better 
really), I just don't think apps review should be unnecessarily loaded with 
work...

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Apr 2011 15:24:11 -0400

> go to the IESG.

In response to review on the uri-review list, I have changed the URI
schema name from "ab" to "addrbook".  I have also made the other
changes listed below in my working copy (which will be -08).  I think
they shouldn't be controversial, but we thought they needed to be
passed by the working group for at least one or two "+1" nods.  Tony,
Ned, can you look at them and comment?

The URI reviews can be found here:
http://www.ietf.org/mail-archive/web/uri-review/current/msg01396.html
http://www.ietf.org/mail-archive/web/uri-review/current/msg01401.html

Murray, when you do your apps review, please note these changes.  If
you need a full version before -08 is posted, let me know separately
and I'll send it to you.

Barry

========================================================
In section 2.5:
OLD
<    The "ab" URI scheme (in particular, the URI "ab:default"), defined in
<    Section 4.3 MUST be supported.  The mandatory-to-implement URI "ab:
<    default" gives access to the user's default address book (usually the
<    user's personal address book).
NEW
>    The "addrbook" URI scheme (in particular, the reserved URI "addrbook:
>    default"), defined in Section 4.3 MUST be supported.  The mandatory-
>    to-implement URI "addrbook:default" gives access to the user's
>    default address book (usually the user's personal address book).
>    Note that these are URIs, subject to normal URI encoding rules,
>    including percent-encoding.  The reserved name "default" MUST be
>    considered case-insensitive after decoding.  That means that the
>    following URIs are all equivalent:
>
>       addrbook:default
>
>       ADDRBOOK:DEFAULT
>
>       aDdRbOOk:DeFauLt
>
>       AddrBook:%44%65%66ault
>
>     Address book names other than "default" MAY be case-sensitive,
>     depending upon the implementation, so their case (after URI
>     decoding) MUST be maintained.

At the end of Security Considerations, section 3:
NEW
>    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.

In "URI scheme semantics:" in section 4.3:
NEW
>        The address book name (the "addrbook" element in the ABNF above)
>        refers to a specifically named address book, as defined by the
>        implementation.  A user might, for example, have access to a
>        number of different address books, such as a personal one, a
>        family one, a company one, and one for the town where the user
>        lives.
>
>        The extension information (the "extensions" element in the ABNF
>        above) is available for use in future extensions.  It might allow
>        for things such as dynamic subsets of an address book (for
>        example, "addrbook:personal?name.contains=fred").  There are no
>        extensions defined at this time.

In "Encoding considerations:" in section 4.3:
NEW
>        In particular, note that implementations MUST properly implement
>        URI processing, including percent-encoding.  Any comparisons,
>        lookups, and so forth are done after all decoding of the URI.

In "Intended usage:" in section 4.3:
Remove the word "internally" in the first sentence, and add
"case-insensitive" in the second paragraph.

In "Interoperability considerations:" in section 4.3:
OLD
<        Applications are only REQUIRED to
<        support "ab:default".
NEW
>        Applications are only REQUIRED to
>        support "addrbook:default", where all cases and encodings of
>        "default" are considered equivalent.  Address book names other
>        than "default" MAY be case-sensitive, depending upon the
>        implementation, so their case (after URI decoding) MUST be
>        maintained.
========================================================