W3C home > Mailing lists > Public > www-tag@w3.org > January 2012

Re: HTML5 proposes introduction of new family of URI schemes

From: Graham Klyne <GK@NineByNine.org>
Date: Thu, 19 Jan 2012 10:39:18 +0000
Message-ID: <4F17F2D6.6080506@NineByNine.org>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Jonathan A Rees <rees@mumble.net>, Julian Reschke <julian.reschke@gmx.de>, "www-tag@w3.org" <www-tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>
Without knowing about the details, this seems somewhat similar to the goals 
targeted by Web Intents (http://webintents.org/).

FWIW.

#g
--

On 19/01/2012 03:10, Noah Mendelsohn wrote:
> Martin,
>
> There's something about your example that confuses me. Let's say I author a Web
> page, and to make it easy for you to email me, I include a link to
> mailto:nrm@arcanedomain.com. You read my page, and click on the link, and you've
> explained why as a (hypothetical) Webmail user you'd want your new, smart HTML5
> Web browser to invoke the Webmail Web app to compose the e-mail. If someone else
> clicks the link, then they might want that same link to open Outlook or
> Thunderbird. So far, no problem. We've got an existing scheme, it's in the
> whitelist, and each client can be configured to do what its user needs.
>
> What strikes me as important, though, is that I in composing the Web page don't
> want to know how you want your particular client to handle the links. I want to
> use a URI that's independent of the implementation technology of, in this case,
> the e-mail reader, which may in some cases be Web-based and in others a native
> client app.
>
> So my question is: why would the story be any different for other links? Don't
> we want to continue to use URI schemes that are independent of the
> implementation technology of the application? Don't we want it to be possible
> that the same link will sometimes invoke a Web-based version of an application
> and sometimes a native? That suggests to me that, rather than minting new URI
> schemes, we need to enable the use of something in the spirit of URI templates
> in the client, so that links using existing URI schemes can be directed to Web
> or native apps as appropriate. Why do we need or want web+ for this?
>
> Noah
>
>
>
> On 1/18/2012 9:59 PM, "Martin J. Dürst" wrote:
>> Hello Jonathan, Julian,
>>
>> On 2012/01/19 0:31, Jonathan A Rees wrote:
>>> On Sat, Jan 14, 2012 at 5:56 PM, Julian Reschke<julian.reschke@gmx.de>
>>> wrote:
>>
>>>> It seem<http://dev.w3.org/html5/spec/Overview.html#custom-handlers>
>>>> contains the rest of the information.
>>>
>>> Maybe it does, but it doesn't answer my question - to what problem is
>>> this a solution? Also how is it expected to play out in practice? What
>>> will the new security dialogs look like and will they baffle users
>>> like all the others do? Has anyone already implemented it?
>>>
>>> The list of 'legacy schemes' is a red flag for me. By what criteria is
>>> inclusion in the list determined? Suppose the list needs to be
>>> changed, does that require a change to the HTML specification? What is
>>> it about 'mailto', really, that causes it to be treated differently
>>> from 'http'? The word 'core' doesn't explain much to me.
>>
>> Actually, it's not too difficult to explain. And 'mailto' is really at the
>> core of it. If you use a 'traditional' email client, and you click on a
>> 'mailto' link on a Web page, then the browser makes sure this 'mailto'
>> URI/IRI is handed off to your email client, and the email client creates a
>> new mail message for you and lets you edit it.
>>
>> These days however, webmail is being used more and more. What web mail
>> users would like to have is the same facility: You click on a 'mailto'
>> link, and a new email message is created by your webmail. It's easy for a
>> webmail service to provide an URI/IRI where the 'mailto' URI/IRI can be
>> added and the result creates the new email message that you were hoping
>> for. But there's a missing piece: How to get the 'mailto' into that URI/IRI
>> automatically.
>>
>> I have to admit that personally, I'm not using webmail. But at least to me,
>> the above scenario, and the need for some additional facility, is quite
>> evident. And we probably don't want to restrict this to 'mailto' only,
>> because we don't know how technology will evolve.
>>
>> I think once we can agree that there's a need, we can look at the issues in
>> more detail. Would you agree with what I wrote above as a starting point?
>> Also, Julian, you seems to be very clearly opposed to the specific proposed
>> solution, with some serious arguments, but do you actually agree that there
>> is a need to be able to activate webmail with a 'mailto' link, and that
>> there may be similar needs for other URI/IRI schemes?
>>
>> As you are asking for a distinction with 'http', that's easy: Because http
>> is already handled by the browser, there's at least currently no need for
>> such a thing as 'webhttp' (i.e. a single web site handling all of your
>> browsing activity). But that also may not be set in stone, it may be
>> possible that in the future, some users will view all their pages through
>> facebook, and others through tor :-(.
>>
>> Regards, Martin.
>>
>>
>>> A more conservative design would be to have a single new web: URI
>>> scheme with a subscheme registry (sort of link urn:), rather than lots
>>> of new URI schemes. This wouldn't allow registering behavior for
>>> mailto:, but might mean fewer surprises and less standards innovation.
>>>
>>> Not opposed, just confused. Someone has thought about this a lot, and
>>> I don't know what they've thought.
>>>
>>>> Best regards, Julian
>>>
>>>
>>
>
>
Received on Thursday, 19 January 2012 10:40:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:44 GMT