VRML and URNs

16 August 95, 18:11 Mitra <mitra@mitra.biz>
This document is part of a collection of VRML2.0 history at http://www.mitra.biz/vrml/vrml2/mw_history.html
Revision: 18 Sept 95 - changed file ref to be a URL.

This is a straw-person document, I'd love to hear concerns and proposed changes It is a response to queries from a number of people at Siggraph who were trying to figure out solutions to a number of problems and thought URN's might be the answer

Goals

The goal of this proposal is to allow us to:

Make references to objects independant of the location of their files
Move forward in the short term without waiting for the IETF's URN group.
Not be dependant on which URN proposal the IETF adopts.
Be compatable with the IETF in the long term

URNs and Generic objects

Firstly, URNs are NOT the same thing as generic objects.

URNs are location independant pointers to the SAME file, or different representations of the SAME content.
Generic Objects are designed to handle the case of where you don't have the exact telephone, but want any telephone. This proposal doesn't address Generic objects except that they may be made easier by this.

Background

URN's are a concept that's been around almost as long as URLs. Currently there is a consensus that they should look something like:

        urn:foo.com:abc123def

where:

urn: Says this is a URN and not a Http or other kind of URL
foo.com: Says the issuing authority is foo.com - there is plenty of controversy about who how these should be assigned, but DNS names look like the best contenders.
ABC123DEF: Is an opaque string assigned by foo.com, it can be any printable ascii - and may or may not be case dependant - for now I recommend we require all URNs to be lower case, just so we win whichever the IETF decides.

The IETF could talk about this for ever, a proposal merging 3 or 4 competing ideas and meeting the formal "requirements document" was presented last October, but the IETF doesn't set timelines, so other proposals keep appearing faster than they can be debunked. Personally I wouldn't bet on IETF ever agreeing, although recent reorganisation of the working group to seperate URN's to its own group ups the odds a bit!

URN's now, and later

For this proposal to succeed we need to address three timelines:

In the short term, we cannot assume any server infrastructure, everything must be happening at the client.
In the medium term, we can assume a server infrastructure created specifically for handling some URNs in relationship to VRML.
In the long term, we can assume a global URN infrastructure, however how long this will take is anyone's guess.

Short term - client only

In the short term, we are relying on the client only, to do this, in brief, the client receives a URN as part of a WWWInline, or WWWAnchor, and then looks up in a hierarchy of tables to determine if/where it has a copy of the file.

This requires four steps:

Make WWWInline a MFString rather than SFString.
This allows a client to see a list of potential locations for an object, and use the first one available. This is generally usefull for clients that don't implement URN's since it allows multiple alternate locations for the same file - increasing reliability.
Its also usefull for the generic objects scenario, where a client can display a URL it does have cached, while waiting for the correct one to be downloaded e.g.
```
WWWInline { 
    name [ "urn:foo.com:abc126,                  # A URN for the fancy phone 
           "http://www.foo.com/fancyphone.wrl",  # Where we know there is a copy
           "http://vrml.org/generic/phone.wrl ]  # A generic version to use now
          }
```
Define a file format for resolving URNs. This format should allow easy future extension to support networked URN resolution. A typical top level URN file might look like.
```
    # We have the object library from foo.com here
    urn:foo.com:* @file:c:/objectlib/foo/index.urn
    # Maybe we have the URN cached from earlier
    *             @file:e:/objectcache/index.urn
    # Try looking in d: (the CDROM) maybe its there
    *             @file:d:/index.urn
```
Note the "@" to denote to look in that file, rather than return the file.
Lower level URN files would look something like
```
    urn:foo.com:abc123 file:c:/objectlib/foo/table.wrl
    urn:foo.com:abc124 file:c:/objectlib/foo/chair.wrl
```
Of course, a clever browser might implement its own, more efficient, binary format, but we need a common shared format.
Browsers would need to know where to go to find the top level file, e.g. by looking in the .ini file
CDRom makers would need a standard location to put a URN index of objects on their disk - I suggest index.urn in the top directory.

Medium Term - some server support

In the medium term, when we can assume some server support for this, then the client wants to be able to go across the network to resolve a URN. Retrieving a URN should be no different from retrieving a URL.

This is implemented by:

Add a network format to the URN file e.g.

    urn:bar.com:* @http://bar.com
    urn:*         @http://vrml.org

The client sends queries to the http server specified.
The server can return the document specified, (typically this will be where it holds the doc, or is a caching server)
Alternatively, the server sends back a HTTP Redirect message - typically where the server is just providing resolution services.
The client interprets the redirect message to retrieve the file from the real server.
We can add a Form-based registration processes, so that sites like vrml.org can know where certain collections of objects are available.

Long term - global infrastructure

This gives us a number of migration directions, if and when URNs become widely deployed and supported.

Implement URN resolution and/or retrieval in common caching http servers
Have caching servers, and resolution servers that implement the official URN resolution method (whatever that is).
Use the real URN standard resolution method directly from the clients

Conclusion

This document outlines a simple way to add URN support to existing clients, while retaining our options towards a really usefull URN resolution system in the future.