Hi Ned,
Ned Freed wrote:
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?
I thought there was an agreement (from a f-2-f meeting) not to add such
test and possible handle unsupported URI types with yet-to-be-written
exception handling mechanism in Sieve, or possibly use/extend ihave. But
of course this decision can be revisited.
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.
Good point, I haven't checked the syntax when I wrote my proposal.
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.)
Ok.
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.
Hmm. We can do that, but we already had this argument before and I
feeling we are going in circles.
What do other people think?
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.
I was talking about omitting <domain>,<date> part. You already pointed
out that that is incorrect, so ignore this comment.
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.
As long as the behavior you described in the last sentence is allowed,
that would be Ok with me.
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve