- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 19 Jan 2012 09:54:30 +0100
- To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
- CC: Jonathan A Rees <rees@mumble.net>, Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>, Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>
On 2012-01-19 03:59, "Martin J. Dürst" wrote: > ... > 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. > ... It appears that the only problem here is to get the URI scheme registration into the system; any browser can do that already (at least during installation, otherwise it wouldn't handle "http"). So what remains is a policy question; do you *want* a web page to be able to register new scheme handlers? Using a fixed prefix sidesteps the issue in that it creates a class of URI schemes that are easier to register for web services. What's totally unclear is what kind of schemes these would be, and why it would be OK for them to be "web" specific. I'm not saying there aren't any, but the spec doesn't provide any insight here. The example mentioned alongside with "mailto" is "web+auth", but I have no idea what this is. Best regards, Julian
Received on Thursday, 19 January 2012 08:55:17 UTC