Subject: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs are bad, bad, bad)

From: Dr Scofield <[email-masked]>
Date: Fri, 06 Feb 2009 13:05:11 +0100

i think we need a virtual world independent way of addressing locations
in virtual worlds. Linden Labs did coin the SLURL way of doing this for
the linden lab grid --- unfortunately SLURLs don't allow us to address
locations on other grids, let alone other virtual world platforms (e.g.,
OpenSim grids).

we'd like to propose the rezzme:// URI scheme
(http://xyzzyxyzzy.net/2009/01/07/addressing-places-in-virtual-worldsor-why-slurls-are-bad/)
--- a reference implementation of a rezzme protocol handler is available
(http://forge.opensimulator.org/gf/project/rezzme/).

we've been using it to address OpenSim grids, Linden Lab main and beta
(and other) grids. the rezzme protocol handler utilizes GridInfo.

    dirk

-- 
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
SL: dr scofield ---- [email-masked] ---- http://xyzzyxyzzy.net/
RL: [email-masked] - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/

---

From: [email-masked]
Date: Fri, 6 Feb 2009 14:14:36 -0600

hmmm... my 2 cents...

Coordinates are abstract labels.  Assigning URI's to world cooddinates  
adds another layer of abstraction.  That a VWURI (virtual world  
uniform resouce identifier) is a reference to a GridInfo object is a  
start.  Note that URI's on the www have several components and all  
relate to objects of various MIME types, protocols, (http, https, et.  
al. ) and addresses within the www.  That is, a URI is an address to  
very specific objects.  a SLURL is a generic location in the context  
defined by SL.   There really are two differnt intents to these two  
very different kinds of references.  I am quite certain two kinds of  
addresses are needed.

1. A Vicinity address that anyone can use as a teleportation  
destination - like rezzme.
2. An object address that anyone can use to construct a client viewer  
from.  ...with of course new MIME types - like GEOM? and EGEOM for  
embeded geometry.  Imagine a med student entering a patient's ear...  
visiting an aural nerve .. entering the cytoplasm of the nerve...  
watching the molecules as they respond to a sound... going in the  
nerve's nucleus & replaceing a neucleotide or two... watching the  
results of his genetic surgury.  Note that EGEOM's can act as a user  
defined kind of leveling.  (use a psuedo object for outside viewing,  
and load the contents of the EGEOM for display if inside the object...  
  ala iframe)

I have to admit I haven't looked at the GridInfo structure.  But it  
sounds like it describes the content of a sim.   I.e., limited to the  
objects stored at a single CPU.  I'd prefer to use a model similar to  
the WWW where an object may be referenced by a VW page.

This idea, for example, turns out to be very useful for load balancing  
( see Mod-Rewrite for example) and obviously ... failovers... virtual  
page construction ala CGI technologies like .asp, .net, .jsp etc... etc.

And I am seeing a need to begin a wiki dictionary for this project.  I  
think it might be useful to see the URL for the dictionary at the  
bottom of each email for this list.

here's a few ideas for your darts...

HGML -- for Hyper Geometry Markup Language & as a mime type and is a  
container for other grid objects of various other MIME types.   
Obviously along the same lines as SGML & XML.

VWURI -- for VW mime types  (hmmmmm do we really need a new concept  
for this????)  Oh & btw... an HGML page that refers to an object via  
its coordinates becomes obsolete if the object is moved. Object names  
ala SL won't work since the names are not unique.  So for  
interoperability objects really do need to be refered to by their  
GUID's.  & so HGML pages then should have UUID's.. so in a sense a  
GUID becomes similar to an IP. hmmmmm - do I hear a can of worms  
opening - or an opportunity? (reverse GUID lookup?)  OR... should  
there be relative resource ID's? -- some restrictions may apply eh?   
This might end up as a requirement.

(BTW... where's the requirements document?)

VIC -- for vicinity locations that may be used for teleport  
destinations ala rezzme.  VIC might not be good though - I think in  
Swedish it means %$@#.
alternatives (VWC - virtual world coordinates) (TPC - teleport  
coordinates) (VWL for virtual world location)

VWN - virtual world node (rather than sim).

VWC - virtual world cluster

Sorry I can't write up a document... I don't even have time for this :(

BTW - thank you Dr. Scofield. Your post to the group was productive.

Quoting Dr Scofield <[email-masked]>:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 6 Feb 2009 14:51:07 -0800

right... slurl's are currently limited to the main Second Life grid. a  
scheme that allows users to reference locations in other grids (even  
other LL grids) would have more utility. if you haven't done so  
already, i would recommend looking at  some of the existing standards,  
specifically RFC3986 and RFC3305 and the documents they reference. I  
think there's some wisdom in both documents that would definitely  
apply to the conversation.

working code and experience deploying and using it is definitely good.

there is one caveat i would add, however. the utility of new URI  
schemes is often questioned, so it's probably good to define the  
verbiage for the motivation for the scheme. let me give this  
suggestion for a motivation... at some point we're going to be  
defining protocol that will include "locations in { a | the } virtual  
world" as a parameter to some service request. i would anticipate the  
question, "why do we need a new URI scheme for this? why can't we just  
provide a HTTP URL that points to a resource that provides the  
information you need?" the rebuttal(s) to this question i can think of  
would be... a) it's nice to have a URI that encodes semantics that are  
human comprehensible.. i.e. - you can look at the rezzme: URI and get  
useful information. and b) it allows you to remove the method of  
accessing the information you need from the information itself.. (i.e.  
- a rezzme: URI doesn't REQUIRE you to do a HTTP query just to get  
then info about the target location.)

and... the scheme referenced includes a form that adds the user's  
password to the URI. i can't find the exact reference at the moment,  
but i'm pretty sure this is generally a deprecated form. while  
including authentication information in URIs is useful in many cases,  
it's a huge security hole and i remember there was quite a bit of  
discussion about it a while ago.

but.. it's a great suggestion for something to include in the scope of  
the WG.. being able to uniquely identify locations in {a | the}  
virtual world will definitely be a requirement.

-cheers
-m/∞

---

From: Rodney Thayer <[email-masked]>
Date: Fri, 06 Feb 2009 15:02:22 -0800

(somebody has to say it...)

V6 address wouldn't work, right?  We're not routing packets
between worlds so that doesn't make sense, right?  But... we're
routing (stuff) between (places) and so lots of prior art, er, work,
might provide insight.  X.400 email addresses and X.500 distinguished
names come to mind.  A TLD for SL and the other virtual worlds
that are public and/or have registered names?

My point is not that SLURL-equivalents could be done in X.400 email,
rather that we should make sure this is solving a new problem...
this entire area clearly needs some standardization but before it
adds protocols it'd be nice to make sure we use the ones that apply
(and are architecturally relevant.)

Meadhbh Hamrick (Infinity) wrote:
> other LL grids) would have more utility. if you haven't done so already,
> i would recommend looking at  some of the existing standards,
> think there's some wisdom in both documents that would definitely apply
> to the conversation.
> 
> there is one caveat i would add, however. the utility of new URI schemes
> is often questioned, so it's probably good to define the verbiage for
> the motivation for the scheme. let me give this suggestion for a
> motivation... at some point we're going to be defining protocol that
> will include "locations in { a | the } virtual world" as a parameter to
> some service request. i would anticipate the question, "why do we need a
> new URI scheme for this? why can't we just provide a HTTP URL that
> points to a resource that provides the information you need?" the
> rebuttal(s) to this question i can think of would be... a) it's nice to
> have a URI that encodes semantics that are human comprehensible.. i.e. -
> you can look at the rezzme: URI and get useful information. and b) it
> allows you to remove the method of accessing the information you need
> from the information itself.. (i.e. - a rezzme: URI doesn't REQUIRE you
> to do a HTTP query just to get then info about the target location.)
> 
> password to the URI. i can't find the exact reference at the moment, but
> i'm pretty sure this is generally a deprecated form. while including
> authentication information in URIs is useful in many cases, it's a huge
> security hole and i remember there was quite a bit of discussion about
> it a while ago.
> 
> the WG.. being able to uniquely identify locations in {a | the} virtual
> world will definitely be a requirement.
> 
> -cheers
> -m/∞
>

---

From: Dr Scofield <[email-masked]>
Date: Mon, 09 Feb 2009 18:49:48 +0100

Rodney Thayer wrote:
> V6 address wouldn't work, right?
why not?
>   We're not routing packets
i tend to stay away from X.400 and X.500 DNs... in my experience they
are not really working that well in everyday settings.

[...]

    dirk/DrS