On 9/27/10 9:15 AM, Cyrus Daboo wrote:
draft-ietf-sieve-external-lists-02 - as agreed at the last meeting this
is ready for last call. That will be issued later today.
I've completed an "AD review" of that one (I'll be the sponsoring AD
because Alexey is one of the authors). Overall it looks good. Here are a
few comments...
Section 2.2 states:
The external lists are queried, perhaps
through a list-specific mechanism, and the test evaluates to "true"
if any of the specified values matches any member of one or more of
the lists.
And:
When any value is found to belong to the
list, the queries stop and the test returns "true". If no value
belongs to the list, the test returns "false".
If a test MUST return true if any value is found to belong to the list,
does that place a limit on the "list-specific mechanism" by which a list
can be queried? If so, it would be good to say that, and to describe a
bit more what we mean by list-specific mechanisms. (It's also not clear
to me how such list-specific mechanisms are discovered or advertised.)
Section 2.4 states:
A name of an externally stored list is always an absolute URI [URI].
Implementations might find URLs such as [LDAP], [CardDAV], or
[TAG-URI] to be useful for naming external lists.
URLs, or URIs?
IMHO it would be helpful for Section 2.5 to provide more examples.
Section 4 seems to imply that this document is registering a notify
Sieve extension per RFC 5435, but as far as I can see the extlists
extension is not a notification method.
Section 4 mentions both the ':list' match type and the ':list' argument
for the 'redirect' action. Are there (or could there be) any other uses
for the extlists extension?
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve