Re: HTML5 proposes introduction of new family of URI schemes

On 2012/01/20 3:00, David Booth wrote:
> On Thu, 2012-01-19 at 17:07 +0100, Robin Berjon wrote:
>> On Jan 19, 2012, at 16:51 , David Booth wrote:
>>> On Thu, 2012-01-19 at 12:47 +0100, Robin Berjon wrote:
>>>> A configuration option is not user-friendly enough, which would hurt
>>>> adoption of the Web as an application platform — providing web site
>>>> with the ability to set this up easily is good (though there may be
>>>> kinks in the current approach's security model).
>>> And that could be done by the web site offering "hints" that the user's
>>> browser could choose to use or not.  "Click here to auto-configure your
>>> browser to use Acme Web Mail as your default email client."

The difference between between configuration and opt-in is actually very 
gradual. I'd expect that browsers would expose the current settings 
somewhere in their configuration panels. Actually, Opera already has 
Tools/Preferences/Advanced/Programs, where "protocol" mailto: currently 
is linked to the executable of Eudora OSE on my machine (you can guess 
as much from the headers of this mail). Selecting "Edit", that already 
would allow me to select a webmail service, although for whatever 
reasons, only Yandex, fastmail, and are available. I didn't 
check other browsers, but I guess the situation would be very familiar.

Also, according to the current HTML5 spec, the browser is required to 
ask the user for configuration, and "Click here to auto-configure your
browser to use Acme Web Mail as your default email client." would in my 
view be a rather reasonable text for such a configuration message.

> I didn't mean to be focusing on one particular browser-website handshake
> technique over the other, since a similar handshake needs to happen
> regardless of how it is initiated or controlled.  I meant to be drawing
> attention to the larger issues of: (a) the advisability of making it
> "too easy" for web sites to make themselves URI scheme handlers;

Yes, that's why many of the current URI/IRI schemes are excluded in the 

> (b)
> whether new URI schemes are needed at all for the desired functionality;

For existing schemes, there is no need to create parallel web+ schemes.

> and (c) whether a standards group should be inventing new URI schemes
> incidentally.

Currently, nobody is inventing a new URI/IRI scheme. The only thing we 
are discussing is if it is a good idea to have a convention for *future* 
schemes, namely that those that start with web+ are usable with Web 
applications, but those not starting with web+ are not.

>>>> What's more with your solution we'd still need some form of standard
>>>> or convention for how to content of the URI (e.g.
>>>> would be transmitted to the web app.

The current HTML5 spec says how this happens: When a URI/IRI scheme is 
registered by a Web page, there is a "%s" placeholder that indicates 
where in the URI/IRI of the Web application the the URI/IRI to be 
handled goes.

As an example, for a new scheme web+acme:, and a Web application, registering with "" would mean 
that an URI of web+acme:hello would be redirected to

> I have not read the entire spec, so I may have misunderstood the intent
> of the new URI scheme.  I read this section:
> And I particularly noted this:
> [[
> Custom scheme and content handlers
>    [ . . . ]
> The registerProtocolHandler() method allows Web sites to register
> themselves as possible handlers for particular schemes. For example, an
> online telephone messaging service could register itself as a handler of
> the sms: scheme, so that if the user clicks on such a link, he is given
> the opportunity to use that Web site.
> ]]
> My understanding is that a web page could call registerProtocolHandler()
> to register a web site as a possible handlers for a particular URI
> scheme, and (if successful) thereafter when the browser attempts to
> navigate to a URI that uses that scheme, the browser would use that web
> site's handler instead of using whatever other mechanism it otherwise
> would have used.  Is that correct, or did I misunderstand the intent of
> that section?

That's correct.

> If I understood correctly, then that URI scheme is being used to trigger
> the browser's use of a special handler, though the handler was
> pre-registered earlier, so much of the browser-website handshake already
> occurred in the preregistration process.

Yes. Once you have said you want a certain Web mail application to 
handle your mailto: URIs/IRIs, then all mailto: URIs/IRIs that the 
browser sees will be handed over to that Web mail application, without 
any further confirmation needed.

>>> Sure, that's what the web site owner wants.  But that's also what every
>>> phishing site owner wants
>> Which is why there's a security mechanism involved in the first place,
>> which leads to this discussion. Any why it's useful to figure out if
>> putting that security at the URI scheme level is the right way to go.
> What other options are being considered?
> It just seems to me -- if I've understood correctly -- that what's
> really going on here is that the new URI scheme would be created
> specifically for a particular class of handlers,

That's no the case. There won't be any web+mailto. You still can tell 
your browser that you want an external application to handle e.g. 
URIs/IRIs of the web+acme: scheme.

when to my mind a URI
> scheme should be handler-neutral.  Otherwise we would be creating
> parallel universes of URI schemes (e.g., foo: and web+foo).

That's not what's intended.

Regards,    Martin.

Received on Friday, 20 January 2012 10:18:05 UTC