Re: [ogpx] VWRAP Draft Charter - 2009 09 01

[Carlo Wood <[e-mail]>]

Ok,... (finally, I might add)...
with this wording I can agree that we continue to form a working group.

Thanks

On Tue, Sep 01, 2009 at 03:49:13PM -0700, Infinity Linden wrote:
> Working Group Name:
> 
>   Virtual Worlds Region Agent Protocol (VWRAP)
> 
> Chairs:
> 
>   TBD
> 
> Area and Area Directors:
> 
>   Applications Area
> 
>   Lisa Dusseault <[e-mail]>
>   Alexey Melnikov <[e-mail]>
> 
> Responsible Area Director:
> 
>   TBD
> 
> Mailing List:
> 
>   [e-mail]
>   http://www.ietf.org/mailman/listinfo/ogpx
> 
> Description of Working Group:
> 
> The working group will define the Virtual Worlds Region Agent Protocol
> (VWRAP)  for  collaborative  3-dimensional  virtual  environment.  The
> protocol permits  users to interact as  digital representations called
> "avatars".  Avatars exist  in at  most  one location  within a  shared
> virtual  space. Conforming  client  applications use  the protocol  to
> manipulate  and  move  the  user's  avatar,  create  virtual  objects,
> interactd with other users  and their surroundings, consume and create
> media and information from  sources inside and outside their simulated
> environment.
> 
> Adjacent points in  virtual spaces 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  environments  may   consist  of  regions
> administered  by distinct organizations.  Regions provide  the service
> endpoints  for  interacting  with  the inhabitants  and  objects  they
> contain.  Regions uniquely  represent their  partition of  the virtual
> space (that is,  they are not a "sharding" mechanism).  The state of a
> virtual world is independent of the client applications that access it
> and may persist between user sessions.
> 
> Regions and other services implemented according to the specifications
> may be  deployed by separate  organizations with varying  policies and
> trust  domains. The  VWRAP protocol  will provide  the  mechanisms for
> these 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.
> 
> 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 region,
> 
>   * an application-layer  protocol for changing  an avatar's position,
>     including moving between regions,
> 
>   * format descriptions for objects and avatars, and
> 
>   * an  application-layer  protocol   for  identifying  entities,  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
> 
> The  protocol  should describe  interaction  semantics 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.
> 
> Goals and Milestones:
> 
>   * December  2009  "Introduction  and   Goals"  to  the  IESG  as  an
>     Informational RFC
> 
>   * March 2010  "Abstract Type System for the  Transmission of Dynamic
>     Structured Data" to the IESG as Proposed Standard
> 
>   * March 2010  "Foundational Concepts and  Transport Expectations" to
>     the IESG as Proposed Standard
> 
>   * March  2010  "Service  Establishment"  to  the  IESG  as  Proposed
>     Standard
> 
>   * July 2010 "Guidelines  for Host Authentication" to the  IESG as an
>     Informational RFC
> 
>   * July 2010  "Client Application Launch  Message" to the IESG  as an
>     Informational RFC
> 
>   * July  2010  "Simulation Presence  Establishment"  to  the IESG  as
>     Proposed Standard
> 
>   * November 2010  "Primitive Object Format"  to the IESG  as Proposed
>     Standard
> 
>   * March 2011 "Digital Asset Access" to the IESG as Proposed Standard
> 
>   * June 2011 "Entity Identifiers" to the IESG as Proposed standard
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx

-- 
Carlo Wood <[e-mail]>