Re: [ogpx] revised draft charter for OGPX working group

[Meadhbh Siobhan <[e-mail]>]

Dave. we're actually going for a much narrower scope. MMOX was about
what you mention, an integrated protocol for _all_ virtual worlds.
OGPX is about OGPish systems; drawing on what we learned from two
years of interop experiments with "second lifelike" systems such as
Second Life(tm), OpenSim(tm?) and arguably realXtend(tm).

the statement "The objective of the OGPX working group is to provide
an application-layer wire protocol for Virtual Worlds to enable
interoperability between applications and provide for access and
exchange with other systems on the internet such as web services,
e-mail and other information storage systems." describes the objective
of the working group and it's value add. right now in the domain of
"second lifelike" systems there are a collection of protocols (opensim
and SL are very close, realXtend a litter further away, but still
pretty close.) the work of OGPX is to get agreement amongst this set
of participants.

the charter does not detail the architecture of a OGP "compliant"
virtual world, but defers to the introduction and requirements draft.
and even then, there's some wiggle-room depending on how you want to
deploy your services. OGP defines an application layer protocol, it
does not mandate your architecture. this is analogous to the way
services are deployed for a web application. you could, if you wanted,
put the endpoints for your service on a single host (
http://www.example.com/login or http://www.example.com/chat ) or on
distinct hosts ( http://login.example.com/ or http://chat.example.com/
.) ultimately it doesn't affect HTTP.

that being said, the intro and requirements doc describes a situation
where a client application authenticates itself to a single agent
domain through which services addresses are resolved. the alternative
approach, like what is being used in hypergrid, where the client logs
into each service individually could make use of some of the
underlying primitives in OGP (capabilities, LLSD / LLIDL, OGP<->HTTP
binding, etc.) though it does sort of break the OGP trust model.

so... to answer your questions... will this permit transfer of digital
assets from one arbitrary virtual world to another? no. digital asset
transfers in OGP will be limited from/to OGP compliant worlds; OGP
won't let you transfer an object from World of Warcraft(tm) to The
Sims Online(tm) using their native protocols.

and.. will this work will permit a user to have a single, unique
presence, across multiple VW instances? no. you won't be able to login
to World of Warcraft(tm) with your Second Life(tm) username and
password using their native protocols.

what it does allow is for a digital asset access protocol to be
defined so you can have a digital assets maintained by a distinct
administrative domain and have those assets appear in a virtual world,
where the hosts that provide simulation services belong to distinct
administrative domains.

or... in OGP lingo... a client's agent domain may tell the client it's
user's assets "live" on servers operated by a third party. and that
user's avatar may rez those assets in a portion of a virtual world
being simulated by yet a different third party.

ultimately however, OGP is more about mechanism than policy. the OGP
draft specs do not disallow a client from connecting to multiple agent
domains, but the intent of OGP is that it will define a protocol that
provides a meaningful experience with a single agent domain per user
account.

clear as mud, eh?


On Mon, Jul 6, 2009 at 1:05 PM, Dave CROCKER<[e-mail]> wrote:
>
>
> Infinity Linden wrote:
>>
>> thanks to the many people who offered suggestions concerning the OGPX
>> draft charter, we now have a new revision.
>
>
> Hi.  A few questions:
>
> Although it might be implied from some comments later in the draft, the
> beginning of the draft charter does not make explicit what value-add is
> being pursued.
>
> That is,
>
>   What problems will be solved?
>
>   What will be possible after the work is done that isn't possible now?
>
>
> I'll offer some guesses, but have no faith in my understanding of things:
>
>   1.  There are multiple VW instances that exist independently and cannot
> interoperate.  This work will permit exchange of virtual objects and (...?)
> among independent virtual worlds.
>
>   2.  Currently, a user must have a distinct and unrelated presence in each
> virtual world that they participate in.  This work will permit a user to
> have a single, unique presence, across multiple VW instances.
>
>
> First, are these two statements correct?
>
> Second, will the work solve other problems or create other enhancements?
>
> Also:  A topic that's been discussed frequently is the difference between
> having a client able to access multiple servers, versus having independent
> servers directly interact.  From the draft charter, I cannot tell which of
> these will be covered or how.
>
> d/
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>