Re: [vwrap] vwrap Digest, Vol 11, Issue 24
Katherine Mancuso <kmancuso@gmail.com> Tue, 29 March 2011 20:46 UTC
Return-Path: <kmancuso@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 059FD3A6A93; Tue, 29 Mar 2011 13:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 n+NRUxngraBo; Tue, 29 Mar 2011 13:46:36 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 905283A6981; Tue, 29 Mar 2011 13:46:36 -0700 (PDT)
Received: by iye19 with SMTP id 19so590908iye.31 for <multiple recipients>; Tue, 29 Mar 2011 13:48:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=gqMTILQOF0c6g9Q69c1eT3LwLmhrx9pROcgnE62qJj4=; b=mChttd5h6IGI3USfo4JrdA5Bd88UjK+U8xofwQRr6Sbq5mZfn/Xw8Sk1F8dmAPd77x tdjAgdmlCrlcEwT3vJHWRFrZ+FxynAvgWqtG5AFTueLlJ/M+8JQL+kqr4bgDaZEBiYrA Ok7v/MQFzOzRkKLPPrxsjDWG2iwLrD4EcJOdc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; b=j8QjhRrvWKZkrzcW2dZAyklWM+rV1/e0RpZOm/5UufePhc0VksLVYfNh8TP9LiKg+Q PAlbfBSr0HVskTLUZYN0FlcOuN9ViLqVB+mGB4sFDZLUnEjsPYxQCnL925/kLv+SJgm7 R1lge0u6LyRkKQdC1dG059tv21xDYZ3Zx4A4w=
Received: by 10.231.29.101 with SMTP id p37mr463666ibc.3.1301431694594; Tue, 29 Mar 2011 13:48:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.143.131 with HTTP; Tue, 29 Mar 2011 13:42:14 -0700 (PDT)
In-Reply-To: <mailman.119.1301425219.8353.vwrap@ietf.org>
References: <mailman.119.1301425219.8353.vwrap@ietf.org>
From: Katherine Mancuso <kmancuso@gmail.com>
Date: Tue, 29 Mar 2011 13:42:14 -0700
Message-ID: <AANLkTimW_yvXG3bfnTJuQ8B3fuw5z4=+mryvKETu+6Ja@mail.gmail.com>
To: vwrap@ietf.org
Cc: vwrap-request@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: kmancuso@gmail.com
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: Tue, 29 Mar 2011 20:46:38 -0000
Hi everyone, I want to speak up for agreeing with Meadhbh & Mike about keeping a role for service level interop in this group. We've made good progress towards this goal and can continue to work on it. Here is an alternative proposal to any which has been brought up so far. I'm aware this may not be fully correct in its technical details, as I am not a software architect: Could the partisans of "full" VW interop consider working together on a draft specification that is something like the intro or David's piece in scope that lays out which specific capacities would need to be supported at a minimum to allow for "full" interop, perhaps getting input from implementers such as the Hypergrid folks and the folks who coordinated the teleport test at Linden? Citing existing service specifications (either ones developed within this WG, or outside specifications like XML, Collada, etc) is preferred, and for capabilities for which there are not existing service specifications or the existing specifications don't work well enough, address that to lay out a clear roadmap of what must be developed. My vision here is that folks who are doing service-level work could continue developing and implementing their individual services, and the folks who wish to do "full" interop could define a menu of services which must be implemented for "full" interop. Implementers could then choose their path based on their use cases: implement the "full" interop specification including all the specifications called for, or implement individual services. I believe that both of these concepts can exist under our existing charter or with limited amendment to the charter and intro, which is much easier for everyone to agree to than entirely rewriting both, and does not require trashing years of work. It seems to me that accomodating "full" interop only would reduce the number of possible implementers and use cases for our work dramatically, not to mention cut out a productive body of folks in this group who have been contributing an awful lot of documents and implementing. For example, to illustrate my point: >From my work as a SL developer focusing in education, I know there's a substantial use case in K-12 education in the US for walled gardens, because schools have big legal liability problems with letting minors wander unwalled virtual worlds (most school libraries in the US have internet filters for the same reasons) and have fairly intense supervision requirements which require substantial moderation & surveillance tools. However, a shared asset server that contains a core of "safe" content might be of interest to these folks, since educators don't necessarily need to reinvent the wheel for their classrooms every year. This is a really good case for service level interop ... implement the asset server specification only, not the "full" one that allows you to teleport to other worlds. On the other hand, universities have far greater interest in letting students and professors teleport among university spaces (which happens metaphorically in the real world all the time), and fewer liability issues. Sharing an asset server might be of interest to them, but so too might "full" interop. They'd want to implement the "full" interop specification. (Paging Fleep Tuque, are you here to make this case better for me?) TL;DR - Proposal is to amend the charter & intro so that they allow the "full" interop people to work in one community on their ideas and the service level interop people to work in parallel on their ideas, rather than assuming that one model has to exclusively dominate the group. I will be unavailable to post anything else much lengthy through 3 April, FYI. Katherine -- --------------------------------------------------------------------------------------------- Katherine Mancuso ISIS Inc, Community Manager (http://www.isis-inc.org) Sex::Tech Conference, Social Media Chair (http://www.sextech.org) The Vesuvius Group: metaverse community builders (http://www.thevesuviusgroup.com) GimpGirl Community Liaison (http://www.gimpgirl.com) http://twitter.com/musingvirtual http://facebook.com/kmancuso http://www.linkedin.com/in/kathymancuso Second Life: Muse Carmona ----------------------------------------------------------------------------------------------
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Dzonatas Sol
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Katherine Mancuso
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Mike Dickson
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Vaughn Deluca
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Dzonatas Sol
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Dzonatas Sol
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Dzonatas Sol
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Sean Hennessee
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Sean Hennessee
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Vaughn Deluca
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Fleep Tuque
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Meadhbh Hamrick
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Vaughn Deluca
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Vaughn Deluca
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Morgaine
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 dyerbrookme@juno.com
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 dyerbrookme@juno.com
- Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Dzonatas Sol