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
next:
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...
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.:
sieveid:addressbook:default
sieveid:calendar:vacation
...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).
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.
- 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.
Examples:
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?
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.
Barry
_______________________________________________
sieve mailing list
sieve(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/sieve