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.
I think it needs to be in light of the fact that notify used this approach.
>> 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?
Another alternative, sugggested by Chris Newman, would be to define a special
"pab" URL type. THis way you can say pab:<foo>, where <foo> is the group
in the user's address book you want to look at.
> 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.
It has to be allowed; there are plenty of lists that don't support any
kind of property metadata.
Ned
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve