RE: web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler.

That and the security considerations, but I suppose that the security concerns are about RegisterProtocolHandler. I don't understand or see how the 'origin' sandboxing can work, since the protocol handler registry is a shared global resource.

And what does the "web+" buy, anyway? It prevents "Web+mailto" from stepping on "mailto", but it doesn't prevent "web+mailto" 1 from stepping on "web+mailto" 2. 

Whenever there's a naming convention, there needs to be some invariant that is true for things that match, otherwise the naming convention is meaningless. So what is it that you know about "web+foo:" that you don't know about "foo:" ?

Larry


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Tuesday, August 21, 2012 7:55 AM
To: Larry Masinter
Cc: Peter Saint-Andre; Philippe Le Hegaret; Barry Leiba; Mark Nottingham; public-ietf-w3c@w3.org; Edward O'Connor
Subject: Re: web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler.

On 2012-08-21 16:45, Larry Masinter wrote:
> I don't care too much about the venue question. I’m just concerned about reliability and stability of the web.
>
> I think the problem with web+XXX (if I understand the proposal, is there actually a document?) is that they're not URIs in any reasonable sense, won't work right if bookmarked, emailed, used as a URI anywhere else, or used as a "URI" rather than just some string that happens to be found in an href.

All we have is what the HTML5 spec says about registerProtocol.

And yes, I believe they are supposed to be real URIs, bookmarkable, and 
usable outside web browsers.

> And *that* problem is that the +XXX isn't globally unique, so there's an opportunity for conflict. f two different libraries RegisterProtocolHander with the same scheme, they'll step on each other.

HTML5 pretends these are URIs, so yes, uniqueness depends on the URI 
scheme registry.

> ...

Best regards, Julian

Received on Tuesday, 21 August 2012 19:41:12 UTC