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

Cristina Videira Lopes <lopes@ics.uci.edu> Sun, 19 September 2010 17:04 UTC

Return-Path: <lopes@ics.uci.edu>
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 4AF713A6781 for <vwrap@core3.amsl.com>; Sun, 19 Sep 2010 10:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.732
X-Spam-Level:
X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, 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 rQLOKc83bnVl for <vwrap@core3.amsl.com>; Sun, 19 Sep 2010 10:04:49 -0700 (PDT)
Received: from david-tennant-v0.ics.uci.edu (david-tennant-v0.ics.uci.edu [128.195.1.174]) by core3.amsl.com (Postfix) with ESMTP id 4B2BF3A67B6 for <vwrap@ietf.org>; Sun, 19 Sep 2010 10:04:49 -0700 (PDT)
Received: from [169.234.249.189] (paul-mcgann.ics.uci.edu [128.195.1.146]) (authenticated bits=0) by david-tennant-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id o8JGbU0W005388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <vwrap@ietf.org>; Sun, 19 Sep 2010 09:37:30 -0700
Message-ID: <4C963C3C.9080700@ics.uci.edu>
Date: Sun, 19 Sep 2010 09:37:16 -0700
From: Cristina Videira Lopes <lopes@ics.uci.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "vwrap@ietf.org" <vwrap@ietf.org>
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>
In-Reply-To: <AANLkTinrD99m2DavCYn0+6vHN9mi+bnNd2791P-kBruc@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060709030304080807040501"
X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information
X-ICS-MailScanner-ID: o8JGbU0W005388
X-ICS-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.862, required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00, SARE_HTML_MANY_BR05 0.50, TW_VW 0.08)
X-ICS-MailScanner-From: lopes@ics.uci.edu
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
Reply-To: lopes@ics.uci.edu
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 17:04:51 -0000

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 <mailto: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
>