Subject: Re: [mmox] mmox Digest, Vol 1, Issue 7

From: "Patrick N." <[email-masked]>
Date: Fri, 6 Feb 2009 17:43:38 -0500

There is an interesting concept that is pretty much the same as SLURL's for
OpenSim right now available in beta.

You can find more information here:
http://lab.newworldgrid.com/index.php/OSURL

The way they have the URL is like this:
http://osurl.org/grid.newworldgrid.com:8002/Faelwen/128/130/50

I personally think it is a good start and maybe it could work also with SL
Urls.

SL: Patnad Babii

--------------------------------------------------
From: <[email-masked]>
Sent: Friday, February 06, 2009 4:04 PM
To: <[email-masked]>
Subject: mmox Digest, Vol 1, Issue 7

> Send mmox mailing list submissions to
> [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/mmox
> or, via email, send a message with subject or body 'help' to
> [email-masked]
>
> You can reach the person managing the list at
> [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mmox digest..."
>
>
> Today's Topics:
>
>   1. Re: rezzme URI scheme: addressing locations/grids (SLURLs are
>      bad, bad, bad) ([email-masked])
>   2. Re: rezzme URI scheme: addressing locations/grids (SLURLs are
>      bad, bad, bad) (Cenji Neutra)
>   3. Greetings, MMOX Charter, Scope, Activities.. (David W Levine)
>   4. Re: Work Items and Planning Documents for the MMOX BoF
>      session (Draft Charter) (Lawson English)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri,  6 Feb 2009 14:14:36 -0600
> From: [email-masked]
> Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids
> (SLURLs are bad, bad, bad)
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
>
> 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]>:
>
>> 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/
>>
>> _______________________________________________
>> mmox mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 6 Feb 2009 15:24:57 -0500
> From: Cenji Neutra <[email-masked]>
> Subject: Re: [mmox] rezzme URI scheme: addressing locations/grids
> (SLURLs are bad, bad, bad)
> To: [email-masked]
> Message-ID:
> <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> It seems unlikely to me that virtual world implementations of the
> (moderate) future will include any fixed 1-1 correspondence between
> named locations used by people and particular geographically
> distributed simulation processes (if they do, they'll soon give way to
> the more computationally efficient implementations of their
> competitors).
>
> I think we all know that LLs decision to expose an implementation
> detail like sims/regions (which correspond to a process responsible
> for simulating a fixed-size geographic area and the physical objects
> within it) in the user interface of SL as named regions, was motivated
> by the trade-off between generality for the future vs expedience and
> simplicity of development / time-to-market.
>
> So, the question is, does a location addressing scheme like
> (region-name,x,y,z) even belong in such a forward-looking standard?
> While any virtual world that employs a 2D land-area can have such an
> addressing scheme overlaid on it, I would think it isn't appropriate
> to include it at such a low level as to force other implementations
> into using such a scheme.  There exist implementations for which
> simulation resources are distributed dynamically over the entities
> that need to be simulated, rather than fixed geographic areas - as in
> SL, and for which a such a mapping may not be practical to implement
> or desirable.
>
> Obviously, the standards process has to agree on some basic properties
> of what constitutes the X in MMOX.  Is that going to imply some
> simulated 3D space?  If so, perhaps a global x,y,z is all that is
> needed (and vendors can map vendor-centric schemes over that if
> desired).  If not, and the 'space' is not constrained to physical
> space analogues at all, then perhaps dictating 'location' addressing
> schemes is outside the scope? (for example, an application agent space
> where agents move according to the interaction patterns dictated by
> the application logic wouldn't fit into a geographic scheme well)
>
> My personal preference would be that we limit the scope of the X in
> MMOX to systems that simulate some analogue of 3D physical space (not
> necessarily continuous or simply-connected).  That way, if location
> addressing is within the scope, something like a global x,y,z can be
> used and then vendors can easily map other schemes over that (or not)
> as desired.
>
> -David
>
> SL: Cenji Neutra
> --
> Apez - we make your virtual life easier
> http://www.apez.biz
>
>> Date: Fri, 06 Feb 2009 13:05:11 +0100
>> From: Dr Scofield <[email-masked]>
>> Subject: [mmox] rezzme URI scheme: addressing locations/grids (SLURLs
>>        are bad, bad, bad)
>> To: [email-masked]
>> Message-ID: <[email-masked]>
>> Content-Type: text/plain; charset=ISO-8859-15
>>
>> 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/
>>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 6 Feb 2009 15:32:24 -0500
> From: David W Levine <[email-masked]>
> Subject: [mmox] Greetings, MMOX Charter, Scope, Activities..
> To: "[email-masked]" <[email-masked]>, [email-masked]
> Message-ID:
> <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Greetings, all, quite a few familiar names going by.. For anyone who
> doesn't keep track of the RL/SL mapping you'll find me in SL under Zha
> Ewry. (Hey, you never know,
> someone might not be paying attention.)
>
> I'd like to start with some perspective on what I expect out of an IETF
> Working Group in this space, and then, follow up with several notes on
> specific issues, one per note.
>
> The reason to bring work to the IETF is to help establish it as a usable
> specification for interop between as large a community as possible. My
> personal and professional interest in this work, is not to codify the
> current state of the Linden Lab grid, or to codify the next iteration of
> that codebase. I think of the goal as parallel to one of the goals of the
> OpenSim code base itself, establishing a set of specifications from which
> a broad range of immersive, virtual spaces can be created.  If MMOX only
> addresses the concerns of Linden Lab, or the OpenSim community, or a small
> set of corporate players, I see little point in the exercise.
> OpenSim and Linden Lab have different code bases, sometimes strikingly so
> as the OpenSim community has been creative and original in solving
> problems. But, both groups share a common heritage, linked by the client,
> and shaped by Linden Lab's initial design choices. This may well be too
> narrow to fully engage the larger community.
>
> The proposed Charter that Infinity provided, is a starting point for
> discussion, and the work items are those Linden has offered to the MMOX
> effort. The point of a BOF, and using the mailing list and developing a
> charter, is to sort out what the entire community of interest thinks
> belongs in the charter, the workgroup and the work items.
>
> My hope is that we end up with a set of specifications, which define three
> broad sets of items. Low level encoding and formats specifications, and
> protocols aimed at building blocks for moving content around.  Sets of
> services, such as Inventory management, asset Storage, Messaging,
> presence, and so forth, which can be deployed in a wide variety of
> combinations to get useful effects. finally, there is a set of services
> centering around that Linden calls a region simulator, which, are in
> essence, the mechanisms used to manage a shared scene graph. Please note,
> that the current deployment of these services within the Linden Lab Grid,
> and on OpenSim grids, is one model for how a scene graph can be shared.
> The core problem, of accepting control inputs from many sources, creating
> a stream of updated states and sharing them back out to concerned parties,
> is, I believe, the nub of the problem. Many variations can be imagined,
> with more or less detail handled centrally, peer to peer simulations, and
> largely client side simulations. Our challenge is to capture a set of
> services and models which lets us describe these various implementation
> choices at the services and protocol level, and, as much as possible,
> separate deployment and implementation choices from the interoperable
> building blocks we define.
>
> I strongly encourage everyone to share news of the BOF, and of the
> proposed working group as widely as possible. While there is a clear
> danger in boiling the ocean, if we end up with too diverse a set of
> interests, I think that danger is far less than the danger of creating a
> small focused set of specifications which don't allow the majority of
> possible virtual worlds environments to interoperate.
>
> Finally, a small word on process and participation. The IETF works by
> "rough consensus" how rough, and how broad, is somewhat ill defined. It is
> not unanimity, nor is there a precise measure of what is meant by the
> phrase. My personal belief is that standards live and die by the ability
> of the working group to attract sufficient  participants to the consensus.
> Standards which unify multiple approaches and allow a diversity of
> implementations are of much higher value than ones which codify a single
> approach, no matter how well they define that approach.  The broader a set
> of participants we attract, and the broader a set of possibilities we
> enable, the more impact we can have.
>
> I don't expect that a successful IETF working group will define a set of
> specifications which maps exactly to any one implementation. I expect  we
> will, as a community, begin the process of creating a set of shared
> building blocks from which we can compose many implementations. The
> balancing acts between generality and efficiency, between learning from
> the existing code bases, and imagining better ones
> will be some of the biggest challenge we face. The goal is not  a single
> homogenous grid, but rather defining a broad set of possible virtual
> spaces, and enabling as fluid and transparent movement between them as we
> can manage.
>
>
> - David W. Levine
> ~ Zha Ewry (ISL)
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: 
> <http://www.ietf.org/mail-archive/web/mmox/attachments/20090206/bab433b5/attachment.htm>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 06 Feb 2009 14:04:08 -0700
> From: Lawson English <[email-masked]>
> Subject: Re: [mmox] Work Items and Planning Documents for the MMOX BoF
> session (Draft Charter)
> To: Lisa Dusseault <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Lisa Dusseault wrote:
>> I'm the sponsoring AD for this BOF, and I'm glad to see work on making
>> the charter more generic already.  It wasn't clear to me how
>> interested other parties besides Linden Labs were, and what they want,
>> but that's what the BOF process (not just the meeting, but also the
>> mailing list and its charter discussions ) is for.  The goal is to
>> figure out The Right Thing to do, and nothing is set in stone yet.
>> The right thing could even be more than one WG, for example.
>>
>> It's worth pointing out very early that the deadline for submitting
>> new Internet-Drafts is March 2, and there's a tradition of only
>> considering material that has been published in Internet-Drafts at
>> IETF meetings.  Thus, if there's any other material that can be put in
>> the form of an Internet-Draft and published by March 2, then that
>> document is referenced in the agenda, a lot of IETF people will read
>> that material and be better prepared for this BOF.
>>
>> In particular, people like me who haven't been involved in this area
>> will need a bit more introduction somehow.  I actually have read some
>> of this Open Grid stuff before, and yet I'm still struggling with what
>> it means for two nodes to share perceptions of things or to handoff
>> control of virtual objects.  What about trust between nodes?  What
>> about differences in how things are modeled and what metadata they have?
>>
>
> Those are hot-button questions, Lisa, due to the "live" economy that
> Second LIfe uses. There's been more discussions on those topics than
> anything else, I suspect.
>
> Here's an index to most of the discussions I'm aware of about these 
> topics:
>
> https://wiki.secondlife.com/wiki/AW_Groupies#Chat_Logs
>
> key words: permissions, perms, IP, intellectual property, content
> creation, content creators,  inventory, assets, copybot...
>
> See alsp: https://wiki.secondlife.com/wiki/Category:AW_Groupies_User_Pages
>
>
>
>> thanks,
>>
>> Lisa
>>
>> On Fri, Feb 6, 2009 at 3:41 AM, Morgaine Dinova
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>     On Fri, Feb 6, 2009 at 10:34 AM, Infinity Linden (Meadhbh S.
>>     Hamrick) <[email-masked] <mailto:[email-masked]>>
>>     wrote:
>>
>>         Hi John, Morgaine,
>>
>>         Yes. Speaking as the co-chair of the BoF, I share your
>>         concerns. The draft group charter is exactly that, a draft. I
>>         think we expect it to be modified before the WG is formed. The
>>         draft does take a very Linden-IBM perspective as those were
>>         the authors of the draft. The IETF standardization process
>>         REQUIRES consensus, so I don't think we're expecting a
>>         rubber-stamp.
>>
>>
>>     Good, that is of course what I was hoping (and expecting) to
>>     hear.  Let's make sure that the charter reflects our openness and
>>     makes our work of value to more parties than just the current
>>     participants in the SL ecosystem.
>>
>>         But, we would like to get people to submit concrete proposals.
>>         So let me ask; do you think you guys could come up with
>>         verbiage that could be inserted into the charter that would
>>         address your concerns?
>>
>>
>>     Yes, I'll try to help with this.  Getting the charter right is
>>     largely just a matter of naming the end goal and cutting out
>>     SL-specifics.
>>
>>         With respect to LLSD, there is a precedent for including
>>         vendor names in the names of drafts and RFCs. RFC2437 PKCS#1 :
>>         RSA Cryptography Specifications and RFC2040 describing the RC5
>>         cipher (RC5 stands for both "Ron's Code 5" and "Rivest Cipher 5)
>>
>>
>>     While the use of "Linden Lab" in the name is not vendor-agnostic
>>     and hence might well cause problems of adoption by your
>>     competitors (and you cannot seriously be suggesting that LL ranks
>>     alongside Rivest!), that is not the key problem with the name,
>>     which is the following.
>>
>>     LLSD is in current use inside LL/SL, and so it cannot be both that
>>     production format and a modified extensible format that we will be
>>     refining at the same time.  (It may not change, but at this stage
>>     we cannot know that.)  To use John's form of words in the LLSD
>>     context, using this established technology PRECLUDES CHANGE if we
>>     find that change is required.  After all, it is not within our
>>     scope to modify LL's current internal format.
>>
>>     Personally I would have avoided the issue by replacing all
>>     occurrences of "Linden Lab" by "Open Grid" in this Structured Data
>>     spec for MMOX as a sign that the OGP protocol is fully independent
>>     of LL, and to avoid any friction with other companies.  "Open Grid
>>     Structured Data" also happens to fit in with "Open Grid Protocol"
>>     like hand in glove.
>>
>>     Morgaine.
>>
>>     _______________________________________________
>>     mmox mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> mmox mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>
>
>
> ------------------------------
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>
> End of mmox Digest, Vol 1, Issue 7
> **********************************
>