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

Morgaine <morgaine.dinova@googlemail.com> Thu, 03 September 2009 01:12 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 9B82B28C1A9 for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 18:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.210, 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 Drj+FpH7prwa for <ogpx@core3.amsl.com>; Wed, 2 Sep 2009 18:12:16 -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 7F86C28C183 for <ogpx@ietf.org>; Wed, 2 Sep 2009 18:12:15 -0700 (PDT)
Received: by ewy3 with SMTP id 3so1382336ewy.42 for <ogpx@ietf.org>; Wed, 02 Sep 2009 18:11:17 -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=isZDWIqsj8l67gVSYwa4GbyhvzimcoWoxGlUm3xA1so=; b=mg2R0OgHGOftZ0/bz+JQn2twDUgvd3tfnO1CiuCcg97fEUnliSXCCYm2MmjivOu9b/ wzXQY8IOegti3s8e19zMph0Ah8OWt9bEuD5yFZRUGgWdfUEJAiITS38tXyDhK5pS4uB8 eTio4tE+B+KlDYHh6mVy11UfLk/Kz/8nAUVxI=
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=gO1+zi69tF93WVbdoA3ZV3Ja5bi2pcHQwOTd/sRjCMSZUQ+VskjY1vMoKOvBmeDUcW HA5m2Xo8vzo1LoN73JzdFA4mNK8E2vsRXNORC3wjARQ6p9BmXICCR8dTq4T6dyPgPih0 Y6QZxbiMWS9hB33fZj/lM6n9oJB8dKZIaxPu4=
MIME-Version: 1.0
Received: by 10.211.128.9 with SMTP id f9mr9675859ebn.93.1251939906935; Wed, 02 Sep 2009 18:05:06 -0700 (PDT)
In-Reply-To: <f72742de0909021315k1c2c7aa4y97c1719cb9396b90@mail.gmail.com>
References: <f72742de0909021315k1c2c7aa4y97c1719cb9396b90@mail.gmail.com>
Date: Thu, 3 Sep 2009 02:05:06 +0100
Message-ID: <e0b04bba0909021805m524aebf1q2a8d021587fc07cf@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=00504502d0d46edb160472a1f9a3
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:12:17 -0000

I like this latest iteration, Joshua.

Some additional feedback follows, but this notwithstanding, I'm inclined to
give this charter a +1.

The Goals and Milestones have not actually been discussed in the group, and
therefore it is hard to state that there is any consensus on them.  As we
have been preoccupied with matters of scope and definition, that list of
proposed documents has escaped scrutiny.

Some of the document titles are not even usefully descriptive.  For
instance, "Service Establishment" could mean several things in our context,
and "Entity Identifiers" has very little meaning even to those of us with an
OGP background.

Also, I am uncertain of the significance of listing specific Goal or
Milestone documents in this WG *formation* charter.  We have only just
defined the scope of the group and have not yet examined the problem space
in detail, let alone the solution space.  How then can we know which
deliverables are relevant at this early stage, before we even know which
solutions we are describing?

Even if the list is not actually significant, if we are agreeing to move
forward with a charter that contains such a list then we should have a
reasonable understanding of what all the items cover.  A description appears
to be lacking at present.

If the Goals and Milestones actually *are* significant then of course this
matter becomes quite a lot more important and will need discussion.  The
dates I cannot comment upon, other than to say that they are premature given
that we haven't examined any protocols yet.


Morgaine.






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

On Wed, Sep 2, 2009 at 9: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
>
>