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

NED+mta-filters@mauve.mrochek.com Sat, 23 October 2010 03:59 UTC

From: NED+mta-filters@mauve.mrochek.com
Message-id: <01NTD959BSSI000CVY@mauve.mrochek.com>
Date: Fri, 22 Oct 2010 20:28:15 -0700
In-reply-to: "Your message dated Thu, 21 Oct 2010 15:06:12 -0400" <AANLkTi=1Bg2ks3iCZBRO6AZU6Mewg-s7bfOGQJ1edB=m@mail.gmail.com>
MIME-version: 1.0
Content-type: TEXT/PLAIN
References: <4C500AB3.7040808@rename-it.nl> <01NQ4OHCU1HE00004A@mauve.mrochek.com> <18437_1280824505_o738Z4AF020978_4C57D4A6.1080902@rename-it.nl> <E6ACF2B10BCC81BCB369A119@minbar.fac.cs.cmu.edu> <4C584DD1.8070205@rename-it.nl> <4C5938A1.9050909@isode.com> <01NQAM2295HU000CVY@mauve.mrochek.com> <AANLkTiki8YH-7wCvkaaj2j9nyUiWJ6+OxMM-5F4BwGhs@mail.gmail.com> <4CB817E6.1020204@isode.com> <01NT5NV377QC000CVY@mauve.mrochek.com> <4CBFFEBF.10709@isode.com> <AANLkTi=1Bg2ks3iCZBRO6AZU6Mewg-s7bfOGQJ1edB=m@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>, Ned Freed <ned.freed@mrochek.com>, Sieve mailing list <sieve@ietf.org>
Subject: Re: [sieve] Question about draft-ietf-sieve-external-lists-02
Precedence: list

> >> 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 was one who was very much against using opaque strings, and pushed
> for URLs, for interoperability reasons.

But if interoperabiity/portability is your goal, I'm not sure tag: URLs
buy you much over opaque strings.

> Note that my objection was to
> *opaque* or implementation-defined strings.  I have no problem at all
> with Ned's suggestion of a registry of *well defined* strings that can
> be used in addition to URLs.  In fact I think a list of well defined
> strings is the *best* answer to the whole list issue for probably 90%
> of the use cases (many of which involve the PAB).

So the question becomes, should we (a) Set up a registry for these well defined
strings, or (b) Define a pab: URL type. The former is a little simpler and
generalizes to non-pab applications, the latter gets us  support for checking
memoership in pab groups.

I think (b) is the better bet, mostly because I agree that pab is the main
use case.

I've also been thinking about the issue how to test to see if a given
list is available. I know of three proposals: (a) environment, (b) ihave,
or (c) a new test along the lines of valid_notify_method.

Using environment for this is problematic. Here's why:

    require ["environment", "extlists", "variables"];
    if environment :matches "extlists" "*foo*" { ... }

Now suppose you have an MUA implementation that allows lists to be defined
using arbitrary LDAP URLs. How could such an implementation possibly
implement the above test? And what value would ${0} be set to on a successful
test result?

The problem here is fundamental: Environment, by it's nature, depends on
implementations being able to enumerate the value(s) of the environment item.
That's not possible in general for extlists, and we definitely don't want to
require that it be possible.

    require ["environment", "extlists", "variables"];
    if environment :list "extlists" "nice-lists" { ... }

Checking to see if a member of list of lists is listed  on a list of lists... A
bit too Cantorian for me!

Now, I suppose we could say that the only MATCH-TYPE for this environment item
is :is. But I'd really rather not impose such an arbitrary restriction just to
ram this into environment; it's grotty.

Ihave avoids this particular problem but has other issues. In particular, ihave
is designed so it can checked at compile time. (And even if ihave isn't done at
compile time, require is, and require and ihave accept the same arguments by
definition.) So if we defined, say, an extlist-URL convention, it would buy us
into some ihave tests occuring at compile time and others at run time. I really
don't like this inconsistency - this stuff's behavior is already tricky enough.

I therefore believe that a separate test is the best approach.

				Ned

[sieve] Question about draft-ietf-sieve-external-… Stephan Bosch
Re: [sieve] Question about draft-ietf-sieve-exter… NED+mta-filters
Re: [sieve] Question about draft-ietf-sieve-exter… Stephan Bosch
Re: [sieve] Question about draft-ietf-sieve-exter… Jeffrey Hutzelman
Re: [sieve] Question about draft-ietf-sieve-exter… Stephan Bosch
Re: [sieve] Question about draft-ietf-sieve-exter… Alexey Melnikov
Re: [sieve] Question about draft-ietf-sieve-exter… Alexey Melnikov
Re: [sieve] Question about draft-ietf-sieve-exter… NED+mta-filters
Re: [sieve] Question about draft-ietf-sieve-exter… Barry Leiba
Re: [sieve] Question about draft-ietf-sieve-exter… Alexey Melnikov
Re: [sieve] Question about draft-ietf-sieve-exter… Alexey Melnikov
Re: [sieve] Question about draft-ietf-sieve-exter… Barry Leiba
Re: [sieve] Question about draft-ietf-sieve-exter… NED+mta-filters
Re: [sieve] Question about draft-ietf-sieve-exter… Alexey Melnikov
[sieve] PAB/GAB ; Was Re: Question about draft-ie… Derek Diget
Re: [sieve] Question about draft-ietf-sieve-exter… NED+mta-filters
Re: [sieve] Question about draft-ietf-sieve-exter… Barry Leiba
Re: [sieve] Question about draft-ietf-sieve-exter… NED+mta-filters