NED+mta-filters(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
I have posted a new rev of external-lists, for everyone's reviewing
pleasure. I would like to finish up this document, and there's still
a bit of a to-do list. Please, all, give it a review, and
particularly address the to-do list just below the abstract.
It looks fine, modulo the to-do list of course.
ToDo
o Do we need support for URI schemes in ihave? From IETF 77
minutes: "Can use ihave to test if a URI is valid, both that the
scheme is supported and that the URI can be retrieved/queried."
I'll again repeat that if you want to allow this in ihave, the way you
do it is to define it for require. ihave is defined to piggyback on
require - it has no independent argument of its own.
Right.
And I have a problem with allowing this in require. List validity and
accessibility is not something I can always properly check at compile time.
Agreed.
So if we want this, it really needs to be a separate test, just like it is in
notify.
I am personally happy with this. Anybody else wants to weight in?
o Do we need to say anything about comparators? We can be silent
(as now), we can say that comparators MAY be ignored as a list-
specific thing, or we can say that comparators MUST NOT be used.
My preference is to disallow the combination, but ignoring it would
also be acceptable.
I have no preferences, so let's do what you suggest, unless others have
other opinions.
o Should we add a mandatory-to-implement tag? Ned suggests (and I
agree) that it might be good to add a registry of well-defined
strings that can be used instead of URIs, and define the initial
string "pab" to represent the user's personal address book.
My thinking on this has changed - it would be better to define a pab:
pseudo-URL so there can be an argument specifying which of the user's
address books to use.
Can you think of any use for pab: URLs outside of Sieve external list?
If you can, then that would suggest that that is the best way forward.
There's one addition I'd like to make to the list. I've proposed saying
that if variables are enabled ${0} should return the thing that matched
in a :list match, just like it does for :matches. ${1} and so on would
return optional, list-specific information. In the case of pab: URLs
I'd suggest defining ${1} to be a sort of status for the entry returned.
Can you elaborate on what you mean by "status" here and how would this
work for other types of URIs?
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve