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

[[e-mail]]

> 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