Hi Barry,
As I am not going to sponsor this document, let me clearly state my
preferences.
Barry Leiba wrote:
As we work on sieve-external-lists-04, I see that we still have very little
discussion on the remaining issues, which are these:
1. Do we need to say anything about comparators, and if so, what?
We can say that comparators are incompatible with the :list match type. We
could say that comparators MAY be specified, and MUST NOT cause errors, but
that a comparator will be ignored if it isn't applicable to the list in
question. Or we could just say nothing. There's been no discussion
recently that might show consensus on this.
I think we should go with whatever Ned suggested.
2a. Should we have a managesieve capabililty that lists the valid external
lists mechanisms?
I have text in the pending -04 for this, courtesy of Alexey. But subsequent
discussion makes me question whether we'll keep it.
I think this is still needed for Sieve script generators.
2b. Should we have a new test mechanism to test is a given external-list URI
is acceptable?
Ned suggests that ihave isn't really the right place for this, and wants a
new test, similar to valid_notify_method. I see his point, but this is
pushing ME back to the idea that we're getting too damned complicated here,
and we should back up and consider just letting scripts die if the
implementations don't support what they need. If you can't test the list
you want to test, what will your script do to recover?
Anyway, where are we with respect to consensus on this?
I don't see much point in agonizing over this. I personally prefer to
have the test. Maybe the script can choose to check another external
list which is supported, or fallback to a hardcoded (in the script) list.
Suggesting some specific text:
Test valid_ext_list
Usage: valid_ext_list <ext-list-names: string-list>
The "valid_ext_list" test is true if all of the external list names
in the ext-list-names argument are supported, and they are
valid both syntactically (including URI parameters) and semantically
(including implementation-specific semantic restrictions). Otherwise
the test returns false.
This test MUST perform exactly the same validation of an external
list name as would be performed by the "header :list" test.
3a. Should we have a special "pab" identifier? Should that generalize into
a registry of special identifiers?
3b. Should we instead define a "pab:" URI type? If so, what would it look
like?
I like the "pab" identifier, and the registry therein. It's much simpler,
and I'm really aiming toward simplicity at this point. But, again, we need
to have some discussion on this that involves other participants than Ned,
Alexey, and me.
I think I can live with a new pab: URI. I would rather not have
additional identifiers.
I will suggest how this URI definition might look like in a separate
email (even if we decide not to use it after all).
4. Should we be able to have the list match return properties into
variables?
This is a new thing brought up by Ned. Is this something we want to put in?
I think that would be a good idea. Albeit, I am still a bit confused on
the exact details.
The following two notes should summarize what discussion there's been on
these points:
http://www.ietf.org/mail-archive/web/sieve/current/msg04886.html
http://www.ietf.org/mail-archive/web/sieve/current/msg04889.html
I'd like to sort this out and get this draft done soon. I'm actually
getting quite weary of the fact that what started as a relatively simple
idea still seems to sprout new heads every time we poke it.
Best Regards,
Alexey
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve