Re: [vwrap] Comments on http://tools.ietf.org/html/draft-ietf-vwrap-intro-00
Fleep Tuque <fleep513@gmail.com> Sun, 19 September 2010 12:29 UTC
Return-Path: <fleep513@gmail.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 90EC93A68F6 for <vwrap@core3.amsl.com>;
Sun, 19 Sep 2010 05:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level:
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5
tests=[BAYES_40=-0.185, 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 W2kR-7Hjiam3 for
<vwrap@core3.amsl.com>; Sun, 19 Sep 2010 05:28:59 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com
[209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B815A3A68E3 for
<vwrap@ietf.org>; Sun, 19 Sep 2010 05:28:58 -0700 (PDT)
Received: by vws10 with SMTP id 10so2923948vws.31 for <vwrap@ietf.org>;
Sun, 19 Sep 2010 05:29:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:mime-version:received:received:in-reply-to
:references:date:message-id:subject:from:to:content-type;
bh=sAC8M2WMhHKQR4Hi8SY7/HXsTUZRN80QOyABhvfKch4=;
b=Z8e4rUSgaXRB4HGXI+Zuzcj+NOxnHMcbXyH7LuDn/WpsALQ1JRx4WgilLNPLoY6NyI
8zV/VpFub/0TTBsB/6YlA4YOl15GZ9wdyceIVxQ2q3wFlpr2VDMJP9d0M4TtzTihYbb7
ksJj4y08SfFtXMKTX3K97S2ZPdIbJZfsbUGXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
b=vYXZ02PQ+DSL+s9XSHo5pHAyV/uiRO7kDzD996naCrfhVDkbfPoKOgt1xhhaEQmAxu
6VH6LasawfVIQRsbKZLO2/3/HZ6ZiZq0PuFXDOtbeRUYVe4S2ZGxQwk1ercF2+DTwd6Q
rLiIpjmuKbhg3A5enffGp4QivCpcTCK4pKVls=
MIME-Version: 1.0
Received: by 10.220.63.136 with SMTP id b8mr4166288vci.35.1284899362330;
Sun, 19 Sep 2010 05:29:22 -0700 (PDT)
Received: by 10.220.161.206 with HTTP; Sun, 19 Sep 2010 05:29:22 -0700 (PDT)
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D012669F0EC@rrsmsx506.amr.corp.intel.com>
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>
Date: Sun, 19 Sep 2010 08:29:22 -0400
Message-ID: <AANLkTinrD99m2DavCYn0+6vHN9mi+bnNd2791P-kBruc@mail.gmail.com>
From: Fleep Tuque <fleep513@gmail.com>
To: "vwrap@ietf.org" <vwrap@ietf.org>
Content-Type: multipart/alternative; boundary=e0cb4e88758310592304909bf2ec
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 12:29:00 -0000
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] 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