Re: [ogpx] VWRAP Draft Charter: 2009 08 28 revision

Morgaine <morgaine.dinova@googlemail.com> Sat, 29 August 2009 02:10 UTC

Return-Path: <morgaine.dinova@googlemail.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 883AD3A6993 for <ogpx@core3.amsl.com>; Fri, 28 Aug 2009 19:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 P19Pd-KC0cjN for <ogpx@core3.amsl.com>; Fri, 28 Aug 2009 19:10:03 -0700 (PDT)
Received: from mail-ew0-f207.google.com (mail-ew0-f207.google.com [209.85.219.207]) by core3.amsl.com (Postfix) with ESMTP id 5980A3A6823 for <ogpx@ietf.org>; Fri, 28 Aug 2009 19:10:03 -0700 (PDT)
Received: by ewy3 with SMTP id 3so905449ewy.42 for <ogpx@ietf.org>; Fri, 28 Aug 2009 19:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=UJqhj+VOcgLsHgq67EjQdU+H/x7Zaik5KqgfPeAISz8=; b=NgEJJoL61Kk/dtcNXBmMMhZbYG+XKxe4DESiHHAQr/C/J/qcjy0KF5RitS0mTNzK0s nkMM8QSBMTnHmx7fBfudG2N73P3/4MJxToIzVyIIdb1DZhm6ppplblf2IVj7yN2QzwUY ygdjCPnvE43MOMA9c0tbcgdAmk0u9RwmbhGk8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mjsxxaVxK0vQ+NJL6Mam0otpXYtbJLQAZ6vLjSbDZZUzL/zxaIkjF5RjV4rUBxPWCv XvaUQhUkcmCSZKO/13vB5jGK+P2lunBIKvigvjIM+FOLiXDzNo4fpfHBb6Tl+HwGB/xj MnQ/IH9PyFLG/06DAIHBKXoUf6aap6d1RdYtQ=
MIME-Version: 1.0
Received: by 10.211.173.6 with SMTP id a6mr2102927ebp.13.1251511806506; Fri, 28 Aug 2009 19:10:06 -0700 (PDT)
In-Reply-To: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com>
References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com>
Date: Sat, 29 Aug 2009 03:10:06 +0100
Message-ID: <e0b04bba0908281910x5c0f4e86nae0dd81f9ba9279f@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=00504502ca31a8b77404723e4cbd
Subject: Re: [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: Sat, 29 Aug 2009 02:10:05 -0000

This charter still does not mention in plain English that the group and the
protocol *will* address cross-world interop.

It is not enough to claim that cross-world interop is included through lack
of explicit exclusion.  That can lead to disputes about what was intended to
be in scope and what was not.  The charter needs to express the group's
scope clearly, that is its purpose.

What's more, because cross-world interop is the area of greatest complexity
in this work, it needs to be prominent as a deliverable.  Currently there is
not even a hint of it in the deliverables, which is a major and extremely
important omission.

Among the *Foundational Components* (the bullet list of paragraph 5), we
need a clause something like:


   - A model describing the use of the protocol for interoperation between
   multiple distinct virtual worlds and involving multiple region/agent domains
   and services.


Unless the many possible scenarios of cross-world interop are carefully
considered, the protocol has no hope of working in such scenarios.  This is
work we must do, or cross-world interop was just lip service after all.


Morgaine.





=======================

On Fri, Aug 28, 2009 at 7:27 PM, Infinity Linden <infinity@lindenlab.com>wrote;wrote:

> 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
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
>