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.)
There's no reason for it to be either discovered or advertised. The
point of talking about a "list-specific mechanism" is exactly that
it's opaque, so no assumptions can be made about how it works. It's
not done with a Sieve comparison.
The "queries stop" bit was meant as a way to say that once a match is
found, the list-specific mechanism needn't keep looking at the other
values. If you think it's useful, I can change the text to say that.
Perhaps:
If any value is found to belong to the list, the test returns
"true". If no value
belongs to the list, the test returns "false". Once a value is
found in the list,
there is no need for the query mechanism to look further.
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?
Fixed; thanks.
IMHO it would be helpful for Section 2.5 to provide more examples.
More examples are always good. If anyone can give me specific
examples, I'll put them in. Unless there are implementations of this,
I don't know that we have good examples to give.
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.
No, this document is registering a Sieve extension, per RFC 5228.
It's just the word "notify" that's extraneous, and I've removed it.
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?
There aren't any we've thought of. Do you have anything in mind?
I suppose one could come up with a use case for having the target of
"fileinto" come from a list, or something like that. But (1) no one's
seen a need for that yet, and (2) it's always possible to extend this
extension in future.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve