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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Nov 2010 19:38:03 +0000

How does this look to people:

   This specification requests the IANA to register the
   "pab" URI scheme as specified in this document and summarized in
   the following template, per [RFC4395]:

   URI scheme name:  pab

   Status:  Permanent

   URI scheme syntax:

     paburi = "pab:" addrbook [ "?" extensions ]

     addrbook = segment
                ; <segment> defined in [RFC3986]

     extensions = query
                ; <query> defined in [RFC3986]

   URI scheme semantics: "pab" URIs are used for designating references
      to personal address books. A personal address book is an internal
      concept used by different applications (such as Sieve interpreters)
      for describing a list of named entries, and maybe translated into
      other types of address books, such as LDAP Groups.

   Encoding considerations:  Percent-encoding is allowed in "segment"
      and "query" components.  Internationalization is handled by IRI
      processing.

   Intended usage:  An "pab" URI is designed to be used internally by
      applications for referencing address books.

   Applications and/or protocols that use this URI scheme name:
      Currently only Sieve External List extension is using this URI scheme.
      Email clients that use URIs internally might find this URI scheme
      to be useful as well.

   Interoperability considerations:  Applications are only REQUIRED to
      support "pab:default".

   Security considerations:  Applications SHOULD ensure appropriate
      restrictions are in place to protect sensitive information that
      might be revealed by "pab" URIs from access or modification by
      untrusted sources.

   Relevant publications:  RFCXXXX

   Contact:  Sieve IETF WG

   Author/Change controller:  IETF

?

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 30 Nov 2010 15:14:41 -0500

Hi Alexey,

>    the following template, per [RFC4395]:

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

If we do stick with it, then:

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"?

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

-- 
Cyrus Daboo

---

From: Barry Leiba <[email-masked]>
Date: Tue, 30 Nov 2010 17:28:35 -0500

Oy.  I have mixed responses to this one.

> So I am not convinced we should have this URI scheme (though that is not a

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...

> 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).

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