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

[Graham Klyne <[e-mail]>]

Barry,

OK, I think I'm starting to see the _potential_ wider benefits here.  Your 
thoughts about "more richly" parallel those I was having, and I see that 
interchangeability with LDAP, CalDAV, etc. has real potential value.

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.

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

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

Another point about which I worry is the potential mismatch between being able 
to use such URIs as part of the process of, say, adding an entry to an address 
book, and in a context that allows "any URI that can be considered to resolve to 
some sort of list".  (But this maybe a probhlem for the Sieve protocol, not the 
proposed URI scheme.)

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.

#g
--


Barry Leiba wrote:
> Hi, Graham.
> 
>> I didn't really see any technical case above.  (Though I could imagine a
>> more richly defined addrbook: URI having utility on a scale to compare with
>> mailto: - from my perspective, SIEVE looks like a fairly narrow use-case,
>> though maybe I misunderstand the context of expected SIEVE usage.)
> 
> The "more richly" is the reason for the extension stuff after the "?".
>  We anticipate other uses of it, which will add refinement and
> details, but we don't have those to hand now, so we're leaving them to
> be defined later.  Browser-based applications that access online and
> offline address books could likely use these, for example.  Things
> like "add to address book" links might be very useful.
> 
>>> The main issue for Sieve uses cases is that Sieve scripts can be typed by
>>> users manually (using a normal text editor), not all Sieve scripts are
>>> generated by special UIs. For manual editing URIs should be short(ish) - in
>>> order to avoid typing long strings and risking introducing errors. This was
>>> the main reason for not choosing URNs.
>> FWIW, This is the argument I find hardest to dismiss.  As in so many of
>> these discussions around URIs, the core issues are often social, not
>> technical.  I can imagine alternative approaches, but without better
>> understanding the context of intended use it would be rash of me to push
>> alternative designs.
>>
>> So here's a question to start with:  in the Sieve context where you see
>> addrbook: URIs being used, do you anticipate that other kinds of URI might
>> also be used?
> 
> We do.  The document
>    http://tools.ietf.org/html/draft-ietf-sieve-external-lists-07
> suggests LDAP, ACAP, and CalDAV URIs as three likely ones.  The point
> here is that any URI that can be considered to resolve to some sort of
> list is useful here.
> 
> We had long discussions about what to use for the name that points to
> the list.  We included opaque strings (no interoperability at all), a
> registry of well-known strings, and other such.  We settled on URIs
> only after a lot of discussion... so this wasn't just a casual "OK,
> let's use URIs; next issue?" thing.
> 
> Barry
>