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

[Alexey Melnikov <[e-mail]>]

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

Graham Klyne wrote:

> (For the avoidance of doubt, these comments are made with my URI 
> scheme reviewer hat OFF.)
>
> 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".

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.

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

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

> In summary, in this case, I don't think the case has been made that a 
> new URI scheme is justified.
>
> #g
> -- 
>
> Barry Leiba wrote:
>
>> In the Sieve working group, draft-ietf-sieve-external-lists defines an
>> address-book URI scheme, "ab:".  See the draft, here:
>> http://tools.ietf.org/html/draft-ietf-sieve-external-lists
>>
>> We would like to get uri-review comments on the proposed scheme.
>> There's a reference to the scheme in section 2.5, it's used in the
>> examples in section 2.8.1 and at the end of the Security
>> Considerations (section 3), and it's defined and registered in section
>> 4.3.
>>
>> Thanks in advance for reviews and comments.
>>
>> Barry 
>
Best Regards,
Alexey

-- 
Internet Messaging Team Lead, <http://www.isode.com>
JID: same as my email address
twitter: aamelnikov