With registerProtocolHandler in the web platform able to install web handling of mailto:, smsto:, tel: anywhere in the system, it's likely that "Web context" really is "system context"... there are no other apps.
I think that's the bigger implication -- the vision that the web supplants all other (network) apps; for some systems, "URLs to non-Web things" is an empty set. My understanding of Peter's survey of other specs that make reference to RFC 3987 was that there weren't any whose implementations relied on anything other than the browser to do URL/IRI resolution and processing. I wasn't sure which list to have this conversation on, so I originally just bcc'd mailing lists with a cc to www-archive (so that the mail is at least archived publicly). Larry -- http://larry.masinter.net > -----Original Message----- > From: Ted Hardie [mailto:[email protected]] > Sent: Monday, October 15, 2012 8:50 AM > To: Robin Berjon > Cc: Anne van Kesteren; Larry Masinter; [email protected]; Peter Saint-Andre > ([email protected]); Pete Resnick ([email protected]); "Martin Dürst > ([email protected])"; [email protected] > Subject: Re: URL work in HTML 5 > > On Mon, Oct 15, 2012 at 8:07 AM, Robin Berjon <[email protected]> wrote: > > > URLs to non-Web things (e.g. mailto:, smsto:, tel:, etc.) happen in Web > > contexts. Libraries written to process those in Web contexts are likely to > > be reused elsewhere. There isn't really an option to have some of this in > > Web use cases and something else outside of it. If it's used for the Web, it > > *will* leak. Probably a lot, and probably fast. > > > > I agree. But that argues that an xmpp URI seen in a jabber context > and an xmpp URI seen in a web context should be the same; or, to > re-iterate, that a fork would be harmful. Changing the URI parsing in > web contexts only is likely to be problematic because of leakage. > Avoiding that by retaining one way is my personal preference for the > way forward. But if those working on web-specific specs do not agree > and choose to fork, then we *must* mark the difference between the > contexts, or the results will be even worse. > > regards, > > Ted Hardie > > > So if interoperable processing of URLs is a goal (and I personally believe > > it is), and if it is being defined, I am not certain that there is much of a > > goal/non-goal choice to make. It's more likely a choice of getting together > > to do it, or fighting about it. > > > > -- > > Robin Berjon - http://berjon.com/ - @robinberjon
