Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision

[Carlo Wood <[e-mail]>]

On Fri, Aug 28, 2009 at 11:27:08AM -0700, Infinity Linden wrote:
> Adjacent locations  in virtual worlds accessible by  this protocol may
> be   explicitly   partitioned  into   "regions"   to  facilitate   the
> computational  and communication load  balancing required  to simulate
> the virtual  environment. Such virtual  worlds may consist  of regions
> administered  by distinct organizations.  Though these  virtual worlds
> may  be partitioned,  they  remain "un-sharded;"  all inhabitants  and
> objects  in a  particular location  in  a virtual  world may  initiate
> interaction with  all other inhabitants and objects  in that location;
> and, service  endpoint addresses  refer to at  most one  location. The
> state of  a virtual  world is independent  of the  client applications
> that access it and may persist between user sessions.

Going with the definition that "virtual world" is from the perspective
of the user (every place reachable), I think that using "a virtual world"
is less confusing, and I'd rewrite the above paragraph as follows:

Adjacent locations in a virtual world accessible by  this protocol may
be   explicitly   partitioned  into   "regions"   to  facilitate   the
computational  and communication load  balancing required  to simulate
the virtual  environment. Such a virtual world may consist  of regions
administered  by distinct organizations.         Though virtual worlds
may  be partitioned,  they  remain "un-sharded;"  all inhabitants  and
objects  in a  particular location  in  a virtual  world may  initiate
interaction with  all other inhabitants and objects  in that location;
and service  endpoint addresses  refer to at  most one  location.  The
state of  a virtual  world is independent  of the  client applications
that access it and may persist between user sessions.

(also removed the comma after 'and').

> Regions and  services implemented according to  the specifications may
> be deployed by separate  organizations with varying policies and trust
> domains.  The OGPX  protocols will  provide the  mechanisms  for these

s/The OGPX protocols/VWRAP/

> virtual world  services to interoperate, when permitted  by policy and
> shared trust  domains. To support the exegesis  of the specifications,
> the group  may define a  non-exhaustive set of  non-normative policies
> protocol participants may enforce.

s/protocol/that protocol/

> 
> The protocol  should describe interaction semantics  for these virtual
> worlds, independent of  transport, leveraging existing standards where

Idem, in order to not confuse people in thinking that the collection
of all reachable regions exists of multiple virtual worlds, I'd use
"a virtual world" here. Thus:

The protocol  should describe interaction semantics  for the regions of
a virtual world independent of  transport, leveraging existing standards where

> practical. It  should define interoperability  expectations for server
> to server  interactions as well as  client-server interactions. Though
> the  protocol  is  independent  of transport,  early  interoperability
> trials used HTTP(S) for non-real-time messages. The working group will
> define specific  features that must be replicated  in other transports
> and  will  define  the use  of  HTTP(S)  as  a transport  of  protocol
> messages.
> 
> Foundational components of the protocol include the publication of:
> 
>   * an abstract  type system, suitable for  describing the application
>     protocol in an implementation neutral manner,
> 
>   * a   security   model   describing  trust   relationships   between
>     participating entities,
> 
>   * guidelines   for   the   use   of  existing   authentication   and
>     confidentiality mechanisms,
> 
>   * an application-layer  protocol for establishing  the user's avatar
>     in a virtual world,
> 
>   * an application-layer  protocol for moving a  user's avatar between
>     adjacent and remote locations in a virtual world,
> 
>   * format descriptions for objects and avatars in a virtual world, and
> 
>   * an   application-layer  protocol   for  identifying   agents,  and
>     requesting information about them.
> 
> The protocol  defined by this  group will carry information  about the
> virtual  environment,  its contents  and  its  inhabitants.  It is  an
> application layer protocol,  independent of transport, based partially
> on these previously published internet drafts:
> 
>   * http://tools.ietf.org/html/draft-hamrick-ogp-intro
>   * http://tools.ietf.org/html/draft-hamrick-llsd
>   * http://tools.ietf.org/html/draft-hamrick-ogp-auth
>   * http://tools.ietf.org/html/draft-hamrick-ogp-launch
>   * http://tools.ietf.org/html/draft-lentczner-ogp-base
>   * http://tools.ietf.org/html/draft-levine-ogp-clientcap
>   * http://tools.ietf.org/html/draft-levine-ogp-layering
> 
> Goals and Milestones:
> 
>   * October  2009   "Introduction  and  Goals"  to  the   IESG  as  an
>     Informational RFC
> 
>   * October 2009 "Abstract Type System for the Transmission of Dynamic
>     Structured Data" to the IESG as Proposed Standard
> 
>   * October 2010 "Foundational Concepts and Transport Expectations" to
>     the IESG as Proposed Standard
> 
>   * February 2010 "Guidelines for  Host Authentication" to the IESG as
>     an Informational RFC
> 
>   * February  2010 "Service  Establishment"  to the  IESG as  Proposed
>     Standard
> 
>   * February 2010  "Client Application Launch Message" to  the IESG as
>     an Informational RFC
> 
>   * February 2010  "Simulation Presence Establishment" to  the IESG as
>     Proposed Standard
> 
>   * June  2010  "Primitive Object  Format"  to  the  IESG as  Proposed
>     Standard
> 
>   * June 2010 "Digital Asset Access" to the IESG as Proposed Standard
> 
>   * June 2010 "Entity Identifiers" to the IESG as Proposed standard

However, I remain sceptical about the lack of stressing
the importance of making interop possible as much as possible
between regions where little overlap in ToS exist, or only partial
trust exists.

Imho, the whole effort of this group is meaningless unless the end result
will make it possible for many independent parties to take part in
creating one big virtual world. The more (policy) restrictions are
*necessary* for an acceptable interop, the less this effort will
have succeeded; hence, it should be an important, of not the most
important goal of this working group!

-- 
Carlo Wood <[e-mail]>