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
- [vwrap] Comments on http://tools.ietf.org/html/dr… Cristina Videira Lopes
- [vwrap] Comments on http://tools.ietf.org/html/dr… Katherine Mancuso
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Morgaine
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Meadhbh Hamrick
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Hurliman, John
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Meadhbh Hamrick
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Hurliman, John
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Fleep Tuque
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Cristina Videira Lopes
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Meadhbh Hamrick
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Meadhbh Hamrick
- Re: [vwrap] Comments on http://tools.ietf.org/htm… David W Levine
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Cristina Videira Lopes
- Re: [vwrap] Comments on http://tools.ietf.org/htm… Morgaine