Re: [vwrap] Status and future of the VWRAP working group

[Morgaine <[e-mail]>]

Izzy, it's truly simple, and I see that you understand it.  You have listed
a number of possible restrictions or constraints that could be applied to
limit or modify interop between worlds, but your list of questions is only
meaningful because you already understand what interop between virtual
worlds means at its most open and powerful.

You are there already in your understanding! :-)

When our protocols support such interoperation between virtual worlds,
restrictions can of course be placed on that interoperation by world
providers, just like an email service provider can place restrictions on who
can access their service, where people can send emails, the kinds of content
permitted, and so on.  It's totally normal for services on the Internet to
apply their own restrictions, and it would be no different for interoperable
VWs.

Likewise for us, we know what interoperation between virtual worlds means in
concept (I described it in simple user language in my previous email), but
any individual deployment might reduce or limit that based on local policy.
It's not up to us to mandate local policy, but it is up to us to create a
protocol that provides interoperation between virtual worlds so that it's
available for those worlds that do want to interoperate.


Morgaine.




============================

On Tue, Mar 29, 2011 at 4:46 PM, Izzy Alanis <[e-mail]> wrote:

> I'll second Mike's comment: I don’t know what it mean to have virtual
> world interop personally.
>
> Do I have to be able to teleport from one world to the next within the
> same viewer to qualify as "interop"? Or would it be OK if I was able
> to log in using different viewers/clients as long as my 'identity' was
> maintained? What if I had to have separate identities between virtual
> worlds, but could still access my bank of assets? What if I could
> maintain the concept of "identity" but not transfer assets/use a
> particular asset service? What if I couldn't access my assets from a
> particular asset service in a particular virtual world due to policy
> reasons (e.g. virtual world "A" doesn't like asset service provider
> "B")?
>
>  - Izzy
>
> On Tue, Mar 29, 2011 at 11:37 AM, Morgaine
> <[e-mail]> wrote:
> > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> > <[e-mail]> wrote:
> >>
> >> Right, so we do need to standardize “Service Level Interop”.  As has
> been
> >> pointed out its concrete enough you can actually do it and it would
> allow
> >> the assembly of virtual worlds based upon it.
> >
> > I think you misunderstood the point that I wrote, since you concluded the
> > opposite.  No, it does not follow that we need to standardize "service
> level
> > interop", because that does not give us interoperation between virtual
> > worlds.  It only allows us to standardize (as you correctly state) the
> > "assembly of virtual worlds", one world at a time, instead of
> standardizing
> > their interoperation.  We don't need to standardize how VWs are
> assembled,
> > it's not even our remit to do that because that's up to each provider.
> >
> >>
> >>
> >> I don’t know what it mean to have virtual world interop personally.
> >
> > Why?  It's very easy to understand, and I would guess that every VW user
> > today who is using two or more virtual worlds like (say) OSgrid and
> InWorldz
> > can probably describe it very eloquently.  I'll just repaste how I
> described
> > it yesterday:
> >
> >>
> >> We either have interoperability between worlds, in which an inhabitant
> can
> >> travel from one world to another and take their avatar and/or
> possessions
> >> with them, or else we don't have that.  It's black and white, and no
> amount
> >> of fudging about "service level interoperability" is going to overcome
> the
> >> lack of VW interoperability as a user would understand it.
> >
> > Interoperability between VWs is truly a simple concept, and users are
> asking
> > for it continually and woeing its absence daily.  Its lack is so clear
> and
> > self-evident and annoying that people even write export-import programs
> to
> > try to alleviate the user "suffering" through its absence.  Frankly,
> > professing not to understand what it means is very bizarre.  All I can
> > suggest is, I'll try to clarify it further for you if you still don't
> > understand what it means.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> > ===========================
> >
> > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> > <[e-mail]> wrote:
> >>
> >> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >> Morgaine
> >> Sent: Monday, March 28, 2011 8:01 PM
> >> To: [e-mail]
> >>
> >> Subject: Re: [vwrap] Status and future of the VWRAP working group
> >>
> >>
> >>
> >> Responding to two posts:
> >>
> >> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol <[e-mail]>
> wrote:
> >>
> >> If you want service only, I think there is code implemented already.
> >>
> >> Exactly as Dzonatas says.  We don't need to work on protocols for
> internal
> >> use by separate, isolated world services.  We have those already.  The
> >> ingredient that is mostly missing from the Virtual World arena is
> >> interoperability between such services, and that is the goal that has
> >> sparked extremely wide interest.
> >>
> >> Right, so we do need to standardize “Service Level Interop”.  As has
> been
> >> pointed out its concrete enough you can actually do it and it would
> allow
> >> the assembly of virtual worlds based upon it.   The point that some of
> this
> >> exists is a good one, there’s some existing practice and knowledge that
> can
> >> be leveraged.
> >>
> >> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte
> >> <[e-mail]> wrote:
> >>
> >> d. interoperability between (instances of) any two virtual world systems
> >> conforming to the (to be defined) VWRAP standard.
> >>
> >> Exactly as Boroondas says.  Indeed, that is the interoperability goal
> >> sought by the majority of contributors here over the years, so this is
> >> nothing new. It's the feature that virtual worlds don't yet have, and
> that's
> >> why it's worthwhile to work on it.
> >>
> >> Again, this is sensible and it’s achieved via the “standard services”
> >> defined above.  I don’t know what it mean to have virtual world interop
> >> personally.  It’s a nice ideal but in practice differences in policy,
> >> technology, etc, make it practically impossible to specify given the
> current
> >> state of  affairs.    We can’t even agree on a the data description
> protocol
> >> let alone how to handle policy across VW systems.  And that extends past
> >> business policy into technical issues like: if an “object”  is scripted
> how
> >> does that transfer to another VW. Who allocates the script resources.
> And
> >> of course there’s also creator’s rights vs. owner’s rights.  The list is
> >> extremely long and we can’t even agree on how services should talk and
> which
> >> there should be in a standard way.
> >>
> >>
> >>
> >> IMO, the effort should focus on Service Level interoperability and the
> >> definition of a few fundamental building block services: i.e user
> service,
> >> inventory service, asset service.  I’d leave the simulator piece off for
> >> now.  If we get those right you can start to share user information
> between
> >> “virtual worlds”, locate and access inventory and define an objects
> >> characteristics inside a simulator.  And the simulator piece can evolve
> >> until its ready to be standardized.
> >>
> >> Mike
> >>
> >>
> >
> > _______________________________________________
> > vwrap mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/vwrap
> >
> >
>