- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 8 Oct 2009 22:08:55 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-webapps@w3.org, arun@mozilla.com
On Thu, Oct 8, 2009 at 7:10 PM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 8 Oct 2009, Jonas Sicking wrote: >> > >> > - why is a new URI scheme needed? Can't you just use urn:uuid? >> >> I think we'd really like to avoid creating a new scheme if we could >> reuse an existing one. I know Arun was looking for an existing scheme, >> but not sure if he looked at the 'urn' scheme. > > I think we need a new URL scheme because otherwise we're going to end up > with really complicated origin rules (e.g. the origin of > "urn:isbn:0123..." is a unique ID, but the origin of "urn:uuid:0123..." is > the special file API origin). Reusing urn:uuid would also mean basically > hijacking the urn:uuid semantics in browsers and overriding them with > something else, such that, e.g., nobody could reuse this scheme in other > contexts if there was any risk of the context coming into contact with > brosers. Whatever scheme we're using for this feature we'll end up with a somewhat messy origin situation. The origin will always have to be on a per-uri bases, and can't be deduced from the uri alone. > And of course there's the implementation cost; APIs generally > make it much easier to implement a new scheme than to implement part of > the space created by the urn: scheme. This seems inherit to the urn scheme. I.e. anyone that implements it will have to make it pluggable on the urn-namespace level. And anyone implementing the uuid namespace will likely have to make it pluggable on a per-uuid level. So at first glance neither of these seem like a problem in Firefox. However this might be especially easy in Firefox since Gecko has its own network library. I'd be interested to get feedback from other UAs. / Jonas
Received on Friday, 9 October 2009 05:09:55 UTC