- From: Aaron E. Walsh <aaron@mantiscorp.com>
- Date: Wed, 23 Aug 2000 14:26:18 -0400
- To: "Martin J. Duerst" <duerst@w3.org>
- CC: uri@w3.org
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: > >http://www.web3dmedia.com/urn:web3d:media:/textures/nature/grass_1.jpg > >http://www.officetowers.com/urn:web3d:media:/textures/nature/rocks_3.jpg > > 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 www.web3dmedia.com with /urn:web3d:media:..., and > www.web3dmedia.com 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 http://www.example.com/urn:web3d:media, > 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: http://www.web3dmedia.com/urn:web3d:media:/textures/nature/grass_1.jpg 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). Regards, Aaron -- --------------------------------------------------------------------- Aaron E. Walsh http://www.mantiscorp.com/people/aew/ 617.350.7119 ---------------------------------------------------------------------
Received on Wednesday, 23 August 2000 14:17:06 UTC