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

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.

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.

Better would be to use a string based on the origin (host-port combo, web+service+larry.masinter.net+80/ ) or even a GUID to name the protocol handler.  

Isn't there a CORS impact of this? Where's the security considerations written up?


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] 
Sent: Thursday, August 16, 2012 5:24 AM
To: Peter Saint-Andre
Cc: 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-01 20:37, Peter Saint-Andre wrote:
> ...

For the record: I agree with what Peter said.

In addition I'd like to remind everyone that overloading parts of the 
name this way can only be done once (there's only one prefix), and thus 
affects all future URI scheme names. So *if* we did something like this, 
it really should be done by the body responsible for scheme names (and 
that's the difference to that +xml media type suffix Maciej mentioned 
over on the HTML WG mailing list: it *was* introduced in an IETF spec).

Best regards, Julian

Received on Tuesday, 21 August 2012 14:46:15 UTC