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

From: [email-masked]
Date: Wed, 01 Dec 2010 11:37:30 -0800 (PST)

> How does this look to people:

I like it!

				Ned

>    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

> ?

> _______________________________________________
> sieve mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sieve

---

From: Tony Hansen <[email-masked]>
Date: Wed, 01 Dec 2010 17:13:47 -0500

Does anyone else feel like "pab" should be spelled out more, like 
"persaddrbook"? I keep wondering what the pabulum protocol is.

     Tony Hansen

---

From: [email-masked]
Date: Wed, 01 Dec 2010 21:12:25 -0800 (PST)

> "persaddrbook"? I keep wondering what the pabulum protocol is.

I can't say I like persaddrbook much. If you want a longer name,
how about addressbook: ?

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Dec 2010 21:18:17 +0000

Cyrus Daboo wrote:

> Hi Alexey,
>
> --On November 30, 2010 7:38:03 PM +0000 Alexey Melnikov 
> <[email-masked]> wrote:
>
> 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"?

I am not wedded to the name, as long as it is 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.:
>
> sieveid:addressbook:default
> sieveid:calendar:vacation

I think people complained about length (the same comment was made about 
URNs). I think these should be short, otherwise we might as well keep 
using tag:.

To be frank I am not convinced about usability of generic Sieve URIs. I 
would rather have 2 different URI schemes that are easy to explain, then 
a one combined.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 03 Dec 2010 21:21:01 +0000

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

---

From: Tony Hansen <[email-masked]>
Date: Fri, 03 Dec 2010 20:16:03 -0500

> I can't say I like persaddrbook much. If you want a longer name,

Seems like there are two conflicting desires: keep it short, and make it 
meaningful.

I think "pab", "ab" and "nab" are too short -- others feel they're just 
right.

No one else spoke up in support of a longer name, though. So unless 
there's more support for something longer like "addressbook" or 
"addrbook", I'll withdraw the suggestion.

     Tony

---

From: Cyrus Daboo <[email-masked]>
Date: Fri, 03 Dec 2010 23:19:15 -0500

Hi Tony,

> "addrbook", I'll withdraw the suggestion.

Often I use the abbreviation "adbk" in source code. Yet another choice 
perhaps...

-- 
Cyrus Daboo