Barry Leiba wrote:
>I'm about to submit an -03 version of external-lists, which we would
>presumably do WGLC on. This version will resolve PSA's issues, and
>also Kristin Hubner has provided me with a couple more examples
>off-list (thanks, Kristin!), which i've included.
>
>Before I post it, I need to know what the result of the discussion
>below (about comparators) is, in relation to updates to the document.
>What, if anything, needs to be added to the document about
>comparators?
>
>
Right. I am not entirely clear where we stand on this issue.
>For reference, I'll attach the impending -03 version.
>
>
This looks good to me. The only other outstanding issues are:
1). ManageSieve capability for discovering support for different types
of external lists. I will suggest some text.
In regards to discovering what external lists are available, maybe I'm
missing something, but I'm not seeing how this is substantially different
from the problem of knowing what notification methods are availabe to
a script.
If this is an apt comparison, then it would argue for some sort of
valid_external_list test, wouldn't it?
2). Add a tag: personal addressbook as mandatory to implement (as per
discussion in Spring 2010). Are people happy with using "tag:pab"?
I agree that having a standard name for the user's own personal address book is
a good idea. But the problem with tag:pab is it's not a valid tag: URL. The
authority and date fields are required in tag: URLs; you cannot omit them.
If I'm understanding the theory of tag: URLs correctly, the proper way to do
this would be to "mint" this in a namespace the IETF controls. So you'd end up
with something like tag:ietf.org,2010:pab. (Note that with tag: URLs the
"authority" associated with the authority name refers to control over that part
of the namespace. It doesn't imply only that authority can resolve that tag:
URL.)
But ever since they were first suggested my problem with tag: URLs has been
that they are butt-UGLY. Having to remember a specific date in order to
construct the right URL? Please! Nobody wants to do that, even if you cut it
down to the minimum required fields.
So I think it's quite telling that the minute we want to mint a specific tag:
URL ourselves for use in the specification, we immediately wanted to toss those
pesky syntax rules out the window. And if we're going to do that, I can
assure you that others are going to feel the same way.
So, in the specific case of identifiers for well known list constructs like
pab, I think the right thing to do is use simple alphanumeric identifiers and
set up an IANA registry for them. The initial contents of the registry would
be "pab" for personal address book access. The rule would then be that
a registered name SHOULD be used preferentially over tag: URLs if the
semantics fit.
I wish I had a suggestion for replacing tag: URLs for general use, but I don't.
They're a poor fit to this application, but other URL schemes are poorer. What
we actually want is something that looks like cid: or mid: syntactically, but
with tag: URL semantics.
This
is going to be a bit of a special case, because it is not going to use
the recommended prefix, but I think we should use an exception in this case.
If by "prefix" you mean the taggingEntity stuff, it's required, not
recommended.
My one other issue with external lists is the inability to return properties
associated with the match. I've suggested previously that we reuse the paradigm
of :matches and variables for this - after a match ${0} is set to the thing
that matched, and ${1} and so on get set to properties in a list-specific
fashion. An implementation that doesn't want to support lists with properties
is free to see ${0} and nothing else.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve