[Top] [All Lists]

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

2010-10-22 23:00:53
So, in the specific case of identifiers for well known list constructs
pab, I think the right thing to do is use simple alphanumeric identifiers
set up an IANA registry for them. The initial contents of the registry
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.

sieve mailing list