Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00

David W Levine <dwl@us.ibm.com> Sun, 19 September 2010 19:54 UTC

Return-Path: <dwl@us.ibm.com>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3D23A687D; Sun, 19 Sep 2010 12:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.635
X-Spam-Level:
X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543]
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 DcLa9+FmOSU4; Sun, 19 Sep 2010 12:54:20 -0700 (PDT)
Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 105DD3A6877; Sun, 19 Sep 2010 12:54:19 -0700 (PDT)
Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o8JJsdUN009910; Sun, 19 Sep 2010 15:54:39 -0400
Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o8JJsZnX2011324; Sun, 19 Sep 2010 15:54:35 -0400
Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o8JJsYI7028995; Sun, 19 Sep 2010 16:54:34 -0300
Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id o8JJsY2i028992; Sun, 19 Sep 2010 16:54:34 -0300
In-Reply-To: <4C963C3C.9080700@ics.uci.edu>
References: <4C8660AA.4050004@ics.uci.edu> <AANLkTimqq_oZJvFMZg7sB23DbWxH6Tzhdj6o5HTVVyMZ@mail.gmail.com> <AANLkTi=GVz5ynLKYKixvvjVsyC=mHa22rzLGRj7gFiZJ@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D012669F0E0@rrsmsx506.amr.corp.intel.com> <AANLkTikNwthsbP12N=NNC6LAp4BxPp5HFagyAGZY5ezq@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D012669F0EC@rrsmsx506.amr.corp.intel.com> <AANLkTinrD99m2DavCYn0+6vHN9mi+bnNd2791P-kBruc@mail.gmail.com> <4C963C3C.9080700@ics.uci.edu>
X-KeepSent: DB7D98D0:6C0661BD-852577A3:006CF906; type=4; name=$KeepSent
To: lopes@ics.uci.edu
X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010
Message-ID: <OFDB7D98D0.6C0661BD-ON852577A3.006CF906-852577A3.006D5D5B@us.ibm.com>
From: David W Levine <dwl@us.ibm.com>
Date: Sun, 19 Sep 2010 15:54:34 -0400
X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5.1HF41 | October 22, 2009) at 09/19/2010 15:54:34
MIME-Version: 1.0
Content-type: multipart/related; Boundary="0__=0ABBFD30DFFF7F968f9e8a93df938690918c0ABBFD30DFFF7F96"
Cc: "vwrap@ietf.org" <vwrap@ietf.org>, vwrap-bounces@ietf.org
Subject: Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Sep 2010 19:54:22 -0000

The "One avatar in place" restriction touches remarkably little of the
working group's remit. I've argued against it, as it's very much a policy
proscription not a protocol design issue. Allowing an agent to project
multiple avatars into the greater grid adds very little complexity to the
collective protocols, and frankly should be a policy choice of the people
deploying the service(s).

If you look at the deploymet patterns document from last spring, you'll see
that I strongly encourage thinking of VWRAP as a set of services which can
be composed to allow many different deployments. In general, the matter of
how the services compose at run time, and which policies are applied at run
time, should be accounted for as "Do we permit people to make choices" and
"MUST we constrain this choice"  When we hit "We must constrain this
choice" I think we need to offer very strong justifications. (e.g. "If you
don't constrain this, you can't really do interpo."

- David
~ Zha



                                                                                                                                             
  From:       Cristina Videira Lopes <lopes@ics.uci.edu>                                                                                     
                                                                                                                                             
  To:         "vwrap@ietf.org" <vwrap@ietf.org>                                                                                              
                                                                                                                                             
  Date:       09/19/2010 01:05 PM                                                                                                            
                                                                                                                                             
  Subject:    Re: [vwrap] Comments	on	http://tools.ietf.org/html/draft-ietf-vwrap-intro-00                                             
                                                                                                                                             
  Sent by:    vwrap-bounces@ietf.org                                                                                                         
                                                                                                                                             





In defense of Meadhbh's position, the charter for VWRAP does, indeed,
support what she is saying, down to "a collaborative 3-dimensional virtual
environment" and "An avatar exists in at most one location within a shared
virtual space.":
http://tools.ietf.org/wg/vwrap/charters

Charters are the binding goals of working groups, I think. Hence my review
stated as "this does not reflect the goals of the OpenSimulator project,
and I don't know what to make of it." I was truly puzzled when I read the
intro doc.

But now that I thought more about, I think there's a way out of this
puzzlement. In my spectrum of requirements for clients, there is a point in
there where one assumes the existence of one, and the same, client. Let's
make this group focus on that.  We can assume, roughly, the Linden Lab
client, or some variation of it, since I think that this group does not
have representatives from other radically different viewers. The thing that
needs to be revised, I think, is the very strong interference that the
intro document makes wrt the internals of each virtual world server-side
system -- that is never going to fly, not even among operators of virtual
worlds of the same species! We are already seeing that in the small
ecosystem of OpenSimulator-based virtual worlds.

---
Personally, I'm becoming more and more interested in web-browser-based
viewers, or something like them. I.e. viewers that are simply shells that
receive, essentially, a lambda implementing the viewer itself. That's the
way to go. But that doesn't exist yet, not in production at least.

Fleep Tuque wrote:
      Hi all,

      I'm sure I need to go back through and re-read some of these
      documents to find definitions, but I must be missing something
      entirely.  I've been lurking on this list for some months and the
      statement that "VWRAP is not now, nor has it ever been a protocol to
      enable
      interoperability BETWEEN virtual worlds" took me completely by
      surprise.  I've been under the impression that was the entire point
      of this effort!

      The OpenSim model described by Cristina, and the concerns raised by
      the message at the start of this thread, pretty closely reflect my
      views and concerns.  A consortia of universities is developing in
      which each university will operate its own "world" - using their own
      access and authentication schemes, internal system architecture, etc.
      - but allow our researchers/students to be able to connect and go to
      the worlds of other participating members to collaborate on research
      projects.  We need protocols to help establish the ground rules for
      that connection, and what the baseline requirements are for our
      "world" systems to be able to communicate with one another, but
      ideally to be as minimally intrusive/restrictive as possible.

      Part of the interest in this experiment is similar to the
      "laboratories of democracy" model in which each institution CAN and
      SHOULD do its own thing internally so we can see what sorts of best
      practices and innovation in internal system design emerges.  (In fact
      we have little choice, since each institution is bound by different
      laws and policies governing things like authentication and student
      data.) In our use case, this is not a "tourist" model OR a "walled
      garden" model - it's both!  Each institution intends/needs to have
      areas of their "world" that are off limits to other institutions, and
      some areas that are accessible to members of the consortia.  Figuring
      out which bits we need to pass back and forth to make this work is, I
      thought, what VWRAP would be addressing.


      I will go back through and re-read the source documents with
      Meadhbh's comments in mind, but I wanted to chime in and say
      Cristina's concerns and perspective pretty closely represent my
      interests as well.  And I think it's a mistake to frame the
      conversation as a "tourist" model vs a "walled garden" model even
      hypothetically, since as far as I can tell, we are much more likely
      to see hybrids of the two than any pure implementation of either in
      the ecosystem of worlds that Cristina rightly points out are already
      developing.  In any case, a protocol that assumes only one world
      seems on its face of very little value to _anyone_ if the point is
      not to have interoperability between worlds using the protocol!


      Confused and befuddled,

      - Chris/Fleep


      Chris M. Collins (SL: Fleep Tuque)
      Project Manager, UC Second Life
      Second Life Ambassador, Ohio Learning Network
      UCit Instructional & Research Computing
      University of Cincinnati
      406E Zimmer Hall
      PO Box 210088
      Cincinnati, OH 45221-0088
      (513)556-3018
      chris.collins@uc.edu

      UC Second Life:   http://homepages.uc.edu/secondlife
      OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php










      _______________________________________________
      vwrap mailing list
      vwrap@ietf.org
      https://www.ietf.org/mailman/listinfo/vwrap

_______________________________________________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap