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