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

[Barry Leiba <[e-mail]>]

> I find I'm left with a nagging worry, though.  While I agree it's not
> appropriate to try and define addrbook: URIs more richly at this stage,
> especially as part of Sieve, I fear that if they end up growing by accretion
> rather than with some coherent rationale they could end up failing to
> realize their potential utility.

Understood.  So our goal, here, is to make sure that this definition
has the right bits in it to steer things in the right direction, and
the right extensibility to allow it to go there when it needs to.

> For example, and from the top of my head, I think it could be helpful to be
> clear:
> (1) what kind of resource is identified by an addrbook: URI (a set of
> address-book entries? OR a specific address-book entry with indicated
> content?)

I tried to get to that with the update that I posted in an earlier
message, repeated here:

In "URI scheme semantics:" in section 4.3:
NEW
>        The address book name (the "addrbook" element in the ABNF above)
>        refers to a specifically named address book, as defined by the
>        implementation.  A user might, for example, have access to a
>        number of different address books, such as a personal one, a
>        family one, a company one, and one for the town where the user
>        lives.
>
>        The extension information (the "extensions" element in the ABNF
>        above) is available for use in future extensions.  It might allow
>        for things such as dynamic subsets of an address book (for
>        example, "addrbook:personal?name.contains=fred").  There are no
>        extensions defined at this time.

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.

> (2) what kind of representations one might get back on de-referencing an
> addrbook: URI (e.g. if one is placed as a link on a web page, what might one
> get by clicking on it?).  (I don't mean to specify a particular format
> here.)

I figure the browser interface has one right-click to get a set of
options, which might include opening the book (or set of entries, or
individual entry) in an address-book-browser widget or app, merging
the set of entries into another address book, exporting the book/set
(saving it locally), and so on.  I'd figure the default (left-click)
action would be the first, opening it in a browser thingy.

> (3) what other kinds of operation (other than dereferencing) might be
> appropriate for these URIs?  This is an area where I think the mailto: URI
> might not be such a great model to follow, as it some ways it sits uneasily
> with other expectations of Web architecture.  (I've tried to avoid appealing
> to Web notions up to now, but I don't think that can be completely avoided,
> as URIs *are* probably the most fundamental technical underpinning of Web
> architecture, and I do think we should try not to create additional problems
> there.)

One could imagine directly sending email, opening a chat window, or
initiating a VoIP call to a single entry, if the entry has the
appropriate contact info (addresses, phone numbers).  In this sense,
it might step on mailto, xmpp, and tel URLs, but maybe it's that it
might "contain" such URLs, and be a level of indirection to them.  But
it's sort of like on my BlackBerry: when I click the menu button on an
addrbook entry, it offers things like "call Graham; SMS Graham; chat
with Graham; email Graham".

> In particular, concerning point (3), I think that an "add to address book"
> functionality encoded within a URI would be a Bad Thing.  But allowing that
> operations like Add, Update and Delete might usefully be applied to such
> URIs

I'm not suggesting that "add to address book" would be encoded in the
URI, but that it would be something the application could do with the
URI.  I'd imagine that a good app would get user approval after
showing the user what was going to happen.

> In summary, I find myself in the slightly uncomfortable position of liking
> the potential for what an addrbook: URI scheme might offer, but fearing that
> the immediate requirement coming from the Sieve protocol has too small a
> "contact area" with the URI to meaningfully shape the URI technical
> specification to be able to achieve those goals in later developments.

Does this help with that?
Do you have suggestions about what text we could add that would make
things better?

Barry