* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Vwrap Status Pages

Virtual World Region Agent Protocol (Concluded WG)
App Area: Barry Leiba | 2009-Sep-29 — 2011-May-19 

2011-04-28 charter

Virtual World Region Agent Protocol (vwrap)


 Current Status: Active

     Barry Leiba <barryleiba@computer.org>
     Joshua Bell <josh@lindenlab.com>

 Applications Area Directors:
     Pete Resnick <presnick@qualcomm.com>
     Peter Saint-Andre <stpeter@stpeter.im>

 Applications Area Advisor:
     Peter Saint-Andre <stpeter@stpeter.im>

 Mailing Lists:
     General Discussion: vwrap@ietf.org
     To Subscribe:       vwrap-request@ietf.org
     Archive:            http://www.ietf.org/mail-archive/web/vwrap/current/maillist.html

Description of Working Group:

  The working group will define the Virtual World Region Agent Protocol
  (VWRAP) for a collaborative 3-dimensional virtual environment. The
  protocol permits users to interact as digital representations called
  "avatars". An avatar exists 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,
  interact with other users and their surroundings, consume and create
  media and information from sources inside and outside their simulated

  A virtual space can be partitioned into "regions" to facilitate the
  computational and communication load balancing required to simulate
  the virtual environment. A region provides the service environment in
  which inhabitants and objects can interact. A region uniquely
  represents a partition of the virtual space; they are not a mechanism
  for load balancing by having multiple instances of the same space.
  Different regions may be administered by different organizations. The
  state of a virtual world is independent of the client applications
  that access it and may persist between user sessions.

  Within a VWRAP virtual environment, services may be deployed by
  multiple organizations having varying policies and trust domains. The
  VWRAP protocol will provide the mechanisms for these services to
  interoperate, when permitted by policy. The working group may document
  examples of policies applicable to a VWRAP environment.

  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:
  Feb 2010 - 'Introduction and Goals' to the IESG as an Informational RFC
  Feb 2010 - 'Abstract Type System for the Transmission of Dynamic Structured Data' to the IESG as Proposed Standard
  Jun 2010 - 'Foundational Concepts and Transport Expectations' to the IESG as Proposed Standard
  Jun 2010 - 'Client Application Launch Message' to the IESG as an Informational RFC
  Oct 2010 - 'Trust Model and User Authentication' to the IESG as Proposed Standard
  Oct 2010 - 'Voice and Text Communication Channel Establishment' to the IESG as Proposed Standard
  Feb 2011 - 'Agent Presence Establishment' to the IESG as Proposed Standard
  Feb 2011 - 'Region Description Format' to the IESG as Proposed Standard
  Jun 2011 - 'Digital Asset Access' to the IESG as Proposed Standard
  Jun 2011 - 'Primitive Object Format' to the IESG as Proposed Standard
  Oct 2011 - 'Avatar Format' to the IESG as Proposed Standard
  Oct 2011 - 'Entity Identifiers' to the IESG as Proposed Standard
  Feb 2012 - 'Time Sensitive Messages' to the IESG as Proposed Standard

All charter page changes, including changes to draft-list, rfc-list and milestones:

Generated from PyHt script /wg/vwrap/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -