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

Latif Khalifa <latifer@streamgrid.net> Thu, 03 September 2009 01:09 UTC

Return-Path: <latifer@streamgrid.net>
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 2609B28C13E for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 18:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.958
X-Spam-Level:
X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=1.020, 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 vYp7n+spxBsY for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 18:09:39 -0700 (PDT)
Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id BC2A328C10C for <ogpx@ietf.org>; Wed, 2 Sep 2009 18:09:38 -0700 (PDT)
Received: by bwz19 with SMTP id 19so1145111bwz.37 for <ogpx@ietf.org>; Wed, 02 Sep 2009 18:08:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.81.12 with SMTP id i12mr3865892mul.37.1251940111684; Wed, 02 Sep 2009 18:08:31 -0700 (PDT)
In-Reply-To: <f72742de0909021315k1c2c7aa4y97c1719cb9396b90@mail.gmail.com>
References: <f72742de0909021315k1c2c7aa4y97c1719cb9396b90@mail.gmail.com>
Date: Thu, 3 Sep 2009 03:08:31 +0200
Message-ID: <5ebce2ec0909021808p7e55a7a5t5d535ca1c63e54bb@mail.gmail.com>
From: Latif Khalifa <latifer@streamgrid.net>
To: Joshua Bell <josh@lindenlab.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 04 Sep 2009 09:14:54 -0700
Cc: ogpx@ietf.org
Subject: Re: [ogpx] VWRAP Draft Charter - 2009-09-02
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: Thu, 03 Sep 2009 01:09:40 -0000

+1

Draft charter looks good

On Wed, Sep 2, 2009 at 10:15 PM, Joshua Bell<josh@lindenlab.com> wrote:
> 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 <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 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
>
>
>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>
>