[Top] [All Lists]

Re: [sieve] Proposed "pab" URI scheme registration for Sieve External Lists

2010-12-03 16:20:57
Barry Leiba wrote:

Oy.  I have mixed responses to this one.
So I am not convinced we should have this URI scheme (though that is not a
strong objection).

I'm not either.  I was more in favour of a registry of well known
names, which could be used instead of URIs.  Then "pab" would be one
(the only one, for now).  Of course, that doesn't address what comes
1) Since you have broadened the scope to "applications" in general, why does
this have to remain a "personal" reference? What about shared or global
address books available to the application. i.e. shouldn't this be "ab"
rather than "pab"?

The usual term I know is "nab", for "name & address book", and, yes,
now that you mention it, I'd rather be more general...
I am not particularly stuck on "pab" versa "ab" versa "nab" (or whatever people want to use). But I would like to suggest that the prefix should be short.

2) I wonder if we want to be more generic - not just address books (e.g. I
could easily imagine a SIEVE system looking at my calendar to determine
possible vacation times automatically - i.e. it would be nice to just add an
all-day event to a special "vacation" calendar and have that automatically
turn on SIEVE vacation for that day). So if we stick with a URI, why not
target it specifically at sieve, but allow for different types, e.g. have a
'sieveid' scheme that can be used to represent any external "system"
identifier needed in a SIEVE script. The syntax could include a type
specifier as the first item, e.g.:


...but not THAT general.  Now we're getting back to the original
proposal of, essentially, locally understood names.  Maybe my desire
to have interoperable list names is just doomed to failure (because,
as we've said, the "tag" URIs don't really help this either).

I tend to agree. Besides, URIs are relatively cheap to make.

Ned's point on the "pab" URI (as opposed to just a "pab" item in a
registry) was that it could be used beyond Sieve, though he doesn't
really have a use case right now.  Cyrus's approach, above, moves us
back to being Sieve-specific.  Which way to go?

I think our best bet to satisfy your (Cyrus's) desire, here, is to go
with the registry idea.  How's this, just as a stab?:
- The list name can be a URI *or* a registered name.

I don't like this being in the same slot. (I almost feel strongly about that) It has to use a different tagging argument (:list versa :list-local or whatever).

- The syntax of the registered name is "name;attr;attr;attr", where
there can be any number of "attr" (including none, in which case it's
just "name" (or does "name;" work better for parsing?).
- When a name is registered, the registration includes a list of
attributes for that name.
- Extensions can add attributes to existing names, as well as adding new names.

  nab;personal   -- the user's default personal address book,
mandatory to implement
  nab;personal;name=home   -- an alternative personal address book
  nab;organization;name=SieveWorkingGroup  -- a shared, group address book

Then, if you want to register a calendar name, you might have
something like this:
  cal;personal;filter=vacation  -- matches dates that have entries
tagged "vacation" on them

...or whatever.  And that can be done in an extension.

Or is that whole idea cockamamie?
I think you are reinventing URNs all over again. I know URIs are not always pretty, but they mostly work for our purposes.

However we resolve this, it's a very basic problem that we've been
wrestling with since the day Alexey proposed external lists in the
first place: we want an easy way to specify the list names, and we
want them to have as much of a chance at being portable (as we move a
script from one implementation to another) as is reasonably possible.
I think that means using well-known names as much as we can.
The hardest part is to argue about syntax, as usual ;-).

sieve mailing list

<Prev in Thread] Current Thread [Next in Thread>