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

[Graham Klyne <[e-mail]>]

Alexey Melnikov wrote:
> Hi Graham,
> Let me try to defend my proposal and we can see if I can change your mind.

Alexey,

You provide some useful additional context, but I'm not yet fully convinced. 
But by all means let's kick this one about and see where it ends up.

>> I am reminded of recent discussions about the jms: scheme, and how 
>> appropriate it is to mint a new URI scheme for accessing information 
>> for which there is no specific access protocol.
> 
> IMHO, the issue with jms: URIs was different: there was no 
> *interoperable* protocol behind it.
> 
> I am thinking of the ab: URI scheme as similar to mailto:. For mailto: 
> there is no protocol behind it, at least there is no requirement for 
> using SMTP transaction for operating on mailto URIs. A typical operation 
> on a mailto URI is "open a mail composition window". Similarly, for an 
> ab: URI it is going to be "open the addressbook viewer window".

I note that mailto: may not be bound to SMTP, but it is pretty closely bound 
with RFC822 (et seq).

> In the last months I've seen a couple of Windows application registering 
> URIs for similar kind of API use. One application is for gift vouchers 
> for a game download application, another one for a music download 
> application. I think these are pretty similar to mailto: and ab:. If 
> these are not supposed to be legal uses of URIs, then I think IETF 
> community needs to build some consensus against that.

Ah, there's a whole discussion to have.  Maybe something to bring up in the 
IETF/W3C liaison group?  Is it appropriate to mint URI schemes to access a local 
application?  mailto: is a precedent here, but one that was established before 
many of the concerns about URI scheme profligation became more widely voiced.

At heart, it comes down to "what are URIs for?".  Off the top of my head, I suggest:
- identifying resources (all URIs do this, and addrbook: passes on this)
- in many cases, providing information that can be used interoperably to 
interact with the identified resource; often this means identifying a protocol 
and associated parameters.  mailto: seems to sit right out at the edge here, and 
is to some extent justified by its ubiquity and widespread utility.  For this, 
maybe we have to allow that not all protocols are wire protocols?

>> The fundamental problem is "The use and deployment of new URI schemes 
>> in the Internet infrastructure is costly;" 
>> (http://tools.ietf.org/html/rfc439) and "New URI schemes SHOULD have 
>> clear utility to the broad Internet community, beyond that available 
>> with already registered URI schemes." (ibid).
>>
>> As I recall, the jms: scheme was allowed because there was a 
>> significant body of usage in code, if not on the wire.  Similarly, the 
>> recently discussed about: scheme was looked upon favourably because it 
>> was essentially codifying what browsers have been doing since the very 
>> early days.
>>
>> In this case, I see no evidence of prior use to be accommodated,
> 
> That is true.
> 
>> nor do I see any *technical* reason why an existing scheme cannot be 
>> used.
> 
> I think I've tried to make my case above. But also see below for some 
> additional reasons, some of which are non technical.

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

>> As I read your document, the only *required* value is ab:default - 
>> everything else is implementation dependent.  My suggestion would be 
>> to use instead "http://ietf.org/sieve/addrbook#default" (and, as a 
>> bonus, create a web page at that address explaining what it means).  
>> The other values can be arbitrary URIs chosen by implementers.  if 
>> there is a future need for additional interoperable values, the above 
>> pattern is easily extended.  (My use of "#default" rather than 
>> "/default" is to sidestep an obscure issue of web architecture, but 
>> either could be used.)
>>
>> Some folks are uncomfortable with http: URIs that represent not just 
>> web pages, but using http: URIs in this way is now a widely 
>> established practice in web data cicrles.  If you really don't like 
>> the http: approach, other possibilities might be a urn namespace - 
>> there's already a URN namespace for protocol parameters 
>> (http://tools.ietf.org/html/rfc3553), so one might end up with 
>> something like "urn:ietf:params:sieve:default".
> 
> The Sieve WG looked at tag: URIs and URNs. (We didn't look at using 
> http:, but I do have a bit of distaste for that proposal).
> The tag: URI was almost Ok, but then the use of a fake date which has no 
> semantic meaning made us think that maybe use of a new URI scheme would 
> be better. So here we are.
> 
> 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?

#g
--