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

[Graham Klyne <[e-mail]>]

Barry,

This has moved on somewhat from my original point.  I think I'll need some time 
to review and digest the original background material and make a constructive 
response.

#g
--

Barry Leiba wrote:
>> 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
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>