[ogpx] VWRAP Draft Charter - 2009-09-02

[Joshua Bell <[e-mail]>]

One more iteration based on some constructive off-list feedback:

* Singular / plural disagreement has been fixed where noticed

* We removed the sentence fragment that included the word "exegesis" as
several people commented it seemed awkward. It was there to support the
concept that working on sample policies was "in scope"; we instead just
clarified the sentence.

* A handful of other minor edits to improve readability and avoid jargon.

..........

Working Group Name:

  Virtual World 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 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
environment.

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:

  * 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