Re: Colons in URIs (rfc2396) for Universal Media URNs in URLs

Hi Martin, thanks for your reply and confirmation that colons in the
path of URLs is legal...

"Martin J. Duerst" wrote:

> >I wonder if un-escaped colons are legal in the path portion of a URL so
> >long as they're not in the scheme or domain?
> Michael answered this one, yes they are legal (and don't need to
> be escaped).

Great. That makes our job much easier...

> >For example:
> >
> >
> These look definitely like legal URIs.
> ...
> While the syntax is okay, this may not exactly work. The above
> are http URIs, and the fact that they contain 'urn:web3d:media:'
> as one of their path components doesn't make any difference.
> For the HTML browsers, this would work out because they just send
> a request to with /urn:web3d:media:..., and
> is allowed to treat this in any way it wants
> (and may even have set up a directory named urn:web3d:media: just
> to make work easy on the server side).

Yes, that's exactly what we did (created a folder on the server named
"urn:web3d:media:", which flies on all platforms except Windows as that
OS doesn't allow colons in names).

> However, the other way round is a bit more difficult. How is VRML
> software supposed to treat this differently? Looking at the first
> path component and treating it as an URN if it starts with urn:
> is definitely wrong; it would go havoc if somebody decided to
> use something like,
> which is a perfectly good straight old http URI.

Actually that's exactly the behavior we want; products that don't know
about our URNs treat the above URL like an ordinary URL (fetch via
http), whereas VRML browsers and other Universal Media aware programs
see "urn:web3d:media:" and extract the entire URN based on the path that
follows, and resolve it locally (using http as a "fallback" if the
resource isn't already locally installed). For example:

Looks like "urn:web3d:media:/textures/nature/grass_1.jpg" to Universal
Media savvy products, but like a normal URL to all others. 

We also *want* to let anyone include "urn:web3d:media:" in their Web
URLs so that they can host the textures, sounds, and 3D objects in our
standard libraries directly from their own sites. Standard browsers
(like Navigator, IE, WebTV, etc.) just fetch the resource from the URL
(their site), whereas URN-savvy products parse out the embedded URN and
grab the local copy instead.
This allows our system to be massively scalable (anyone can host our
standard media libraries on their site by creating a folder
"urn:web3d:media:" and placing the library contents into it, taking the
load of our main server and official mirrors for all cases except when
the the URN is really used; in this case the media is either fetched 1)
locally or 2) from the official site or an official mirror).

We won't parse for anything other than "urn:web3d:media:" (notice the
three colons are required) as that is part of our naming scheme. If we
omitted the last colon, for example, and just parsed for
"urn:web3d:media" (as you have above, although I'm not sure if the last
colon was intentionally omitted?) then we could run into conflict with
future Web3D Consortium working groups (if a wg named having the
"mediaplayer" identifier in our consortium was created, for example,
they'd have "urn:web3d:mediaplayer:" -- by not including the final ":"
the parsing would be too ambiguous).

So, our intent is to give valid URLs to standard browsers, and embedded
URNs to Web3D products and other products that want to utilize our
shared, persistent cache. By intentionally encouraging end users to host
our library, using their own URLs (i.e,
http://www.mysite.xzy/urn:web3d:media:/textures/...), we distribute our
media libraries without losing the intent of our system (fetching
locally when possible, using an official site or official mirror to
install the reference element if the product is capable of doing that,
or just fetching from that user's own site in the case of standard Web
browsers and other products that don't utilize Universal Media).

Aaron E. Walsh   617.350.7119

Received on Wednesday, 23 August 2000 14:17:06 UTC