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

Morgaine <morgaine.dinova@googlemail.com> Tue, 01 September 2009 22:27 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 5A57C28C41A for <ogpx@core3.amsl.com>; Tue, 1 Sep 2009 15:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=0.176, 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 ka5LbGRAmTDW for <ogpx@core3.amsl.com>; Tue, 1 Sep 2009 15:27:18 -0700 (PDT)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 040B728C235 for <ogpx@ietf.org>; Tue, 1 Sep 2009 15:26:34 -0700 (PDT)
Received: by ey-out-2122.google.com with SMTP id 22so85648eye.51 for <ogpx@ietf.org>; Tue, 01 Sep 2009 15:26:48 -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=M+SrhB1/1QhEaz9kpudKGjaYq88V03O4b0h2McyqrTM=; b=ZP+gIBDSRKrPqj8cpNKn72QtY/TbtUnQQYr8IzVAqED+mVrBY6H54qooC6n70AY7eQ NbD/vc6tyGj0weSt4w+OmVF8k/FMPE3Yb+9/pZeuJWugGAvrj8BxQZgMoCIkTy3eLxLr tvQ5cihT+4ItJuqP9RuR1dXzGFZ2+TYr+G3v4=
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=tTCY9A6AIGq5qsxKYcEGkLxU3t1wqd5sYWbK87YeCWbmwXXD+/jEgkytrQX9BcvbWw gHrbAL8DXpUslUbLjEff/gqZS4qshTHbO91dfeeNw4w7XaXpTcIK0HTe6msJuPtHzao2 /usdTnZ5H+r1JMSc+8gGpVv9m6AH63hri750c=
MIME-Version: 1.0
Received: by 10.211.172.16 with SMTP id z16mr7858898ebo.91.1251843537326; Tue, 01 Sep 2009 15:18:57 -0700 (PDT)
In-Reply-To: <2bd5b7f10908311732v202a085awf1eecb9f67d332d6@mail.gmail.com>
References: <3a880e2c0908281127h6965f332na493007b032e5e93@mail.gmail.com> <2bd5b7f10908311207rdbc7be0ue9d69b8273e6ba4b@mail.gmail.com> <e0b04bba0908311619w52cc69e0id398691dbf8398e9@mail.gmail.com> <2bd5b7f10908311732v202a085awf1eecb9f67d332d6@mail.gmail.com>
Date: Tue, 1 Sep 2009 23:18:57 +0100
Message-ID: <e0b04bba0909011518y7aae6325gada007d7d7aa1ab8@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: ogpx@ietf.org
Content-Type: multipart/alternative; boundary=00504502d2575b587404728b8910
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: Tue, 01 Sep 2009 22:27:20 -0000

On Tue, Sep 1, 2009 at 1:32 AM, Suzy Deffeyes <suzyq@pobox.com> wrote:

>
> I've been implementing the existing OGP spec in snowglobe, and I am
> anxious to get more of the protocol designed.
>


I'm keen to get there too. !!   But sadly, we seem to have hit a speed bump,
and it seems to be a bit of a mountain. ;-)

Let me give you a run-down of recent events.

I thought it was all so simple on the 20th.  I often analyse the meaning of
specs and other texts in detail, and so there was no doubt whatsoever in my
mind when I wrote this:
http://www.ietf.org/mail-archive/web/ogpx/current/msg00171.html .  It
summarizes as "Fine, so we're just building a world from regions and doing
no interop between VWs.  No problem, let's write that down."

The language of that charter was quite unambiguous:  the purpose and role of
OGP was to add regions to an existing virtual world.  There was no mention
of interop with any other virtual world, and inclusion by non-exclusion is
not a viable method for us --- a whole universe of things would have
appeared in scope.  Consequently, the most obvious and direct meaning of the
charter was exactly the one that it stated in black and white:  that it
would deliver a protocol for building a virtual world by attaching hosts
that implement regions.

I would have preferred OGP to be a protocol for interop between virtual
worlds such as SL and OSgrid, but if that wasn't what was being planned, so
be it ---  let's build worlds with OGP and then interoperate them with some
other protocol, possibly one of the Opensim protocols.  While not ideal,
such an OGP would still be a very worthwhile protocol, and so I requested
that the "no VW interop in OGP" goal be written down clearly to define the
scope of the OGPX charter.  This would have allowed us to progress
immediately to charter agreement for a protocol that builds worlds without
providing interop between worlds.

I really didn't expect the explosion of contrary opinion that ensued from
OGP designers.

Apparently what had been written down in the charter document was not what
was intended at all, and had never been intended by OGP.  After a few days,
there was broad agreement (possibly even unanimous agreement) that OGP was
definitely intended to address "cross-world interop" --- this phrase was
used quite often.  I was surprised, but pleasantly surprised.

Unfortunately, this now meant that the charter had to be modified to express
this goal, and also to provide a deliverable that ensured that cross-world
interop was captured as a requirement, otherwise it would just be lip
service.  This is where things started to unravel again, and they got worse
throughout the week as more and more people asked questions about
cross-world interop.

On Sun 30th, Meadhbh Siobhan finally answered:

"OGPX is intended to provide interoperability, not between worlds, but
between hosts that work together to simulate a virtual world."

Hooray, clarity!

I don't think that anyone will claim that this is ambiguous.  It's extremely
clear.  Meadhbh simply confirmed that the language of the charter expressed
*exactly* what I observed on the 20th.  There is no interop between virtual
worlds intended for OGP/VWRAP, only between one world and some hosts.  Other
worlds are not even mentioned as participants in the protocol.  It's
extremely asymmetric, with one world being THE world and the connecting
hosts being treated as mere regions, not as regions belonging to peer
worlds.

So now confusion reigns supreme because there is no willingness to put such
clear language as Meadhbh wrote above in the charter, which is what I had
asked for on the 20th.  I don't mind what the protocol does, as long as
whatever it does is 100% clear.  But apparently there is extreme aversion to
allowing it to be expressed clearly, for no reason that I can understand.

If a form of expression is clear enough to deliver great understanding on
this list, it can provide the same great understanding and clarity in the
charter.

It seems logical now to propose that we use Meadhbh's words in the charter
and make it 100% clear that VWRAP is concerned only with growing single
worlds aymmetrically, and is not involved in peering with other worlds.

Unfortunately, we can't seem to achieve that, so we're back to defining
"virtual world". :-(

Defining "virtual world" is quite a simple matter as long as one is not
wedded to prior wording.  Some of us have proposed clear and unambiguous
ways of doing so, for example as a set of services that provide VWRAP
endpoints.  Unfortunately these proposals have been dismissed or not even
addressed, and instead of discussion all there has been is restatement of
the original form of words that created so much confusion.

Several questions about scope have been asked by contributors who would like
VWRAP to interoperate between SL-like worlds.  Instead of being given clear
answers (about *mechanism*, not about policy) which would have defined the
scope of the group nicely, these questions have been mostly evaded.  I don't
know why.  It's not a hard problem.  The solution appears to elude us
however, as there is no expressed willingness to modify the original form of
words in response to the feedback from this group.

How this is going to be resolved I don't know.   However, I do believe that
this is *a group effort*, and *NOT* the imposition of a standard by one
party and rubberstamping by the rest.

Given this, I look forward to general acceptance that the current wording
requires substantial modification, because it has proved to be undefined,
imprecise, refuses even to mention the concept of interop with other virtual
worlds, and hence it is only minimally intelligible to an audience expecting
cross-world interop.

So you see Suzy, we are in a very poor position here currently.  It stems
largely from unwillingness to accept that the original language of OGP, *which
made sense* for extending a world with additional regions, *no longer makes
any sense* when discussing interop between more than one virtual world.
Until this is resolved, we don't really have the basis for a logical
charter.

Alternatively of course, we could simply put Meadhbh's clear words directly
into the charter and honestly state that VWRAP is a protocol for growing a
given virtual world, and not a VW interop protocol.  What I wrote on the
20th still applies.  That's the quick way forward.


Morgaine.







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

On Tue, Sep 1, 2009 at 1:32 AM, Suzy Deffeyes <suzyq@pobox.com> wrote:

> Meow Morgaine!
>
> Not sure last email went thru ....
>
> We've had some great input to the Charter, and now it feels like some
> nitting on definitions.  I think the people that find the wording
> clear are probably  just being quiet and not posting to the list, so I
> am unsure I would claim it is a 'widespread' view that the Charter is
> not clear.
>
> For purposes of defining the scope, I think we are there.
>
> I've been implementing the existing OGP spec in snowglobe, and I am
> anxious to get more of the protocol designed.
>
> Suzy Deffeyes/Pixel Gausman
> IBM
>
> On Monday, August 31, 2009, Morgaine <morgaine.dinova@googlemail.com>
> wrote:
> > Hi Suzy!
> >
> > On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <suzyq@pobox.com> wrote:
> >
> >
> > I
> > think the Charter looks good, and I support moving forward with
> > submitting this to the IETF.  I think it accurately describes the scope
> > of what we want to do, and is clear in its description.
> >
> >
> >
> > We've just spent the last 10 days or longer trying to understand the
> wording and scope, without success.  That the charter is "clear in its
> description" is sadly not a widespread view.  This is why several of us are
> trying to get the terms defined in order to add the missing clarity.
> >
> > Note that this confusion is present despite the very extensive OGP
> background within the group.  For new readers of the charter, its meaning
> will be even less clear, if not completely obscure.
> >
> > In the absense of this understanding, it is not possible to say that the
> document "accurately describes the scope of what we want to do", since we
> don't know what it describes.  The scope is currently unknown to a
> significant number of participants.
> >
> > As the charter is clear to you, perhaps you could assist in the process
> of clarification by answering some of the recent questions made to the
> list?  I am sure that this would be widely appreciated.
> >
> >
> > Morgaine.
> >
> >
> >
> >
> >
> >
> >
> > ==============================
> >
> > On Mon, Aug 31, 2009 at 8:07 PM, Suzy Deffeyes <suzyq@pobox.com> wrote:
> >
> > Hi Infinity,
> >
> > I think the Charter looks good, and I support moving forward with
> submitting this to the IETF.  I think it accurately describes the scope of
> what we want to do, and is clear in its description.
> >
> > I am ready to move to working on the protocol and implementation. Let the
> interface definitions commence!
> >
> > Suzy Deffeyes / Pixel Gausman
> > IBM
> >
> >
> >
> > On Fri, Aug 28, 2009 at 2:27 PM, Infinity Linden <infinity@lindenlab.com>
> 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:
> >
> >   *
> >
>