Re: [Uri-review] Request for review of "ab:" URI scheme

[Graham Klyne <[e-mail]>]

Cyrus Daboo wrote:
> Hi Barry,
> 
> --On April 26, 2011 11:17:32 AM -0400 Barry Leiba 
> <[e-mail]> wrote:
> 
>> The idea here is that an unadorned addrbook URI refers to an "address
>> book" -- that is, a set of address book entries.  Extension elements
>> can further specify that, reducing the set, or specifying individual
>> entries.  Consider (and don't worry about syntax here):
>>
>> 1. addrbook:personal
>> 2. addrbook:personal?name.contains=fred
>> 3. addrbook:personal?email=[e-mail]
>> 4. addrbook:personal?entry=314159265
>>
>> The first clearly provides a "whole book", a set of entries.  The
>> second is likely to give a set of entries, but the set could have
>> cardinality 1.  The third is likely to give a set of cardinality 1,
>> but it's possible for it to be > 1.  The fourth is specifying a single
>> entry by its unique ID.
> 
> OK, so now I am getting nervous too. What you have just sketched out 
> above is an address book access API. I think this goes way beyond the 
> scope of what was needed in SIEVE. It crosses the boundaries of a whole 
> bunch of other protocols: CardDAV, LDAP, the W3C contacts api etc. Some 
> of those already have URIs that can encode query strings (LDAP) so why 
> are we going to re-invent the wheel here?

Yeah... :)  I had some vaguely similar thought ... why not have a localhost 
option for some existing scheme (similar to file:///)?  But on a brief skim I 
couldn't make the parts line up, so became less sure that was a viable approach.

So, reinvention aside, I think what Barry sketches above is prima facie a 
reasonable approach.  If there's any real advantage to an addrbook: scheme, I 
think it is in part that it can abstract away from a particular protocol or 
mechanism and leave just the essential capabilities exposed.

#g
--