[ogpx] VWRAP Draft Charter: 2009 08 28 revision

Infinity Linden <infinity@lindenlab.com> Fri, 28 August 2009 18:27 UTC

Return-Path: <infinity@lindenlab.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5533A6AA1 for <ogpx@core3.amsl.com>; Fri, 28 Aug 2009 11:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YIFrtA7Wmzx9 for <ogpx@core3.amsl.com>; Fri, 28 Aug 2009 11:27:05 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 63A793A6A78 for <ogpx@ietf.org>; Fri, 28 Aug 2009 11:27:05 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 22so485118eye.51 for <ogpx@ietf.org>; Fri, 28 Aug 2009 11:27:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.7.209 with SMTP id 59mr265818wep.213.1251484028295; Fri, 28 Aug 2009 11:27:08 -0700 (PDT)
Date: Fri, 28 Aug 2009 11:27:08 -0700
Message-ID: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com>
From: Infinity Linden <infinity@lindenlab.com>
To: ogpx@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [ogpx] VWRAP Draft Charter: 2009 08 28 revision
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Aug 2009 18:27:06 -0000

okay... here's what i think we've all agreed to. i've taken the
liberty of using the VWRAP name since it seems to me we have consensus
around that name.

also note that i still have the ogpx@ietf.org email list in the
charter text, since we don't have the VWRAP mailing list up yet.

but the rest of it should be "correct" based on discussions. please
look it over and tell me if i've missed something.

-cheers
-meadhbh

Working Group Name:

  Virtual Worlds Region Agent Protocol (VWRAP)

Chairs:

  TBD

Area and Area Directors:

  Applications Area

  Lisa Dusseault <lisa.dusseault@gmail.com>
  Alexey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

  TBD

Mailing List:

  ogpx@ietf.org
  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  worlds. The protocol
permits  users  to  interact  with  each other  while  represented  as
"avatars,"  or digital representations  of the  user. Within  a single
virtual  world, avatars  exist in  at most  one location  in  a shared
virtual  space. Conforming  client  applications use  the protocol  to
manipulate and  move the  user's avatar, create  objects in  a virtual
world, interact  with other users  and their surroundings  and consume
and create media and information from sources inside and outside their
virtual world.

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.

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
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.

The protocol  should describe interaction semantics  for these virtual
worlds, 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