[Top] [All Lists]

Re: [sieve] Question about draft-ietf-sieve-external-lists-02

2010-10-21 03:50:32
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
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,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:


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.

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

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