From morgaine.dinova@googlemail.com Mon Mar 7 01:14:57 2011 Return-Path: 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 CF68628C0E8 for ; Mon, 7 Mar 2011 01:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 bsM4Q1G8hLiY for ; Mon, 7 Mar 2011 01:14:56 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 60B463A684D for ; Mon, 7 Mar 2011 01:14:56 -0800 (PST) Received: by qyk29 with SMTP id 29so1647175qyk.10 for ; Mon, 07 Mar 2011 01:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vNx9rk4WwJqWfWiOji02+QeY84KIiK4zQLZ6NK4B6m0=; b=Lkv0qSqhvpNDNpj1rvXIqH6iihGWywQOXtTYP+mTue8BfoO7MX05FPxbZW+VHyu4eZ 5Aylt27of/qWEscn0Wshel9G6k/Gc/Ua43/Hya7mPtLkY1b+pKLC+iML9JHzqL2HDj2P zIYx8GWvvi5ArQbcYTEljCTV87NBWn63aC//Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wDSEaQhTNsZ6QQgV1HcaomNGmJuvIbsgeUihQwnUGYVkKqlo/vxH1xkSV1Lc2e8ZEu cVpJKFF9SLVSupWIVWex2d/Z22w5eLP4DB1V3aXePObiDScylhBb4drk7Hm6dFGVD8se /wdRUFs/RxVKcz7aJvfBxpPKqi9KHAgHOaXQE= MIME-Version: 1.0 Received: by 10.229.75.141 with SMTP id y13mr1339459qcj.15.1299489368780; Mon, 07 Mar 2011 01:16:08 -0800 (PST) Received: by 10.229.222.70 with HTTP; Mon, 7 Mar 2011 01:16:08 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Mar 2011 09:16:08 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429cb3437308a049de0f245 Subject: Re: [vwrap] Networked Communication of Objects: some thoughts X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 09:14:57 -0000 --00235429cb3437308a049de0f245 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Christopher, your post http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a few weeks ago and its linked PDF gave me much food for thought. Web-oriented communication with objects in virtual worlds is useful, but it seems to me that this is really just a subset of a larger field of interest: communication *between objects* in virtual worlds. It's rather remarkable that throughout the long AWG->OGP->MMOX->OGPX->VWRAP process, we never considered inter-object communication between VWs. Yet, communication with and between VW objects is undoubtedly an important aspec= t of VW interop, as it provides essential mechanisms for integration. That was a failure on our part, probably caused by excessive familiarity with the largest commercial VW service, which unfortunately doesn't recognize the existence of other virtual worlds and the need to communicate with them. We need to do better than this if we're trying to bring in a future of interop. Since we're already defining an abstract data type and some serialization formats to carry it, why don't we extend the role of these definitions to inter-object communication as well? It's a relatively small step from LLSD to an LLSD-based messaging format --- the only additional requirement is a scheme for VW object addressing so that an LLSD-formatted message can reach the right object in the intended virtual world. I can think of several ways of achieving this in a flexible way, and numerous applications for it. Perhaps it's worth discussing? Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird wr= ote: > Before we turn off the lights... > > I have recently written a paper Entitled Networked Communication of Secon= d > Life=AE Objects using LSL, php, and MySQL. And it can be found at > http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objec= ts.pdfIts short so I will wait while you read it. > > So this got me to thinking, though my application is specific to Second > Life, there is no reason that communication between objects in various gr= ids > with non-persistent URLs could not be obtained with a simple extension to > this method. Though my method specifically uses the LSL HTTP server (whi= ch > I believe up to this point is not reproduced in the OpenSimulator LSL clo= ne) > any object in any virtual space that can send and receive HTTP requests > should be able to join in one of the networks described in the paper. > > The best part is that this is built on existing standards and all that is > needed in any virtual world to implement something like this is an HTTP > channel to your virtual object. > > Thoughts? Criticisms? Comments? > > -- Christopher (ZenMondo) > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --00235429cb3437308a049de0f245 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Christopher, your post http://www.ietf.org/mail-archive/web/vwrap/current= /msg00528.html of a few weeks ago and its linked PDF gave me much food = for thought.=A0 Web-oriented communication with objects in virtual worlds i= s useful, but it seems to me that this is really just a subset of a larger = field of interest:=A0 communication between objects in virtua= l worlds.

It's rather remarkable that throughout the long AWG->OGP->MMO= X->OGPX->VWRAP process, we never considered inter-object communicatio= n between VWs.=A0 Yet, communication with and between VW objects is undoubt= edly an important aspect of VW interop, as it provides essential mechanisms= for integration.

That was a failure on our part, probably caused by excessive familiarit= y with the largest commercial VW service, which unfortunately doesn't r= ecognize the existence of other virtual worlds and the need to communicate = with them.=A0 We need to do better than this if we're trying to bring i= n a future of interop.

Since we're already defining an abstract data type and some seriali= zation formats to carry it, why don't we extend the role of these defin= itions to inter-object communication as well?=A0 It's a relatively smal= l step from LLSD to an LLSD-based messaging format --- the only additional = requirement is a scheme for VW object addressing so that an LLSD-formatted = message can reach the right object in the intended virtual world.

I can think of several ways of achieving this in a flexible way, and nu= merous applications for it.=A0 Perhaps it's worth discussing?

Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher = Bird <zenmondo@g= mail.com> wrote:
Before we turn off the lights...

I have recently written a paper Ent= itled Networked Communication of Second Life=AE Objects using LSL, php, and= MySQL. And it can be found at http://fl= ynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects.pdf = Its short so I will wait while you read it.

So this got me to thinking, though my application is specific to Second= Life, there is no reason that communication between objects in various gri= ds with non-persistent URLs could not be obtained with a simple extension t= o this method.=A0 Though my method specifically uses the LSL HTTP server (w= hich I believe up to this point is not reproduced in the OpenSimulator LSL = clone) any object in any virtual space that can send and receive HTTP reque= sts should be able to join in one of the networks described in the paper.
The best part is that this is built on existing standards and all that = is needed=A0 in any virtual world to implement something like this is an HT= TP channel to your virtual object.

Thoughts? Criticisms? Comments?
-- Christopher (ZenMondo)

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--00235429cb3437308a049de0f245-- From lenglish5@cox.net Mon Mar 7 10:12:21 2011 Return-Path: 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 10D0D3A67DA for ; Mon, 7 Mar 2011 10:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 a4KbFltL1HcU for ; Mon, 7 Mar 2011 10:12:19 -0800 (PST) Received: from fed1rmfepo103.cox.net (fed1rmfepo103.cox.net [68.230.241.145]) by core3.amsl.com (Postfix) with ESMTP id B53503A67F3 for ; Mon, 7 Mar 2011 10:12:18 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmfepo103.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20110307181332.VSUJ20516.fed1rmfepo103.cox.net@fed1rmimpo01.cox.net> for ; Mon, 7 Mar 2011 13:13:32 -0500 Received: from testsite.local ([72.200.122.104]) by fed1rmimpo01.cox.net with bizsmtp id GJDX1g00i2FFAJo03JDXCK; Mon, 07 Mar 2011 13:13:31 -0500 X-VR-Score: -150.00 X-Authority-Analysis: v=1.1 cv=WtRarTlxVJ38pOpEoV/iO0An5zAk6Rp4dU44mOq+3B0= c=1 sm=1 a=A0BIZ8095Y0A:10 a=Wajolswj7cQA:10 a=F1WT8d/iksvrQKts3CK7KQ==:17 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a=QKNIQRYFAAAA:8 a=G_bLLVcMTxy6TxTcUm4A:9 a=myeWF4S_tu6bXiSmYSMA:7 a=foW1Ng5OB61hRqQ1T3RwHtiyt9cA:4 a=wPNLvfGTeEIA:10 a=1saAOwDhB0AA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=lTUmxKvJ7u8VIDBpPhsA:9 a=aC4ZMexMhzQHyjpKH3EA:7 a=b_MaZW1pLY4fzJcu8fOnM8rpYI0A:4 a=F1WT8d/iksvrQKts3CK7KQ==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <4D75204B.3020903@cox.net> Date: Mon, 07 Mar 2011 11:13:31 -0700 From: Lawson English User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030706030302080800050409" Subject: Re: [vwrap] Networked Communication of Objects: some thoughts X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 18:12:21 -0000 This is a multi-part message in MIME format. --------------030706030302080800050409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit For me, the best existing examples of networked objects are the Cobalt/Croquet implementations of David Reed's Teatime Architecture and the original Kansas collaborative environment from Sun. Of course, they were relatively easy to implement because the languages used, Smalltalk and Self, are OOP "all the way down," so there's no programmer skill required for sending messages to remote objects in different applications/computers because its all OOP messaging. You can fake the messaging in various ways with non-pure-OOP languages, and obviously when more than one language comes into play, things get more complicated. But, the basic relationships stay the same, even with multiple languages. Until you examine what is done with the pure OOP implementations of this idea, you're going to be limited in what you think can be done in this scenario (hint, its a lot more than you think... a LOT more) because you'll limit your ideas due to complications of the implementation. My own take is that virtual worlds should take an existing OOP implementation, like Teatime, and use it as the lingua franca for messaging between worlds. To the messaging system, its all TObjects passing messages back and forth. Within the TObject, the implementation can be done in any language on any hardware. The hard part, fully orthogonal message-passing between remote objects using existing network and IPC protocols, has already been solved by TeaTime, so why try to reinvent the wheel? Just use Squeak as the carrier for OOP interop between worlds and worry about the API between objects in terms of smalltalk message definitions. All else is implementation detail for the behavior of objects within the individual worlds, which is an already-solved problem. Boom. You're done. Lawson On 3/7/11 2:16 AM, Morgaine wrote: > Christopher, your post > http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a > few weeks ago and its linked PDF gave me much food for thought. > Web-oriented communication with objects in virtual worlds is useful, > but it seems to me that this is really just a subset of a larger field > of interest: communication /*between objects*/ in virtual worlds. > > It's rather remarkable that throughout the long > AWG->OGP->MMOX->OGPX->VWRAP process, we never considered inter-object > communication between VWs. Yet, communication with and between VW > objects is undoubtedly an important aspect of VW interop, as it > provides essential mechanisms for integration. > > That was a failure on our part, probably caused by excessive > familiarity with the largest commercial VW service, which > unfortunately doesn't recognize the existence of other virtual worlds > and the need to communicate with them. We need to do better than this > if we're trying to bring in a future of interop. > > Since we're already defining an abstract data type and some > serialization formats to carry it, why don't we extend the role of > these definitions to inter-object communication as well? It's a > relatively small step from LLSD to an LLSD-based messaging format --- > the only additional requirement is a scheme for VW object addressing > so that an LLSD-formatted message can reach the right object in the > intended virtual world. > > I can think of several ways of achieving this in a flexible way, and > numerous applications for it. Perhaps it's worth discussing? > > > Morgaine. > > > > ======================================= > > On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird > > wrote: > > Before we turn off the lights... > > I have recently written a paper Entitled Networked Communication > of Second Life� Objects using LSL, php, and MySQL. And it can be > found at > http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects.pdf > Its short so I will wait while you read it. > > So this got me to thinking, though my application is specific to > Second Life, there is no reason that communication between objects > in various grids with non-persistent URLs could not be obtained > with a simple extension to this method. Though my method > specifically uses the LSL HTTP server (which I believe up to this > point is not reproduced in the OpenSimulator LSL clone) any object > in any virtual space that can send and receive HTTP requests > should be able to join in one of the networks described in the paper. > > The best part is that this is built on existing standards and all > that is needed in any virtual world to implement something like > this is an HTTP channel to your virtual object. > > Thoughts? Criticisms? Comments? > > -- Christopher (ZenMondo) > > _______________________________________________ > 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 --------------030706030302080800050409 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit For me, the best existing examples of networked objects are the Cobalt/Croquet implementations of David Reed's Teatime Architecture and the original Kansas collaborative environment from Sun. Of course, they were relatively easy to
implement because the languages used, Smalltalk and Self, are OOP "all the way down," so there's no programmer skill required for sending messages to remote objects in different applications/computers because its all OOP messaging. You can fake the messaging in various ways with non-pure-OOP languages, and obviously when more than one language comes into play, things get more complicated.

But, the basic relationships stay the same, even with multiple languages. Until you examine what is done with the pure OOP implementations of this idea, you're going to be limited in what you think can be done in this scenario (hint, its a lot more than you think... a LOT more) because you'll limit your ideas due to complications of the implementation.

My own take is that virtual worlds should take an existing OOP implementation, like Teatime, and use it as the lingua franca for messaging between worlds. To the messaging system, its all TObjects passing messages back and forth. Within the TObject, the implementation can be done in any language on any hardware. The hard part, fully orthogonal message-passing between remote objects using existing network and IPC protocols, has already been solved by TeaTime, so why try to reinvent the wheel? Just use Squeak as the carrier for OOP interop between worlds and worry about the API between objects in terms of smalltalk message definitions.

All else is implementation detail for the behavior of objects within the individual worlds, which is an already-solved problem.

Boom. You're done.


Lawson


On 3/7/11 2:16 AM, Morgaine wrote:
Christopher, your post http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a few weeks ago and its linked PDF gave me much food for thought.  Web-oriented communication with objects in virtual worlds is useful, but it seems to me that this is really just a subset of a larger field of interest:  communication between objects in virtual worlds.

It's rather remarkable that throughout the long AWG->OGP->MMOX->OGPX->VWRAP process, we never considered inter-object communication between VWs.  Yet, communication with and between VW objects is undoubtedly an important aspect of VW interop, as it provides essential mechanisms for integration.

That was a failure on our part, probably caused by excessive familiarity with the largest commercial VW service, which unfortunately doesn't recognize the existence of other virtual worlds and the need to communicate with them.  We need to do better than this if we're trying to bring in a future of interop.

Since we're already defining an abstract data type and some serialization formats to carry it, why don't we extend the role of these definitions to inter-object communication as well?  It's a relatively small step from LLSD to an LLSD-based messaging format --- the only additional requirement is a scheme for VW object addressing so that an LLSD-formatted message can reach the right object in the intended virtual world.

I can think of several ways of achieving this in a flexible way, and numerous applications for it.  Perhaps it's worth discussing?


Morgaine.



=======================================

On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird <zenmondo@gmail.com> wrote:
Before we turn off the lights...

I have recently written a paper Entitled Networked Communication of Second Life® Objects using LSL, php, and MySQL. And it can be found at http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects.pdf Its short so I will wait while you read it.

So this got me to thinking, though my application is specific to Second Life, there is no reason that communication between objects in various grids with non-persistent URLs could not be obtained with a simple extension to this method.  Though my method specifically uses the LSL HTTP server (which I believe up to this point is not reproduced in the OpenSimulator LSL clone) any object in any virtual space that can send and receive HTTP requests should be able to join in one of the networks described in the paper.

The best part is that this is built on existing standards and all that is needed  in any virtual world to implement something like this is an HTTP channel to your virtual object.

Thoughts? Criticisms? Comments?

-- Christopher (ZenMondo)

_______________________________________________
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

--------------030706030302080800050409-- From morgaine.dinova@googlemail.com Tue Mar 8 04:10:02 2011 Return-Path: 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 8D7193A6868 for ; Tue, 8 Mar 2011 04:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gorCrwyTbTg0 for ; Tue, 8 Mar 2011 04:10:00 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 481B43A6859 for ; Tue, 8 Mar 2011 04:10:00 -0800 (PST) Received: by qwh6 with SMTP id 6so4509361qwh.31 for ; Tue, 08 Mar 2011 04:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gJX0vkR8VvYGQroxhw/zyKNNNbfrT53xTE8jUBnkoXw=; b=DpWf9Sx6X9z4hUWc4Qk2QSQRfpbEPMCWq/L45Jmq4UtQZGsGxhBdusiCVa7DumwsEl pI0dHBhzGM32jbdHQOMlAEQKAArut9IPE1a3EcUCYK0AoPBv7LE1Ft79kHme6sVn2BAg 6ofH1hLPlmWbnu9f5sO4sxsts2NjAmV6sj17g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eJfWr5p0nb/z9RKgQu2pECQDBG6CifeiCoMH9e0Bho2pgMU7JgSgk/k4Z3OZHCL4Hi ckAuIVv5ceFIIRfyStQRWLXRn3jnJjmr87gWsd3P8cbcT7KH+vbIeb1iiAYv0SJv3PvI gz+3hyFj7V+i7n2Wh2JMYlfFco/6wotX6n0vU= MIME-Version: 1.0 Received: by 10.229.135.208 with SMTP id o16mr3914192qct.129.1299586274754; Tue, 08 Mar 2011 04:11:14 -0800 (PST) Received: by 10.229.222.70 with HTTP; Tue, 8 Mar 2011 04:11:14 -0800 (PST) In-Reply-To: <4D75204B.3020903@cox.net> References: <4D75204B.3020903@cox.net> Date: Tue, 8 Mar 2011 12:11:14 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00248c6a66d64304a0049df782d6 Subject: Re: [vwrap] Networked Communication of Objects: some thoughts X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 12:10:02 -0000 --00248c6a66d64304a0049df782d6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting points, Lawson. As you know, IETF protocols are generally concerned with on-the-wire messag= e exchange, and hence they usually focus on message representation and messag= e sequencing, as opposed to language-dependent issues such as object orientation or the syntax of messaging calls. This has the colossal benefi= t of making protocols usable from literally thousands of network-aware languages. In this group we are very strongly concerned with interoperability. Language agnosticism of protocols provides an immense boost for interop --- the Web would be a much poorer place if its protocols had been defined in terms of its designers' favorite languages instead of using language-agnostic messaging. This is a benefit which we must not sacrifice away. Fortunately, your OO-focused suggestion can be incorporated quite easily into a language-agnostic messaging protocol, because support for OO in a network protocol requires nothing more than including sender and recipient fields in each message to identify the source and target objects. That's easy. UUIDs are perfectly adequate as object identifiers even on a world-size scale. If we take an on-the-wire ADT serialization of the LLSD kind, and we define messages which include UUID fields as source/destination object identifiers= , this gives us a sufficient framework for expressing inter-object communication not only between objects in different virtual worlds, but als= o in a manner entirely independent of the languages in which those objects ar= e programmed. It's even independent of computing paradigm. On-the-wire message definitions are truly a lingua franca. That's where we need to go. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On Mon, Mar 7, 2011 at 6:13 PM, Lawson English wrote: > For me, the best existing examples of networked objects are the > Cobalt/Croquet implementations of David Reed's Teatime Architecture and t= he > original Kansas collaborative environment from Sun. Of course, they were > relatively easy to > implement because the languages used, Smalltalk and Self, are OOP "all th= e > way down," so there's no programmer skill required for sending messages t= o > remote objects in different applications/computers because its all OOP > messaging. You can fake the messaging in various ways with non-pure-OOP > languages, and obviously when more than one language comes into play, thi= ngs > get more complicated. > > But, the basic relationships stay the same, even with multiple languages. > Until you examine what is done with the pure OOP implementations of this > idea, you're going to be limited in what you think can be done in this > scenario (hint, its a lot more than you think... a LOT more) because you'= ll > limit your ideas due to complications of the implementation. > > My own take is that virtual worlds should take an existing OOP > implementation, like Teatime, and use it as the lingua franca for messagi= ng > between worlds. To the messaging system, its all TObjects passing message= s > back and forth. Within the TObject, the implementation can be done in any > language on any hardware. The hard part, fully orthogonal message-passing > between remote objects using existing network and IPC protocols, has alre= ady > been solved by TeaTime, so why try to reinvent the wheel? Just use Squeak= as > the carrier for OOP interop between worlds and worry about the API betwee= n > objects in terms of smalltalk message definitions. > > All else is implementation detail for the behavior of objects within the > individual worlds, which is an already-solved problem. > > Boom. You're done. > > > Lawson > > > > On 3/7/11 2:16 AM, Morgaine wrote: > > Christopher, your post > http://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a few > weeks ago and its linked PDF gave me much food for thought. Web-oriented > communication with objects in virtual worlds is useful, but it seems to m= e > that this is really just a subset of a larger field of interest: > communication *between objects* in virtual worlds. > > It's rather remarkable that throughout the long AWG->OGP->MMOX->OGPX->VWR= AP > process, we never considered inter-object communication between VWs. Yet= , > communication with and between VW objects is undoubtedly an important asp= ect > of VW interop, as it provides essential mechanisms for integration. > > That was a failure on our part, probably caused by excessive familiarity > with the largest commercial VW service, which unfortunately doesn't > recognize the existence of other virtual worlds and the need to communica= te > with them. We need to do better than this if we're trying to bring in a > future of interop. > > Since we're already defining an abstract data type and some serialization > formats to carry it, why don't we extend the role of these definitions to > inter-object communication as well? It's a relatively small step from LL= SD > to an LLSD-based messaging format --- the only additional requirement is = a > scheme for VW object addressing so that an LLSD-formatted message can rea= ch > the right object in the intended virtual world. > > I can think of several ways of achieving this in a flexible way, and > numerous applications for it. Perhaps it's worth discussing? > > > Morgaine. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird = wrote: > >> Before we turn off the lights... >> >> I have recently written a paper Entitled Networked Communication of Seco= nd >> Life=AE Objects using LSL, php, and MySQL. And it can be found at >> http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Obje= cts.pdfIts short so I will wait while you read it. >> >> So this got me to thinking, though my application is specific to Second >> Life, there is no reason that communication between objects in various g= rids >> with non-persistent URLs could not be obtained with a simple extension t= o >> this method. Though my method specifically uses the LSL HTTP server (wh= ich >> I believe up to this point is not reproduced in the OpenSimulator LSL cl= one) >> any object in any virtual space that can send and receive HTTP requests >> should be able to join in one of the networks described in the paper. >> >> The best part is that this is built on existing standards and all that i= s >> needed in any virtual world to implement something like this is an HTTP >> channel to your virtual object. >> >> Thoughts? Criticisms? Comments? >> >> -- Christopher (ZenMondo) >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > _______________________________________________ > vwrap mailing listvwrap@ietf.orghttps://www.ietf.org/mailman/listinfo/vwr= ap > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --00248c6a66d64304a0049df782d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Interesting points, Lawson.

As you know, IETF protocols are generall= y concerned with on-the-wire message exchange, and hence they usually focus= on message representation and message sequencing, as opposed to language-d= ependent issues such as object orientation or the syntax of messaging calls= .=A0 This has the colossal benefit of making protocols usable from literall= y thousands of network-aware languages.

In this group we are very strongly concerned with interoperability.=A0 = Language agnosticism of protocols provides an immense boost for interop ---= the Web would be a much poorer place if its protocols had been defined in = terms of its designers' favorite languages instead of using language-ag= nostic messaging.=A0 This is a benefit which we must not sacrifice away.
Fortunately, your OO-focused suggestion can be incorporated quite easil= y into a language-agnostic messaging protocol, because support for OO in a = network protocol requires nothing more than including sender and recipient = fields in each message to identify the source and target objects.=A0 That&#= 39;s easy.=A0 UUIDs are perfectly adequate as object identifiers even on a = world-size scale.

If we take an on-the-wire ADT serialization of the LLSD kind, and we de= fine messages which include UUID fields as source/destination object identi= fiers, this gives us a sufficient framework for expressing inter-object com= munication not only between objects in different virtual worlds, but also i= n a manner entirely independent of the languages in which those objects are= programmed.=A0 It's even independent of computing paradigm.

On-the-wire message definitions are truly a lingua franca.=A0 That'= s where we need to go.


Morgaine.




=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Mon, Mar 7, 2011 at 6:13 = PM, Lawson English <lenglish5@cox.net> wrote:
=20 =20 =20 =20
For me, the best existing examples of networked objects are the Cobalt/Croquet implementations of David Reed's Teatime Architecture and the original Kansas collaborative environment from Sun. Of course, they were relatively easy to
implement because the languages used, Smalltalk and Self, are OOP "all the way down," so there's no programmer skill requir= ed for sending messages to remote objects in different applications/computers because its all OOP messaging. You can fake the messaging in various ways with non-pure-OOP languages, and obviously when more than one language comes into play, things get more complicated.

But, the basic relationships stay the same, even with multiple languages. Until you examine what is done with the pure OOP implementations of this idea, you're going to be limited in what yo= u think can be done in this scenario (hint, its a lot more than you think... a LOT more) because you'll limit your ideas due to complications of the implementation.

My own take is that virtual worlds should take an existing OOP implementation, like Teatime, and use it as the lingua franca for messaging between worlds. To the messaging system, its all TObjects passing messages back and forth. Within the TObject, the implementation can be done in any language on any hardware. The hard part, fully orthogonal message-passing between remote objects using existing network and IPC protocols, has already been solved by TeaTime, so why try to reinvent the wheel? Just use Squeak as the carrier for OOP interop between worlds and worry about the API between objects in terms of smalltalk message definitions.

All else is implementation detail for the behavior of objects within the individual worlds, which is an already-solved problem.

Boom. You're done.


Lawson



On 3/7/11 2:16 AM, Morgaine wrote:
Christopher, your post ht= tp://www.ietf.org/mail-archive/web/vwrap/current/msg00528.html of a few weeks ago and its linked PDF gave me much food for thought.=A0 Web-oriented communication with objects in virtual worlds is useful, but it seems to me that this is really just a subset of a larger field of interest:=A0 communication between objects in virtual worlds.

It's rather remarkable that throughout the long AWG->OGP->MMOX->OGPX->VWRAP process, we never considered inter-object communication between VWs.=A0 Yet, communication with and between VW objects is undoubtedly an important aspect of VW interop, as it provides essential mechanisms for integration.

That was a failure on our part, probably caused by excessive familiarity with the largest commercial VW service, which unfortunately doesn't recognize the existence of other virtual worlds and the need to communicate with them.=A0 We need to do better than this if we're trying to bring in a future of interop.=

Since we're already defining an abstract data type and some serialization formats to carry it, why don't we extend the role o= f these definitions to inter-object communication as well?=A0 It's = a relatively small step from LLSD to an LLSD-based messaging format --- the only additional requirement is a scheme for VW object addressing so that an LLSD-formatted message can reach the right object in the intended virtual world.

I can think of several ways of achieving this in a flexible way, and numerous applications for it.=A0 Perhaps it's worth discussin= g?


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sun, Jan 16, 2011 at 4:54 AM, L. Christopher Bird <zenmondo@gmail.com> wrote:
Before we turn off the lights...

I have recently written a paper Entitled Networked Communication of Second Life=AE Objects using LSL, php, and MySQL. And it can be found at = http://flynnos.org/Networked%20Communication%20of%20Second%20Life%20Objects= .pdf Its short so I will wait while you read it.

So this got me to thinking, though my application is specific to Second Life, there is no reason that communication between objects in various grids with non-persistent URLs could not be obtained with a simple extension to this method.=A0 Though my method specifically uses the LSL HTTP server (which I believe up to this point is not reproduced in the OpenSimulator LSL clone) any object in any virtual space that can send and receive HTTP requests should be able to join in one of the networks described in the paper.

The best part is that this is built on existing standards and all that is needed=A0 in any virtual world to implement something like this is an HTTP channel to your virtual object.
Thoughts? Criticisms? Comments?

-- Christopher (ZenMondo)

_______________________________________________
vwrap mailing list
vwrap@ietf.or= g
https://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h=
ttps://www.ietf.org/mailman/listinfo/vwrap


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--00248c6a66d64304a0049df782d6-- From barryleiba.mailing.lists@gmail.com Wed Mar 23 13:09:10 2011 Return-Path: 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 96FAB28C122 for ; Wed, 23 Mar 2011 13:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 r-QP+b3Kydkr for ; Wed, 23 Mar 2011 13:09:09 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8712A28C0F9 for ; Wed, 23 Mar 2011 13:09:09 -0700 (PDT) Received: by wwa36 with SMTP id 36so7143435wwa.13 for ; Wed, 23 Mar 2011 13:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=CgDAC//ahoIUUeIC0N5tWl1bkFT3nw9opn0eWz1yC5g=; b=moXDyuHZiMdM4WbHTBAcGjIvmFkMfVfG3x3jWuhQuD+ZZ4dAY1q/42Zg5D+0rMTA6I 6cDY2NzCIbgsKlLs3KGwoj1nzw+jhicyXD/u4Einbbdivh0vgbHNb1uRuZPsu99IgB2c BYAeZ4iBQ9+AiTFEoQ0rOpC8MfzQdwLu/lRNY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=fqyGbVXtM6Eo4skWYmiCSEPhYgg311xCr1g1X46pWbX/Goa8hyL2fCgdLeo18odmSC Utdorxam2+OQ6FifppS+OgMZxt0ZuTE/MUutmvhE6lIabyyDTjJH3M4QrCSDdh2c1OyR +vXBNnNmeY8TBH+WPV/1mFuO95AD4hDC+zM84= MIME-Version: 1.0 Received: by 10.227.139.89 with SMTP id d25mr6964791wbu.58.1300911043065; Wed, 23 Mar 2011 13:10:43 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.227.208.83 with HTTP; Wed, 23 Mar 2011 13:10:43 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Wed, 23 Mar 2011 16:10:43 -0400 X-Google-Sender-Auth: Dr2LBoeNcjZyit2OVUoJVpfPyB8 Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 20:09:10 -0000 Reminder: If anyone's done anything related to what's below, please post here and get some discussion going. There's still about two and a half weeks to get something ready. Barry, as chair On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba wrot= e: > On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba wr= ote: >>> As for timescales, we already started work on a new Intro in October an= d >>> November, as I described in my first email in this thread.=A0 It was be= ing >>> done informally, not as an official draft but as input to a totally new >>> draft.=A0 It was not being done as a revision because the previous Intr= o >>> simply did not meet key requirements for many contributors, as was clea= r >>> from the group's very intense discussions of September. >> >> Can you see if you can get it into reasonable shape to introduce >> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =A0That >> would give people something concrete to work from. > > I haven't seen any activity on this, so let me repeat this with a deadlin= e: > > The chairs ask the proponents to please get a new intro document into > reasonable (not final) shape to introduce publicly, and to submit it > as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" > by 10 April (the significance of which will be left for the reader to > research, should s/he care to). =A0There may, of course, be any > (reasonable) number of authors listed on the draft, and any one may be > the name chosen to live in the draft name. > > If we're not able to do that, I think we need to seriously question > whether there's enough real energy to continue. > > Barry, as chair > From vaughn.deluca@gmail.com Fri Mar 25 08:41:04 2011 Return-Path: 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 4193B3A65A5 for ; Fri, 25 Mar 2011 08:41:04 -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 wzxuIBESVQ+7 for ; Fri, 25 Mar 2011 08:41:03 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1CBCB3A6774 for ; Fri, 25 Mar 2011 08:41:02 -0700 (PDT) Received: by ewy19 with SMTP id 19so597852ewy.31 for ; Fri, 25 Mar 2011 08:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3USPwL7wt2s3vla1EsRe8tStA9GE+vnpXOgwF063CSI=; b=c+M5/w3XhojrSPtIdErmJi29g92e47YDKGte7S0LmdevEPNG9nSWnD144C/bPnEU74 8UVCCNKrfrje3Ynva/n7ZjQB0XUxDG9zYY7m4f/9kWxUmcQi/u8DDccvb4qNAB0vyy8i oyBZZKuDAlQh9nq2HGGKTyd+mYRrGX7AoUIuQ= 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 :cc:content-type; b=lIMG8CAPwNQ0nuoKthaOeRt+roidKUuyjecitOWGRiLsdOdLXJUX7DLkbWtyGdEL6E IJgTq7D1AE2YOlcQxb7TYHTZLnuqPs6Y6ZAm+c/1J7hPd5jQghdkhpH0EkxWcYQ0AhFw QL9H6ny36BdqQDbAp4oaPTTLkzUMNj0N69I1o= MIME-Version: 1.0 Received: by 10.213.15.76 with SMTP id j12mr429834eba.119.1301067757575; Fri, 25 Mar 2011 08:42:37 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Fri, 25 Mar 2011 08:42:37 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Fri, 25 Mar 2011 16:42:37 +0100 Message-ID: From: Vaughn Deluca To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 15:41:04 -0000 Absolute radio silence on the list... VWRAP is clearly in a crisis. The major players have all moved on, and those who are left do not seem to be able to generate the needed energy to carry the project forward. I have always been in the fringe of this group. I am not a profesional in the field, and i dont feel capable of leading the project. However simply letting it die does not feel right either... So it seems its time to take a vote, how many of us are *at all* interested in keeping VWRAP alive? I cant believe we will simply give up. Are we really forced to conclude we no longer have enough core participation? On 3/23/11, Barry Leiba wrote: > Reminder: If anyone's done anything related to what's below, please > post here and get some discussion going. There's still about two and > a half weeks to get something ready. > > Barry, as chair > > On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba > wrote: >> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >> wrote: >>>> As for timescales, we already started work on a new Intro in October and >>>> November, as I described in my first email in this thread. It was being >>>> done informally, not as an official draft but as input to a totally new >>>> draft. It was not being done as a revision because the previous Intro >>>> simply did not meet key requirements for many contributors, as was clear >>>> from the group's very intense discussions of September. >>> >>> Can you see if you can get it into reasonable shape to introduce >>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? That >>> would give people something concrete to work from. >> >> I haven't seen any activity on this, so let me repeat this with a >> deadline: >> >> The chairs ask the proponents to please get a new intro document into >> reasonable (not final) shape to introduce publicly, and to submit it >> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >> by 10 April (the significance of which will be left for the reader to >> research, should s/he care to). There may, of course, be any >> (reasonable) number of authors listed on the draft, and any one may be >> the name chosen to live in the draft name. >> >> If we're not able to do that, I think we need to seriously question >> whether there's enough real energy to continue. >> >> Barry, as chair >> > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From nexiim@gmail.com Fri Mar 25 09:01:29 2011 Return-Path: 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 40EA53A67AB for ; Fri, 25 Mar 2011 09:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 QiAeVS49TfAy for ; Fri, 25 Mar 2011 09:01:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 943603A67AA for ; Fri, 25 Mar 2011 09:01:27 -0700 (PDT) Received: by wyb29 with SMTP id 29so755505wyb.31 for ; Fri, 25 Mar 2011 09:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7xIbUKmQcZYk2JTfcSF7cSDj0ebCbe+Bbt86aLIPZ8Y=; b=tt6Oj9CJPwZxzpc6GR3kBRBAHUE8eI1Jf0zon/veltwMM7hi3o4UTF9c7SNXY7I8xK sjEp6irXGtMoMSe6tq6RZg80fjw8hMpuvpLmuQhc09bcHRlxuVHSN4/U46FiDK1/mHV3 HpkbN9EOtYkR4yGYJykAywNyXxcFIgg5o8MMo= 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 :cc:content-type; b=Y65mL18UekrA4Ha9HamzG752OGIFtQXvVeqj5tm90wbLhNP1/lMuEyCgK7MEw9MqkF pMrlTqnSOZovo3KATi+WIQXobz6zIxP+zOAdjNDFwl8ms4lNJ46S3VuSGKR1dqJTl3F5 /heMTLRs0pviFB/WovDbR/rda6sN3/q+z/H64= MIME-Version: 1.0 Received: by 10.216.79.70 with SMTP id h48mr1900141wee.7.1301068982365; Fri, 25 Mar 2011 09:03:02 -0700 (PDT) Received: by 10.216.239.5 with HTTP; Fri, 25 Mar 2011 09:03:02 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Fri, 25 Mar 2011 16:03:02 +0000 Message-ID: From: Nexii Malthus To: Vaughn Deluca Content-Type: multipart/alternative; boundary=000e0ce0b50e85b040049f50badf Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 16:01:29 -0000 --000e0ce0b50e85b040049f50badf Content-Type: text/plain; charset=ISO-8859-1 Chiming in here my own agreement with Vaughn along similiar lines. - Nexii On Fri, Mar 25, 2011 at 3:42 PM, Vaughn Deluca wrote: > Absolute radio silence on the list... > VWRAP is clearly in a crisis. The major players have all moved on, > and those who are left do not seem to be able to generate the needed > energy to carry the project forward. > > I have always been in the fringe of this group. I am not a profesional > in the field, and i dont feel capable of leading the project. However > simply letting it die does not feel right either... > > So it seems its time to take a vote, how many of us are *at all* > interested in keeping VWRAP alive? I cant believe we will simply give > up. Are we really forced to conclude we no longer have enough core > participation? > > On 3/23/11, Barry Leiba wrote: > > Reminder: If anyone's done anything related to what's below, please > > post here and get some discussion going. There's still about two and > > a half weeks to get something ready. > > > > Barry, as chair > > > > On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba > > wrote: > >> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba > >> wrote: > >>>> As for timescales, we already started work on a new Intro in October > and > >>>> November, as I described in my first email in this thread. It was > being > >>>> done informally, not as an official draft but as input to a totally > new > >>>> draft. It was not being done as a revision because the previous Intro > >>>> simply did not meet key requirements for many contributors, as was > clear > >>>> from the group's very intense discussions of September. > >>> > >>> Can you see if you can get it into reasonable shape to introduce > >>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? That > >>> would give people something concrete to work from. > >> > >> I haven't seen any activity on this, so let me repeat this with a > >> deadline: > >> > >> The chairs ask the proponents to please get a new intro document into > >> reasonable (not final) shape to introduce publicly, and to submit it > >> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" > >> by 10 April (the significance of which will be left for the reader to > >> research, should s/he care to). There may, of course, be any > >> (reasonable) number of authors listed on the draft, and any one may be > >> the name chosen to live in the draft name. > >> > >> If we're not able to do that, I think we need to seriously question > >> whether there's enough real energy to continue. > >> > >> Barry, as chair > >> > > _______________________________________________ > > 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 > --000e0ce0b50e85b040049f50badf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Chiming in here my own agreement with Vaughn along similiar lines.

=
- Nexii

On Fri, Mar 25, 2011 a= t 3:42 PM, Vaughn Deluca <vaughn.deluca@gmail.com> wrote:
Absolute radio silence on the list...
VWRAP is clearly in a crisis. =A0The major players have all moved on,
and those who are left do not seem to be able to generate the needed
energy to carry the project forward.

I have always been in the fringe of this group. I am not a profesional
in the field, and i dont feel capable of leading the project. However
simply letting it die does not feel right either...

So it seems its time to take a vote, how many of us are *at all*
interested in keeping VWRAP alive? I cant believe we will simply give
up. Are we really forced to conclude we no longer have enough core
participation?

On 3/23/11, Barry Leiba <barr= yleiba@computer.org> wrote:
> Reminder: If anyone's done anything related to what's below, p= lease
> post here and get some discussion going. =A0There's still about tw= o and
> a half weeks to get something ready.
>
> Barry, as chair
>
> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <barryleiba@computer.org>
> wrote:
>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <barryleiba@computer.org>
>> wrote:
>>>> As for timescales, we already started work on a new Intro = in October and
>>>> November, as I described in my first email in this thread.= =A0It was being
>>>> done informally, not as an official draft but as input to = a totally new
>>>> draft. =A0It was not being done as a revision because the = previous Intro
>>>> simply did not meet key requirements for many contributors= , as was clear
>>>> from the group's very intense discussions of September= .
>>>
>>> Can you see if you can get it into reasonable shape to introdu= ce
>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 = ? =A0That
>>> would give people something concrete to work from.
>>
>> I haven't seen any activity on this, so let me repeat this wit= h a
>> deadline:
>>
>> The chairs ask the proponents to please get a new intro document i= nto
>> reasonable (not final) shape to introduce publicly, and to submit = it
>> as an Internet Draft with a name like "draft-SOMEONE-vwrap-in= tro-00"
>> by 10 April (the significance of which will be left for the reader= to
>> research, should s/he care to). =A0There may, of course, be any >> (reasonable) number of authors listed on the draft, and any one ma= y be
>> the name chosen to live in the draft name.
>>
>> If we're not able to do that, I think we need to seriously que= stion
>> whether there's enough real energy to continue.
>>
>> Barry, as chair
>>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0ce0b50e85b040049f50badf-- From kmancuso@gmail.com Fri Mar 25 12:14:04 2011 Return-Path: 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 AC08B3A6825 for ; Fri, 25 Mar 2011 12:14:04 -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 JzEvTylaxwqz for ; Fri, 25 Mar 2011 12:14:04 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E0A063A6821 for ; Fri, 25 Mar 2011 12:14:03 -0700 (PDT) Received: by iwn39 with SMTP id 39so994259iwn.31 for ; Fri, 25 Mar 2011 12:15:39 -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:content-type; bh=yZArySozFH8H63kO7lUJ/yVGbcEKT6HoEF4aoorB3Mo=; b=eaZIJoHPWEU763+Ge8m3/KglVfprJqJMdJ/nF/Nz9yxCyrTgxGd1qKtP160du87RR5 TBK4+znPDDFxb3f3gYKN1vazkiGJ0DmITFEYpbhpPCj4Ea2mNNB7vZuJFFjp7rHm0Svs nT61mbn3qZrmwtMto/xArQjRaBr7Gtld/9oAA= 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:content-type; b=VaR4OZc7j7pLCKn2+VhnHv7U+P1POD1MIwnUSSDr0oe86jeqpXqi5VU1RvcimCGpjT K0lb+N6SpmseuW7qoRSn14X6jbxFRjjVm9v1FguAXBfrUFV8Dwyr7YCEA43+Fr8PZfyh Kerpgv8z5Zp9yy+b1aGvBX2nrZYPDEyWERb24= Received: by 10.42.75.66 with SMTP id z2mr990793icj.235.1301080539174; Fri, 25 Mar 2011 12:15:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.185.145 with HTTP; Fri, 25 Mar 2011 12:15:19 -0700 (PDT) In-Reply-To: References: From: Katherine Mancuso Date: Fri, 25 Mar 2011 12:15:19 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 4 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 19:14:04 -0000 As I've said before, I will continue in my specialist role dealing with accessibility and additionally contribute to polishing drafts (since I'm a writer with a good understanding of technical topics) - but we still need folks who are willing to be software architects and implementers. The other suggestion I have is forget rechartering, go with some of the drafts Meadhbh & Zha and a few others have written, admit that what they did was actually hard and the rest of this group has so far failed to reproduce such an achievement, and use it as a base to move forward and build upon. Internet drafts are basically not set in stone until they become actual RFCs anyway. Katheirne From izzyalanis@gmail.com Fri Mar 25 13:32:00 2011 Return-Path: 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 181C628C0CE for ; Fri, 25 Mar 2011 13:32:00 -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 SGqSKDj-WC5Q for ; Fri, 25 Mar 2011 13:31:59 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 641853A684D for ; Fri, 25 Mar 2011 13:31:58 -0700 (PDT) Received: by fxm15 with SMTP id 15so1565725fxm.31 for ; Fri, 25 Mar 2011 13:33:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PqZHxdp0AcBql0+WYqcbHdDv4efHf9aDIqNow5uaV38=; b=h3OTYdqA6BP3PM1QjyFljGjrX62b1pIZDC+KXF80cRyvTaYaP4qB0RaUBp2TT5OGFm k9k55Amy+z3Dc1fKYWQBbHxrA+3j0pM0dy4tSk3zvlDDDywfx/0ktsQZJvGsRdyAQ8zh PYWUcVDSaGDe4sjk1rjWrBCLVpplOGu3ZQEh0= 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 :cc:content-type:content-transfer-encoding; b=LqU33cbTNERmHjT6sZ57oMYA+HbX442vffQ++8EOsetXcAqziFB861f/WjpN+QY9aj CJwmCKBgSlmBoSaO9t+NPDpuZMNo57Prb7Es42MnwF44kXFafznOQqlD8oQAHKZJ9kTC OUIv7Af0Dvvnf3zQ1opC+u+Har2CHCVC2bLeg= MIME-Version: 1.0 Received: by 10.223.25.197 with SMTP id a5mr1383142fac.29.1301085213420; Fri, 25 Mar 2011 13:33:33 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Fri, 25 Mar 2011 13:33:33 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Fri, 25 Mar 2011 16:33:33 -0400 Message-ID: From: Izzy Alanis To: Nexii Malthus Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 20:32:00 -0000 If you're interested in automated *testing* of web applications with browser quirks and behavior in mind, I've heard really good things about Watir. If you're interested in automated access to web pages from java for something like data scraping, and if it was just for a particular website... I'd probably hack around the javascript requirements of the login page in question and just use curl or apache's HttpClient libraries (ah the heresy!). If you're interested in automated *rendering* of HTML pages from Java, I've had some success with the Lobo project's Cobra toolkit, but that project is pretty stagnant (and if you're C/C++ minded, run straight to WebKit!). Personally, I make extensive use of httpunit's ServletUnit functionality for unit testing servlets -- primarily for web-services and the like. It's great! But I don't really ever find myself in need of the built in javascript features. This is a bit philosophical, but I consider Unit testing separate from Integration testing, and if you're testing on a live running server, it feels a lot more like integration testing to me... That's just my personal opinion though. On Fri, Mar 25, 2011 at 2:31 PM, Dee Ayy wrote: > I'm trying httpunit because I am trying to login via script to a > website that I assume is running JavaScript as part of its > authentication method and I needed something to run the returned > JavaScript which CURL does not run. > > I got an error: > org.mozilla.javascript.EcmaError: TypeError: Cannot find function > addEventListener. (httpunit#19) > > Then noticed "addEventListener" is not listed here > http://httpunit.sourceforge.net/doc/javascript-support.html > > Then I added HttpUnitOptions per > http://httpunit.sourceforge.net/doc/faq.html#unsupported > and saw many more errors with the first displaying as: > failed: org.mozilla.javascript.EcmaError: TypeError: Cannot find > function addEventListener. (httpunit#19) > > Are the "httpunit#" 's known unsupported TODO features? > Are they listed anywhere? -- probably in the httpunit source. > > On my first target page, I have many 19's, so I'd vote for that as a > priority, but I also have: > 19 > 32 > 9 > 838 > 624 > 226 > 1 > > I suppose I am at a dead end regarding my script login task. > > Can anyone recommend a different free offering that may be able to > login via "automation"? > > But I was also considering Google V8 JavaScript Engine > http://code.google.com/p/v8/ "V8 is Google's open source JavaScript > engine." > > The httpunit developers may want to consider using V8 for their > JavaScript support. =A0I may try V8 myself with either CURL or httpunit. > =A0I saw that getDOM method which I believe is the data V8 wants. > > Regards, > Dee > > -------------------------------------------------------------------------= ----- > Enable your software for Intel(R) Active Management Technology to meet th= e > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your softwar= e > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Httpunit-develop mailing list > Httpunit-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/httpunit-develop > From izzyalanis@gmail.com Fri Mar 25 13:33:05 2011 Return-Path: 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 5D19928C0CE for ; Fri, 25 Mar 2011 13:33:05 -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 2NmYFZ-0oSBe for ; Fri, 25 Mar 2011 13:33:04 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4F99E3A684D for ; Fri, 25 Mar 2011 13:33:04 -0700 (PDT) Received: by fxm15 with SMTP id 15so1566425fxm.31 for ; Fri, 25 Mar 2011 13:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Q7vJZ8CfeA8Mf5Z1qmInvL7MCjUgSJdW2ZvWwmimfrk=; b=n4CQYOmMn4RIdPRXTm6i3l/tcYAA8GdDyrxWEjcOiEZ/kZysMxLlnHytHYRjw4J2Yz upAMXd0CuANIFG8M1Io0PCQvhPhdbEbuaAa0IiUF41xEmgwVCqudCGMfAlpEVGNUnu5U a3BPC9Fg+xmMx1RFjRQPu0D2aK56E3G4gQyq4= 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 :cc:content-type; b=R4ifG4JR2HqPctnl/WPckE09A4jwHD3K+3S2GRtgJdEIDifZVH2vd8sH0ARK22wTc/ XgA+Bg5kxIksEJiaxftPwzPrDlCon7yZJB8OoCdu10WWRYAUAwVLCEozyNYlBZzxEi4i aTQewX9Jc1ObRL/09y3JgIerbZ1jhoSoeSiJQ= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr1359373fan.105.1301085279441; Fri, 25 Mar 2011 13:34:39 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Fri, 25 Mar 2011 13:34:39 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Fri, 25 Mar 2011 16:34:39 -0400 Message-ID: From: Izzy Alanis To: Nexii Malthus Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 20:33:05 -0000 ... retract that last... I'm having a bad e-mail day... What I meant to send was: I feel similarly. I would hate to see VWRAP die. But on a separate, somewhat related, note; every time I even *think* ... "Hmm... what would I like to see in that draft WRAP intro document?", I start to think about the abstract type system, the very first bullet point in the charter, and I think about the crap that is LLSD (no offense to the folks at Linden Labs) and then I think about protocolbuffers and Thrift and think... why on earth would we ever continue with LLSD. Yuck! And then I get wrapped up in those projects instead. (I've very fickle). From ohmeadhbh@gmail.com Fri Mar 25 14:05:01 2011 Return-Path: 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 0AF2328C0CE for ; Fri, 25 Mar 2011 14:05:01 -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 7dm1V+qtcVj3 for ; Fri, 25 Mar 2011 14:04:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D75803A679C for ; Fri, 25 Mar 2011 14:04:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so1097347iwn.31 for ; Fri, 25 Mar 2011 14:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=H3Xx/z3IIgY+3W3U/P91tuT7j1mLZiF5P9uh5KYsWXA=; b=T4iihTF8v/CmAy4bsVR2o2DF7IgrSTiVg1IBMVbsISAx+KlzQLNektYfeBaWElg19A g05fbOLI1r1OP00W8rowh4Wa04M+QDFqyXGFn6w0ntmWS3mM9Tg4MPr2bvAVYzeK11To zf7yFgUerYGwrw0OzIis68NrTFmr4tkJkV9DQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=JpaJW9zBjoSA3MWJnG/ehEk2JI7jr4BKobPj0/os46lz6lQEP4mtW+6Mm+zHPiJxus h5jqkeEjjEf06JOweV3aiqq6z8wXyW8CeCq54vOLM8t+s1ppBPBT9VoCoflzWwfT0ulE hKvTJBaHT47TUpaQP2lBlSJ3iDQwCwsNRYMPM= Received: by 10.43.56.70 with SMTP id wb6mr2047559icb.339.1301087195231; Fri, 25 Mar 2011 14:06:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.199 with HTTP; Fri, 25 Mar 2011 14:06:15 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Fri, 25 Mar 2011 14:06:15 -0700 Message-ID: To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 21:05:01 -0000 so what would you replace LLSD with? -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, Mar 25, 2011 at 1:34 PM, Izzy Alanis wrote: > ... retract that last... I'm having a bad e-mail day... > What I meant to send was: > > I feel similarly. I would hate to see VWRAP die. > > But on a separate, somewhat related, note; every time I even *think* > ... "Hmm... what would I like to see in that draft WRAP intro > document?", I start to think about the abstract type system, the very > first bullet point in the charter, and I think about the crap that is > LLSD (no offense to the folks at Linden Labs) and then I think about > protocolbuffers and Thrift and think... why on earth would we ever > continue with LLSD. Yuck! And then I get wrapped up in those projects > instead. (I've very fickle). > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Fri Mar 25 15:31:46 2011 Return-Path: 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 94D8E28C0FF for ; Fri, 25 Mar 2011 15:31:46 -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 6176Rh8N8JHz for ; Fri, 25 Mar 2011 15:31:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2744B28C0ED for ; Fri, 25 Mar 2011 15:31:45 -0700 (PDT) Received: by iwn39 with SMTP id 39so1169297iwn.31 for ; Fri, 25 Mar 2011 15:33:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kHHwHl6SCwQWxKlpTsIFy+CXe1pBs2g245+oTaVgx+w=; b=qvMxVgdxHaxUiaXXytGaHde+VOFmkHY9vpYaMV636Z+1tsQZGdN0eqJ0HnMMoeyA+v MvKV8DaI4hNGR50I0yo9FKEoU8pkSMQY/GiDvhI6o9LbOBjlsv7olLrcBWwkP5lGy+tO 4fQct7bq3ng5zFAyYFEXSpce2sMNOWSy4VuZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=HmkuKYrI1hl21bh2ogLym+FE+gHz2Q5cVXl3gG8c/KdclNBZc44QoxjXJmZl4W1ohs OUGPyiLlevSS0MUCi1Yjc1Pj0eBoI++ufWRjeW8GmKKBu+jw+NwRmI8x30sZN2ZKP0MF OJTByWwymteCJJmQyGD9GoB1TEAeFzrtLQ+yg= Received: by 10.43.53.74 with SMTP id vp10mr2078817icb.413.1301092400719; Fri, 25 Mar 2011 15:33:20 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-76-153.dsl.scrm01.sbcglobal.net [70.133.76.153]) by mx.google.com with ESMTPS id gy41sm922783ibb.39.2011.03.25.15.33.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 15:33:19 -0700 (PDT) Message-ID: <4D8D182E.90101@gmail.com> Date: Fri, 25 Mar 2011 15:33:18 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 22:31:46 -0000 Meadhbh Hamrick wrote: > so what would you replace LLSD with? There is no reason to replace LLSD. If I did, it wouldn't be with JSON. It strange to see how JSON was suppose to be simple eval(), yet now how turned into the same direction SQL statements have with injection problems. JSON has become complex, and maybe now people see why XML is simpler. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From izzyalanis@gmail.com Fri Mar 25 15:51:16 2011 Return-Path: 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 5771228C0FB for ; Fri, 25 Mar 2011 15:51:16 -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 Qdke2cSFmj18 for ; Fri, 25 Mar 2011 15:51:15 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B778C28C0E3 for ; Fri, 25 Mar 2011 15:51:14 -0700 (PDT) Received: by fxm15 with SMTP id 15so1635700fxm.31 for ; Fri, 25 Mar 2011 15:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jqaEUI3B2p4aTszbVWC8z86PDJexnULkRF2H3lzbdNs=; b=H2MzTpzxkDAZU85QuBBrjUuzSSkxi/khg6rCBHiE9AVDnEfmLwHwNdvagSXnBjmuwl iHEMUWIdhlbKpQs1HlbIFDFcj+JpkXOQZddd+q4rQv1GEscT5w4Lkcr1lYGAd4cSju7o pvhzdFXX3ZI8vTZcA3/qMXUr5P9ol0Vds1wNk= 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 :cc:content-type; b=kOupRiD0Ldw1pPLyOmDVU1SwW7K7TODNx1QWAmGNbhP+wX0w5RJL5ahvWFn8LmcFOF BGxjWrogspXcQZrDumOCsV60ODLG7r6obDCPE9PJjy81NZbqFEkB2CNGcgq9XXlljC9n fbdignEt2BMgOy19LuVBD1xvGey29qdXNaOGM= MIME-Version: 1.0 Received: by 10.223.127.210 with SMTP id h18mr1516105fas.67.1301093569667; Fri, 25 Mar 2011 15:52:49 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Fri, 25 Mar 2011 15:52:49 -0700 (PDT) In-Reply-To: <4D8D182E.90101@gmail.com> References: <4D8D182E.90101@gmail.com> Date: Fri, 25 Mar 2011 18:52:49 -0400 Message-ID: From: Izzy Alanis To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org, Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 22:51:16 -0000 No, not JSON. If protobuf/protocol buffers were a formal standard, I would unhesitatingly say protocol buffers. Since it's not a formal standard, I say... protocol buffers. Just with hesitation. To be fair, the binary serialization of LLSD + LLIDL isn't all that different from protobuf (at least at some level). But it feels wrong to rely on a serialization format made specifically for virtual worlds. We don't want to re-invent the transport level protocols, why do we want to invent our own data serialization and interface definition formats? LLSD implementations aren't going to be as thoroughly reviewed, bug fixed, optimized, and readily available as an actively-developed protocol-agnostic format like protobuf. Maybe there was a good argument for LLSD when LL was still involved, but why now? Other than historical reasons? On Fri, Mar 25, 2011 at 6:33 PM, Dzonatas Sol wrote: > Meadhbh Hamrick wrote: >> >> so what would you replace LLSD with? > > > There is no reason to replace LLSD. If I did, it wouldn't be with JSON. It > strange to see how JSON was suppose to be simple eval(), yet now how turned > into the same direction SQL statements have with injection problems. JSON > has become complex, and maybe now people see why XML is simpler. > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > From djshag@hotmail.com Fri Mar 25 16:01:51 2011 Return-Path: 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 9D95128C0F7 for ; Fri, 25 Mar 2011 16:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 yqRQLrq+BROz for ; Fri, 25 Mar 2011 16:01:50 -0700 (PDT) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by core3.amsl.com (Postfix) with ESMTP id 49A3028C0ED for ; Fri, 25 Mar 2011 16:01:50 -0700 (PDT) Received: from BLU159-DS11 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 16:03:26 -0700 X-Originating-IP: [184.163.193.51] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: References: In-Reply-To: Date: Fri, 25 Mar 2011 19:03:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 25 Mar 2011 23:03:26.0136 (UTC) FILETIME=[D9013380:01CBEB40] Cc: Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 23:01:51 -0000 The more the protocol is standard the more it will attract new user to it, I mean if we choose XML, there's alot of people who already know / use XML. It will be easier for them without learning a completely new set of tools. What is important for VWRAP is that in the end it get adopted by as many game developer as possible. So using the standards the industry has to offer seem just the right thing to do. -----Message d'origine----- From: Izzy Alanis Sent: Friday, March 25, 2011 6:52 PM To: Dzonatas Sol Cc: vwrap@ietf.org ; Meadhbh Hamrick ; Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group No, not JSON. If protobuf/protocol buffers were a formal standard, I would unhesitatingly say protocol buffers. Since it's not a formal standard, I say... protocol buffers. Just with hesitation. To be fair, the binary serialization of LLSD + LLIDL isn't all that different from protobuf (at least at some level). But it feels wrong to rely on a serialization format made specifically for virtual worlds. We don't want to re-invent the transport level protocols, why do we want to invent our own data serialization and interface definition formats? LLSD implementations aren't going to be as thoroughly reviewed, bug fixed, optimized, and readily available as an actively-developed protocol-agnostic format like protobuf. Maybe there was a good argument for LLSD when LL was still involved, but why now? Other than historical reasons? On Fri, Mar 25, 2011 at 6:33 PM, Dzonatas Sol wrote: > Meadhbh Hamrick wrote: >> >> so what would you replace LLSD with? > > > There is no reason to replace LLSD. If I did, it wouldn't be with JSON. It > strange to see how JSON was suppose to be simple eval(), yet now how > turned > into the same direction SQL statements have with injection problems. JSON > has become complex, and maybe now people see why XML is simpler. > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap From izzyalanis@gmail.com Fri Mar 25 17:53:38 2011 Return-Path: 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 5C95728C0F0 for ; Fri, 25 Mar 2011 17:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 E7ZgrJYI0F8s for ; Fri, 25 Mar 2011 17:53:37 -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 32A4428C0CE for ; Fri, 25 Mar 2011 17:53:37 -0700 (PDT) Received: by vws12 with SMTP id 12so1331656vws.31 for ; Fri, 25 Mar 2011 17:55:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=shEnP+1wmemf5ETlR0pjBiZyp0q06Ffr31/yrIgA02E=; b=BM+yc/Fe0F48giQfmoZ2NvBSY7Yrbix3vPO62cR3n63em/vs5542d5vv/qiGLronWL rruuCfXPZ1cVpJ6rynXlewxaQTLVIhksW39UBok8BglofJXuA76wTvGL5avgxBJZilQN 8+G2W2g3HkTGl2GQpwCEn/pC5/IuLhlJQFONs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=GMq8P3ypl0BEOQPCwCjwToE7t+Id6HwqunFdZfvLy2Icc23Vwh7QDlUuu1C0ppNBGL cwg70O5RrC090JTEqw75bbYAYHphXRKQA+neym+aHzdKXKUTxRJISZTr00iupCR9X+Qf WO+4dSigVyUXBlti2qcVfXaFkTAHm+0mrpK88= Received: by 10.52.76.195 with SMTP id m3mr1974195vdw.130.1301100912451; Fri, 25 Mar 2011 17:55:12 -0700 (PDT) Received: from [192.168.1.102] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id q13sm335860vdu.29.2011.03.25.17.55.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 25 Mar 2011 17:55:11 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148) From: Izzy Alanis Date: Fri, 25 Mar 2011 20:55:07 -0400 To: Patnad Babii Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 00:53:38 -0000 Was that an argument for or against LLSD? Of course this all may not matter unless somebody actually addresses the und= erlying issue: That the group needs to start producing documents. - Izzy On Mar 25, 2011, at 7:03 PM, "Patnad Babii" wrote: > The more the protocol is standard the more it will attract new user to it,= I > mean if we choose XML, there's alot of people who already know / use XML. > It will be easier for them without learning a completely new set of tools.= >=20 > What is important for VWRAP is that in the end it get adopted by as many > game developer as possible. So using the standards the industry has to off= er > seem just the right thing to do. >=20 > -----Message d'origine----- From: Izzy Alanis > Sent: Friday, March 25, 2011 6:52 PM > To: Dzonatas Sol > Cc: vwrap@ietf.org ; Meadhbh Hamrick ; Barry Leiba > Subject: Re: [vwrap] Status and future of the VWRAP working group >=20 > No, not JSON. >=20 > If protobuf/protocol buffers were a formal standard, I would > unhesitatingly say protocol buffers. Since it's not a formal standard, > I say... protocol buffers. Just with hesitation. >=20 > To be fair, the binary serialization of LLSD + LLIDL isn't all that > different from protobuf (at least at some level). But it feels wrong > to rely on a serialization format made specifically for virtual > worlds. >=20 > We don't want to re-invent the transport level protocols, why do we > want to invent our own data serialization and interface definition > formats? LLSD implementations aren't going to be as thoroughly > reviewed, bug fixed, optimized, and readily available as an > actively-developed protocol-agnostic format like protobuf. Maybe there > was a good argument for LLSD when LL was still involved, but why now? > Other than historical reasons? >=20 >=20 >=20 > On Fri, Mar 25, 2011 at 6:33 PM, Dzonatas Sol wrote: >> Meadhbh Hamrick wrote: >>>=20 >>> so what would you replace LLSD with? >>=20 >>=20 >> There is no reason to replace LLSD. If I did, it wouldn't be with JSON. I= t >> strange to see how JSON was suppose to be simple eval(), yet now how turn= ed >> into the same direction SQL statements have with injection problems. JSON= >> has become complex, and maybe now people see why XML is simpler. >>=20 >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >>=20 >>=20 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap=20 > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap From vaughn.deluca@gmail.com Sat Mar 26 02:39:33 2011 Return-Path: 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 B8FC93A6907 for ; Sat, 26 Mar 2011 02:39:33 -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 aW3S8vQQM-0j for ; Sat, 26 Mar 2011 02:39:32 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id EF8EA3A690B for ; Sat, 26 Mar 2011 02:39:31 -0700 (PDT) Received: by eye13 with SMTP id 13so779005eye.31 for ; Sat, 26 Mar 2011 02:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZANYbmLe0LgX0pDMORChZm6ovrnF52X/oecLgQU+wPU=; b=JpmYnhZ9AOlOt6UsnfmTSz9hGSiAox4Zlwl3SQbvG8JriG2X/OVIrEzICq1TudRmAK rgQ0/ggSoVfueI29cw+O51g6OhuOZljDEaxZlwRv+ToDGD5wagtmPYTb6GskNT44ZDvw 2i66eB5HF8dwTSEhJvbAo1I6Apu0vwGARTFCE= 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 :cc:content-type; b=XfeXORkyyGj5Idfo4uuNbRamdq011mLvvoHojLntibD82L41zfMF/0tI0IcFtozoV5 V20cKmcIspRP4woauOGrzKxLLuspr5Wx7WZokvP9fz9ac2DIn+Eb17pnRThspN/hZUJt c9II4QL61FyEWtk3IZV3Wp0O8+on8G+i26FvY= MIME-Version: 1.0 Received: by 10.213.35.194 with SMTP id q2mr322713ebd.100.1301132467049; Sat, 26 Mar 2011 02:41:07 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sat, 26 Mar 2011 02:41:06 -0700 (PDT) In-Reply-To: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> Date: Sat, 26 Mar 2011 10:41:06 +0100 Message-ID: From: Vaughn Deluca To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 09:39:33 -0000 Right, we need to produce documents. Part of the reason we are stalled is that the current drafts were critisized, most notably by Morgaine, but no concrete steps were taken to follow up on the critisism. So, i agree with Katherine her proposal (in another tread) and suggest we keep working within the current charter. What we could do is the absolute bare minimum of change to the drafts to keep us floating, and start a campaign for new blood. This is such a cool project, i simply can't imagine we wont be able to attract some new people that can help to make it happen. -- Vaughn On 3/26/11, Izzy Alanis wrote: > Was that an argument for or against LLSD? > > Of course this all may not matter unless somebody actually addresses the > underlying issue: That the group needs to start producing documents. > > - Izzy > > > On Mar 25, 2011, at 7:03 PM, "Patnad Babii" wrote: > >> The more the protocol is standard the more it will attract new user to it, >> I >> mean if we choose XML, there's alot of people who already know / use XML. >> It will be easier for them without learning a completely new set of tools. >> >> What is important for VWRAP is that in the end it get adopted by as many >> game developer as possible. So using the standards the industry has to >> offer >> seem just the right thing to do. >> >> -----Message d'origine----- From: Izzy Alanis >> Sent: Friday, March 25, 2011 6:52 PM >> To: Dzonatas Sol >> Cc: vwrap@ietf.org ; Meadhbh Hamrick ; Barry Leiba >> Subject: Re: [vwrap] Status and future of the VWRAP working group >> >> No, not JSON. >> >> If protobuf/protocol buffers were a formal standard, I would >> unhesitatingly say protocol buffers. Since it's not a formal standard, >> I say... protocol buffers. Just with hesitation. >> >> To be fair, the binary serialization of LLSD + LLIDL isn't all that >> different from protobuf (at least at some level). But it feels wrong >> to rely on a serialization format made specifically for virtual >> worlds. >> >> We don't want to re-invent the transport level protocols, why do we >> want to invent our own data serialization and interface definition >> formats? LLSD implementations aren't going to be as thoroughly >> reviewed, bug fixed, optimized, and readily available as an >> actively-developed protocol-agnostic format like protobuf. Maybe there >> was a good argument for LLSD when LL was still involved, but why now? >> Other than historical reasons? >> >> >> >> On Fri, Mar 25, 2011 at 6:33 PM, Dzonatas Sol wrote: >>> Meadhbh Hamrick wrote: >>>> >>>> so what would you replace LLSD with? >>> >>> >>> There is no reason to replace LLSD. If I did, it wouldn't be with JSON. >>> It >>> strange to see how JSON was suppose to be simple eval(), yet now how >>> turned >>> into the same direction SQL statements have with injection problems. JSON >>> has become complex, and maybe now people see why XML is simpler. >>> >>> -- >>> --- https://twitter.com/Dzonatas_Sol --- >>> Web Development, Software Engineering, Virtual Reality, Consultant >>> >>> >> _______________________________________________ >> 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From carlo@alinoe.com Sat Mar 26 06:35:26 2011 Return-Path: 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 8955E28C11D for ; Sat, 26 Mar 2011 06:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YMJ-SSx7Rn+9 for ; Sat, 26 Mar 2011 06:35:25 -0700 (PDT) Received: from fep13.mx.upcmail.net (fep13.mx.upcmail.net [62.179.121.33]) by core3.amsl.com (Postfix) with ESMTP id 6B4B228C0E4 for ; Sat, 26 Mar 2011 06:35:23 -0700 (PDT) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep13-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110326133657.DGNP1429.viefep13-int.chello.at@edge04.upcmail.net>; Sat, 26 Mar 2011 14:36:57 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upcmail.net with edge id Ppcu1g00m0FlQed04pcv7o; Sat, 26 Mar 2011 14:36:57 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q3Tfh-0007wL-TE; Sat, 26 Mar 2011 14:36:53 +0100 Date: Sat, 26 Mar 2011 14:36:53 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20110326133653.GA29908@alinoe.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=Nww7yNiXF4C1XGF+VcigPkOcTpD8wJaI1KQuZlH5eEk= c=1 sm=0 a=XYJHFtupD_QA:10 a=I88v0MqpzI0A:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=r9cYBvqfzYhskfJq4fwA:9 a=-6W7LLLrGa7wphYUMZQA:7 a=8QxCeFQG9zA7VZnz0fh1EmVNekwA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:35:26 -0000 On Fri, Mar 25, 2011 at 04:42:37PM +0100, Vaughn Deluca wrote: > Absolute radio silence on the list... > VWRAP is clearly in a crisis. The major players have all moved on, > and those who are left do not seem to be able to generate the needed > energy to carry the project forward. [...] > So it seems its time to take a vote, how many of us are *at all* > interested in keeping VWRAP alive? I cant believe we will simply give > up. Are we really forced to conclude we no longer have enough core > participation? The reason I abandonned this project (as in: stopped replying and even reading it) is because (back then) certain "major players" completely dominated the whole effort. This effort was clearly carried by a few companies at the time, and major decisions were made behind the scenes, not on the list. They were made by individuals with enough company behind them to be taken (too) seriously; but individuals nevertheless (I don't believe(d) for a second that they really were backed up by other PEOPLE). If people take airplanes to meet somewhere face to face while staying in hotels and then claim that that is the only place where "real work can be done" then they shut people like me completely out. If people write HUGE documents with exclusively their own ideas, claiming it is really what their (huge) commercial companies wants and basically dooming the project without the support of that company, and mostly ignoring the "little people" on this list... It clearly made no difference how much effort I'd put into this project. I'd alway be considered to be a nobody and not be listened to these "major players". What is wrong here is that I *AM* a major player (or could be): I have a lot of time, a lot experience and a lot of analytic insight and understanding of complex communication protocols. I just don't have a company behind me; so nobody cared if I'd leave; so it was very easy to just ignore me and only concentrate on making a consensus with those "who mattered". The Right Thing to do would be to make all decisions on the list, after discussions on the list and treating everyone equal; or well, treating the more intelligent people more equal than those who don't have an idea what they are saying perhaps - but not only listening to those who have a lot of weight in commercial terms. In particular-- and please note that I never said a single word about this before: I just silently left, but now, in the light of this post I feel it is required to mention it-- I left because of the role that Meadhbh Hamrick had taken. At the time he was still working for Linden Lab and doing all of the above wrong, often in an almost autistic and certainly self-centered way. He left no room whatsoever to get into the discussion / project in a reasonable way. When I decided to give up, the exact words that I thought were: I might get back if Meadhbh leaves the project, but not before. There was some short lived hope when he left Linden Lab... I'm still waiting and have no intention to put (waste) time here as long as he's part of this team. Sorry to be this blunt-- but I thought you wanted to know (from everyone) why they backed out and stopped being responsive. So here is my story. -- Carlo Wood From carlo@alinoe.com Sat Mar 26 06:39:17 2011 Return-Path: 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 12B0628C120 for ; Sat, 26 Mar 2011 06:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 MtYiNKMKoUEn for ; Sat, 26 Mar 2011 06:39:16 -0700 (PDT) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id D8BC628C0E4 for ; Sat, 26 Mar 2011 06:39:15 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110326134050.CIEY23900.viefep20-int.chello.at@edge01.upcmail.net>; Sat, 26 Mar 2011 14:40:50 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id Ppgp1g00Q0FlQed01pgqkS; Sat, 26 Mar 2011 14:40:50 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q3TjU-0007yQ-Ut; Sat, 26 Mar 2011 14:40:48 +0100 Date: Sat, 26 Mar 2011 14:40:48 +0100 From: Carlo Wood To: Izzy Alanis Message-ID: <20110326134048.GB29908@alinoe.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=zlRBWuFCZaNL9+WHNm1pWLowY5Lx061w2zJBJiDkNAU= c=1 sm=0 a=XYJHFtupD_QA:10 a=I88v0MqpzI0A:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=k_xgfghwNV3msoiHwaoA:9 a=gWOXB55ZkvO2F2s0pYkbiyu1A6UA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:39:17 -0000 On Fri, Mar 25, 2011 at 04:34:39PM -0400, Izzy Alanis wrote: > document?", I start to think about the abstract type system, the very > first bullet point in the charter, and I think about the crap that is > LLSD (no offense to the folks at Linden Labs) and then I think about Same here. If I'd be in charge of this project, we'd start from SCRATCH. We'd start by making a list of things we want and need, not start from some old heritage and try to force and mold it at all costs into VWRAP. There are a few very essential things wrong with the core of the current design. It's also not flexible enough. The current draft is exclusively aimed at defending the market position of a dieing company and has nothing to do with what would be technically the best protocol. -- Carlo Wood From carlo@alinoe.com Sat Mar 26 06:51:49 2011 Return-Path: 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 2DB9428C0F6 for ; Sat, 26 Mar 2011 06:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 bhSB-5MJ5N1Z for ; Sat, 26 Mar 2011 06:51:48 -0700 (PDT) Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id AEABD28C0D9 for ; Sat, 26 Mar 2011 06:51:47 -0700 (PDT) Received: from edge01.upcmail.net ([192.168.13.236]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110326135322.KTKL11401.viefep17-int.chello.at@edge01.upcmail.net>; Sat, 26 Mar 2011 14:53:22 +0100 Received: from mail9.alinoe.com ([77.250.43.12]) by edge01.upcmail.net with edge id PptM1g00h0FlQed01ptNlf; Sat, 26 Mar 2011 14:53:22 +0100 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q3Tvc-00083r-Vf; Sat, 26 Mar 2011 14:53:21 +0100 Date: Sat, 26 Mar 2011 14:53:20 +0100 From: Carlo Wood To: Vaughn Deluca Message-ID: <20110326135320.GC29908@alinoe.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=XYJHFtupD_QA:10 a=I88v0MqpzI0A:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=14yIOYk_akUCbEsk-0UA:9 a=9aWhtts-6l-QXUDvAMEA:7 a=VQGJIrWFVTaIAJQsCgau-qoqB0wA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 13:51:49 -0000 On Sat, Mar 26, 2011 at 10:41:06AM +0100, Vaughn Deluca wrote: > Right, we need to produce documents. Part of the reason we are stalled > is that the current drafts were critisized, most notably by Morgaine, > but no concrete steps were taken to follow up on the critisism. I respect Morgaine (although I don't always agree with her) for the time she has put to keeping people aware of what was going on. And if her efforts are the reason that the project stalled then YAY! That was one hell of job. I didn't have the time to it myself, but I think it's a step forwards. Anything but just one or two people dominating the list, producing documents and causing anyone who oppose (like me) to go silent, and then God Forbid - turning that into a standard. > So, i agree with Katherine her proposal (in another tread) and suggest > we keep working within the current charter. What we could do is the > absolute bare minimum of change to the drafts to keep us floating, and No... See, that's where you make a fatal mistake of taking a step backwards. This is not about pushing SOME "standard" at all costs. It's about designing a standard that is clearly technically the best, so that everyone agrees with that. Imho, we need to start from scratch. Oops, no I said 'we'... but count me out. I still see the same people around here and it's still going to fail just as bad as last time (or, as I expected the first time around... some "standard" is going to be produced that sucks; and that is either going to be ignored, or adopted by a few large "players" who then all get major head aches and problems that they can't fix; and in the end it will be the users who suffer most from having a bad protocol of course :/. > start a campaign for new blood. This is such a cool project, i simply > can't imagine we wont be able to attract some new people that can help > to make it happen. > > -- Vaughn From barryleiba@gmail.com Sat Mar 26 07:39:07 2011 Return-Path: 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 C6DEA28C0D8 for ; Sat, 26 Mar 2011 07:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=-0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 v02HNHSrLarE for ; Sat, 26 Mar 2011 07:39:06 -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 D590928B797 for ; Sat, 26 Mar 2011 07:39:06 -0700 (PDT) Received: by iye19 with SMTP id 19so1716842iye.31 for ; Sat, 26 Mar 2011 07:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=U4vhJk8z9AiqQUoD6midonV7YGRhegVQ7JIQW42E23Q=; b=SSJP2N5H78ml9UkeqNZtomGNg5ioSrPZA32zEibJ8sWBDuK7stNI/c67qYXkK1uIqL Tzw7WSW7HhP9GreHnWI+6usxkC5vu3njizM8TnxM0n62KSWo1gyWsRwdHmeiJU/0q9Yg dIEY9pIdypBOtC2BJkVIeZqEQeashdzr66DN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=m60dFXrEA/33PiFe7N5BQXpn/dQrUJC5Six/cdhaEQgqT67Sh3BsFlfHH7sojXJ/es G6wMxI8Xrtu2SLdTxBwPvs0ai2Ifab//zoTLbH8befcorqZ5DTm/81sMsvnLgdZ55BlB sGsJYGPrC7P8lkRPprR4E15aQSx+bajWgV6rs= MIME-Version: 1.0 Received: by 10.231.128.199 with SMTP id l7mr1910335ibs.150.1301150442889; Sat, 26 Mar 2011 07:40:42 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.19.193 with HTTP; Sat, 26 Mar 2011 07:40:42 -0700 (PDT) In-Reply-To: <20110326135320.GC29908@alinoe.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Sat, 26 Mar 2011 10:40:42 -0400 X-Google-Sender-Auth: q389iOxhmY89JRd8bhjZgx1gK7o Message-ID: From: Barry Leiba To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 14:39:07 -0000 Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. I'm glad to see some discussion going. Izzy is right when he says this: > Of course this all may not matter unless somebody actually addresses > the underlying issue: That the group needs to start producing documents. Indeed. We, the chairs, need to see real progress on the documents... particularly the introduction document. This discussion is a start, and, as I say, I'm pleased to see it, but it has to turn into real document editing very soon. I want to say one other thing: > Oops, no I said 'we'... but count me out. I still see the same people > around here and it's still going to fail just as bad as last time (or, > as I expected the first time around... some "standard" is going to > be produced that sucks; and that is either going to be ignored, or > adopted by a few large "players" who then all get major head aches > and problems that they can't fix; and in the end it will be the users > who suffer most from having a bad protocol of course :/. Carlo, Meadhbh is still around, thought she (note gender) has given up the editorship of the documents. Your input is welcome -- encouraged -- though, of course, if you choose not to participate for whatever reason, that's your choice. I think choosing not to participate because some particular person is also participating is a poor choice, but it's your choice to make. I would like to see you reconsider that, if you're willing to do the work. What I do *not* want to see, and what we won't tolerate, are personal attacks on any participant here. Do not engage in name-calling, do not question people's integrity, do not malign the companies they work for, and do not accuse people of malfeasance because they disagree with you. If you present your ideas and others agree with what you say, those ideas will make it forward. That's how we aim to work, here, and if this working group can continue and make progress, that's indeed how we'll work. So... will we make some progress on the intro document? Can we get some real discussion on it, and a draft that shows some level of consensus within the nest few weeks? Barry, as chair From djshag@hotmail.com Sat Mar 26 08:01:44 2011 Return-Path: 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 92DBE3A693B for ; Sat, 26 Mar 2011 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 U3IYORoxKWer for ; Sat, 26 Mar 2011 08:01:42 -0700 (PDT) Received: from blu0-omc2-s2.blu0.hotmail.com (blu0-omc2-s2.blu0.hotmail.com [65.55.111.77]) by core3.amsl.com (Postfix) with ESMTP id 442113A690A for ; Sat, 26 Mar 2011 08:01:42 -0700 (PDT) Received: from BLU159-DS7 ([65.55.111.72]) by blu0-omc2-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 08:03:18 -0700 X-Originating-IP: [184.163.193.51] X-Originating-Email: [djshag@hotmail.com] Message-ID: From: "Patnad Babii" To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com><20110326135320.GC29908@alinoe.com> In-Reply-To: Date: Sat, 26 Mar 2011 11:03:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-OriginalArrivalTime: 26 Mar 2011 15:03:18.0401 (UTC) FILETIME=[F0AB6F10:01CBEBC6] Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 15:01:44 -0000 What we should focus on, is this I believe, are we going to keep LLSD (is it good enought). Is it really needed or shall we start from scratch, with the aim of using some new viewer / browser. Opensim (open source virtual platform with alot of grids already) is using LLSD, especially because the viewer LL made is using LLSD. To be honest I keep saying since the beginning of these working groups (the various ones, ogpx, vwrap, mmox..) we should put aside the existing stuff, work more with Opensim, since they are the key to this new journey that is open virtual worlds, its good they have HyperGrid already which does some amazing stuff! What we need is a consensus, something we all agree on and go forward with the docs. -----Message d'origine----- From: Barry Leiba Sent: Saturday, March 26, 2011 10:40 AM To: Carlo Wood Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. I'm glad to see some discussion going. Izzy is right when he says this: > Of course this all may not matter unless somebody actually addresses > the underlying issue: That the group needs to start producing documents. Indeed. We, the chairs, need to see real progress on the documents... particularly the introduction document. This discussion is a start, and, as I say, I'm pleased to see it, but it has to turn into real document editing very soon. I want to say one other thing: > Oops, no I said 'we'... but count me out. I still see the same people > around here and it's still going to fail just as bad as last time (or, > as I expected the first time around... some "standard" is going to > be produced that sucks; and that is either going to be ignored, or > adopted by a few large "players" who then all get major head aches > and problems that they can't fix; and in the end it will be the users > who suffer most from having a bad protocol of course :/. Carlo, Meadhbh is still around, thought she (note gender) has given up the editorship of the documents. Your input is welcome -- encouraged -- though, of course, if you choose not to participate for whatever reason, that's your choice. I think choosing not to participate because some particular person is also participating is a poor choice, but it's your choice to make. I would like to see you reconsider that, if you're willing to do the work. What I do *not* want to see, and what we won't tolerate, are personal attacks on any participant here. Do not engage in name-calling, do not question people's integrity, do not malign the companies they work for, and do not accuse people of malfeasance because they disagree with you. If you present your ideas and others agree with what you say, those ideas will make it forward. That's how we aim to work, here, and if this working group can continue and make progress, that's indeed how we'll work. So... will we make some progress on the intro document? Can we get some real discussion on it, and a draft that shows some level of consensus within the nest few weeks? Barry, as chair _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap From dzonatas@gmail.com Sat Mar 26 08:37:49 2011 Return-Path: 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 152093A68C0 for ; Sat, 26 Mar 2011 08:37:49 -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 Qf9l2cgHvm-o for ; Sat, 26 Mar 2011 08:37:48 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 1EAC43A6859 for ; Sat, 26 Mar 2011 08:37:48 -0700 (PDT) Received: by pzk30 with SMTP id 30so399596pzk.31 for ; Sat, 26 Mar 2011 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wNY9aIWBGOQ0RMk4MQJ3aBDqxVDUR6U7jW9CK7DSTUA=; b=TElJqRYLEH4R25CupMGKApoO80ncDKWt/giCY0CfzsyHDtQjFTgBKXy2SS7h5ZGbXt xKaueijS2GSzz3VX/PARJsYdLd30VK+n2PhgbR+Wpltwi1VyJU8cP64OhiR76wuSszyQ rQLRruXcxHMoYJf7VFyzzdaVCAusOWRanQbpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=lbCDl7arr7NwAjVB70UIKOqFtk+96cYJP+jdBrLLiK2VNyCL959AR3rJFO9SSBFuBE BL0m3puuKc8xf/wQxJaTSEp8Oue8khYA4Ao9PjKshvulHHHyNyaTjvIqC3WS23WceyTE gWogoRwnqNGPuPFfovxUm3EJ3CjPfG3Mjhpaw= Received: by 10.142.224.17 with SMTP id w17mr1834139wfg.13.1301153964171; Sat, 26 Mar 2011 08:39:24 -0700 (PDT) Received: from [192.168.0.50] (adsl-70-133-76-153.dsl.scrm01.sbcglobal.net [70.133.76.153]) by mx.google.com with ESMTPS id x11sm2982350wfd.1.2011.03.26.08.39.22 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 08:39:22 -0700 (PDT) Message-ID: <4D8E08AB.6060707@gmail.com> Date: Sat, 26 Mar 2011 08:39:23 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Patnad Babii References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com><20110326135320.GC29908@alinoe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 15:37:49 -0000 Patnad Babii wrote: > To be honest I keep saying since the beginning of these working groups > (the various ones, ogpx, vwrap, mmox..) we should put aside the > existing stuff, work more with Opensim, since they are the key to this > new journey that is open virtual worlds, its good they have HyperGrid > already which does some amazing stuff! OpenSim is not open in direction of development; therefore, we can not use opensim and expect to be free from their direction. Just because we do not agree with their client/server terminology should be no reason for them to assume out-of-bound attitudes towards anybody is ok. The goal of opensim/lib was to reverse engineer the SL protocol, not to develop one from an open basis from scratch. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From izzyalanis@gmail.com Sat Mar 26 08:53:15 2011 Return-Path: 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 6029C3A68C0 for ; Sat, 26 Mar 2011 08:53:15 -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 k7J+meCR6Mm1 for ; Sat, 26 Mar 2011 08:53:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id D37073A6407 for ; Sat, 26 Mar 2011 08:53:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so1951190fxm.31 for ; Sat, 26 Mar 2011 08:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4tbTGP1Z7oFZX2JoPY1OQ1EwcO+Wld3QB16ie838eG8=; b=XnZtwEy03eeBzfUFy+PF5xHzLngR4xtVmHZ+5jM7u5EBaRQntickENQh0AsShG6S3R s0x/K6uMCJjWpne8BhbV99YKTJzAMNpSEICHVFq56UZ25NJEGXmn14EQ3QM3//ISisOS kWHMitgwzZQ4/HyxFeroyUoHox2m2tmKo6Grg= 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 :cc:content-type:content-transfer-encoding; b=i4lDnAIW+DqiTS/n0N+Y4paxOdooLkmC6bsV9lfu+GCZSE2LPrWLEa5tNaMIrD8HC3 Pq3+Y9hAjrNisvzNB1rLiSxExkkpTdL7Tu8vLXIeW+7v9J1LX8R+iqnUJppg+hdhyHaY AsTvk9gCcgUAdyFfx0p4qAp/RnZli0OfQhTPg= MIME-Version: 1.0 Received: by 10.223.24.72 with SMTP id u8mr2363131fab.10.1301154887778; Sat, 26 Mar 2011 08:54:47 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sat, 26 Mar 2011 08:54:47 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Sat, 26 Mar 2011 11:54:47 -0400 Message-ID: From: Izzy Alanis To: Patnad Babii Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 15:53:15 -0000 +1 to: put aside the existing stuff For the purposes of the Intro doc, I think it would be possible to table the decision between LLSD/LLIDL and something else (protobuf) for the abstract type system / interface descriptions *if* the doc was couched in terms of a VWRAP-IDL that we then specify/decide on in the following IDL/type system doc. One thing we should make a decision on, and that I think is fuzzy in the draft-hamrick-vwrap-intro-01 doc, is whether the serializations are negotiated between services, or whether VWRAP mandates LLSD as the only approved serialization. Sections 2.3.1: "Web-based applications may choose to use JSON or XML. Server-to-server interactions may use the VWRAP specific binary serialization scheme..." Seems to conflict with (2.3.3): " VWRAP uses the LLSD abstract type system and the LLIDL interface description language to describe the structure and type semantics of elements in messages sent between systems. Because LLSD makes extensive use of variable width, clearly delineated data fields, services which consume protocol messages may identify and extract only those message elements they know how to handle." I'd like to take this opportunity to point out that protobuff supports the same variable width, extensibility, default values, yada yada yada. we could couch that in terms of only the IDL, and leave serialization of messages up to content negotiation between services involved. On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii wrote: > What we should focus on, is this I believe, are we going to keep LLSD (is= it > good enought). Is it really needed or shall we start from scratch, with t= he > aim of using some new viewer / browser. > > Opensim (open source virtual platform with alot of grids already) is usin= g > LLSD, especially because the viewer LL made is using LLSD. > > To be honest I keep saying since the beginning of these working groups (t= he > various ones, ogpx, vwrap, mmox..) we should put aside the existing stuff= , > work more with Opensim, since they are the key to this new journey that i= s > open virtual worlds, its good they have HyperGrid already which does some > amazing stuff! > > What we need is a consensus, something we all agree on and go forward wit= h > the docs. > > -----Message d'origine----- From: Barry Leiba > Sent: Saturday, March 26, 2011 10:40 AM > To: Carlo Wood > Cc: vwrap@ietf.org > Subject: Re: [vwrap] Status and future of the VWRAP working group > > Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. > I'm glad to see some discussion going. =A0Izzy is right when he says this= : >> >> Of course this all may not matter unless somebody actually addresses >> the underlying issue: That the group needs to start producing documents. > > Indeed. =A0We, the chairs, need to see real progress on the documents... > particularly the introduction document. > > This discussion is a start, and, as I say, I'm pleased to see it, but > it has to turn into real document editing very soon. > > I want to say one other thing: > >> Oops, no I said 'we'... but count me out. I still see the same people >> around here and it's still going to fail just as bad as last time (or, >> as I expected the first time around... some "standard" is going to >> be produced that sucks; and that is either going to be ignored, or >> adopted by a few large "players" who then all get major head aches >> and problems that they can't fix; and in the end it will be the users >> who suffer most from having a bad protocol of course :/. > > Carlo, Meadhbh is still around, thought she (note gender) has given up > the editorship of the documents. =A0Your input is welcome -- encouraged > -- though, of course, if you choose not to participate for whatever > reason, that's your choice. =A0I think choosing not to participate > because some particular person is also participating is a poor choice, > but it's your choice to make. =A0I would like to see you reconsider > that, if you're willing to do the work. > > What I do *not* want to see, and what we won't tolerate, are personal > attacks on any participant here. =A0Do not engage in name-calling, do > not question people's integrity, do not malign the companies they work > for, and do not accuse people of malfeasance because they disagree > with you. =A0If you present your ideas and others agree with what you > say, those ideas will make it forward. =A0That's how we aim to work, > here, and if this working group can continue and make progress, that's > indeed how we'll work. > > So... will we make some progress on the intro document? =A0Can we get > some real discussion on it, and a draft that shows some level of > consensus within the nest few weeks? > > Barry, as chair > _______________________________________________ > 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 > From ohmeadhbh@gmail.com Sat Mar 26 09:52:17 2011 Return-Path: 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 9E0953A67A8 for ; Sat, 26 Mar 2011 09:52:17 -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 NDRTL1WEYolx for ; Sat, 26 Mar 2011 09:52:16 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 244B33A6783 for ; Sat, 26 Mar 2011 09:52:16 -0700 (PDT) Received: by qyk29 with SMTP id 29so279907qyk.10 for ; Sat, 26 Mar 2011 09:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=IRedFxC1jNRSmztekJ3uDFBN6JaCVSrEHbbILw2KaA8=; b=TfBBL4XovLTDPH0hLLbx5IdSDOw/iDwNnHjLu1YetO20cXOBtb3XYUPvVCrvgH/Yl6 W80bpbn4yS70TuINaNoyNRCjeyEEdygmFbtRRc2RAhlEhfxKkY36iRH7DOX0Iv1XnvED C90zW9YN82w1y8QHNKUuuZivQxmbAQbybXc+w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Aotp34jrR0Gr2zXsUVfN07vV1cXKO50cKeS/5k51Kt0TAcG1j4Ja8xnSplEVMfgbmg kEzrEQYI3b6t87VTaMnyyWSyTNDKSNQRcutdWU583JoS4v0OKMhE4uh+5VWqnq7eivEc ZhJ41MSYPLZkP9UJxC+f6DpOXHPhzYdmBwz4E= Received: by 10.229.114.76 with SMTP id d12mr1786156qcq.147.1301158431098; Sat, 26 Mar 2011 09:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.210 with HTTP; Sat, 26 Mar 2011 09:53:31 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> From: Meadhbh Hamrick Date: Sat, 26 Mar 2011 09:53:31 -0700 Message-ID: To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 16:52:17 -0000 yup. i'm still around. the documents are in SVN. check them out and edit them. there were ( i believe ) reasons why this effort originally had a focus on SL and OpenSim: the people who organized the working group and corralled opposing viewpoints into consensus for a charter were employees of linden and ibm who had write access to linden's code repository and (at least one) of the code repositories associated with OpenSim. we were the two parties who were interested in defining interoperability for our implementations through this forum. the charter of the group was not to create an entirely new virtual world protocol, but to rectify and complete two implementations developed independently by linden and ibm. the reason things were done "behind your back" and "off the list" is that we were trying to develop an interop protocol for two implementations with differing levels of functionality and completeness. conversations on the list frequently started with: "hey, i have some code that does foo? should we still do foo or should we do bar?" and ended with a number of people talking about how we should really doing "baz" or "qux", both of which had no relation to the code or the problem domain described in the intro document and charter. that being said... having code is not a requirement for a working group, but it does seem that IETF culture is deferential towards those who produce code. now that people with an interest in this group no longer have write access to the linden code repository, that ability to produce one independent implementation of the standard has gone away. which is one of the reasons this group is rebooting. i have on several occasions offered my assistance to anyone interested in drafting a new charter or editing new documents. so far no one's taken me up on my offer. i'm still happy to do a "how to write RFCs with XML" class in-world. but again, no one's indicated an interest. barry's been calling for participation for the last couple of months. but as far as i can tell, morgaine's been the only person who's produced anything. but even that.. something like 1000 or 2000 words are probably insufficient to communicate complicated technical concepts this group is supposed to be manipulating. the cool thing about this group at this moment is if you want to take over this group and recharter it, you really have to do only a small amount of work. and honestly, if you can't manage the effort of opening a text editor and typing out five or six paragraphs that define the starting point for a new group charter, you're going to find the process of actually writing RFCs to bit much. if this group dies, it's not the end of the world for virtual worlds and standardization. i think barry's said it several times. this group failing is not going to be a major hindrance to forming another VW focused group in the future. -Cheers -Meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Mar 26, 2011 at 7:40 AM, Barry Leiba wrot= e: > Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. > I'm glad to see some discussion going. =A0Izzy is right when he says this= : >> Of course this all may not matter unless somebody actually addresses >> the underlying issue: That the group needs to start producing documents. > > Indeed. =A0We, the chairs, need to see real progress on the documents... > particularly the introduction document. > > This discussion is a start, and, as I say, I'm pleased to see it, but > it has to turn into real document editing very soon. > > I want to say one other thing: > >> Oops, no I said 'we'... but count me out. I still see the same people >> around here and it's still going to fail just as bad as last time (or, >> as I expected the first time around... some "standard" is going to >> be produced that sucks; and that is either going to be ignored, or >> adopted by a few large "players" who then all get major head aches >> and problems that they can't fix; and in the end it will be the users >> who suffer most from having a bad protocol of course :/. > > Carlo, Meadhbh is still around, thought she (note gender) has given up > the editorship of the documents. =A0Your input is welcome -- encouraged > -- though, of course, if you choose not to participate for whatever > reason, that's your choice. =A0I think choosing not to participate > because some particular person is also participating is a poor choice, > but it's your choice to make. =A0I would like to see you reconsider > that, if you're willing to do the work. > > What I do *not* want to see, and what we won't tolerate, are personal > attacks on any participant here. =A0Do not engage in name-calling, do > not question people's integrity, do not malign the companies they work > for, and do not accuse people of malfeasance because they disagree > with you. =A0If you present your ideas and others agree with what you > say, those ideas will make it forward. =A0That's how we aim to work, > here, and if this working group can continue and make progress, that's > indeed how we'll work. > > So... will we make some progress on the intro document? =A0Can we get > some real discussion on it, and a draft that shows some level of > consensus within the nest few weeks? > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Sat Mar 26 10:30:29 2011 Return-Path: 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 197CD3A67DF for ; Sat, 26 Mar 2011 10:30:29 -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 Cw3PSmGcfQ0t for ; Sat, 26 Mar 2011 10:30:26 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 369A53A67C0 for ; Sat, 26 Mar 2011 10:30:26 -0700 (PDT) Received: by qyk7 with SMTP id 7so1259361qyk.10 for ; Sat, 26 Mar 2011 10:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=BOlT0nUDuQ4gGAILEawLvumL2PsKaK7wxkdD4jkGuc8=; b=Olifn7ff0E7+BSy+LU0xST1SLsH8fJmxFF/Kp/HzkhWiMC/4DOplUNkTThZeudushL GlfwEuaMQu219PwH9zFZGAsguorRZvhDNOVul0Ts5H4s1Ru3h9wWX2ZmU/hqaqfftbGK U8M4RqZM2O1SoiZwU57eefsZ1l25rFVxq0jnc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=yBG1XijBtEmKDI/YryEZ+O+BAg8QWRL4o8Ez0IqAeMkXxHqSIBHvZ5AlGv8+xMnPXE ZTuNaCbdCB2uaOm0p8UchVQhQ1tTNMTBKhStwEUXWBBTXUbEDRbnk3E9lJnByZIWpRst sxzbOuh16dNkdvASCYDMSSGO9Reznug+IMJP4= Received: by 10.229.78.228 with SMTP id m36mr881267qck.109.1301160721318; Sat, 26 Mar 2011 10:32:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.210 with HTTP; Sat, 26 Mar 2011 10:31:40 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> From: Meadhbh Hamrick Date: Sat, 26 Mar 2011 10:31:40 -0700 Message-ID: To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 17:30:29 -0000 fwiw.. i think this discussion indicates a little confusion over what LLSD = is. LLSD is not a transfer syntax. it is an abstract type system and interface description language that defines three transfer syntaxes. ProtoBufs is not an abstract type system as it's type semantics are not defined. The objective of LLSD was to allow us to describe services independent of any particular technology. sadly, that was never made abundantly clear in the docs. but in the list discussion, many of us who had used LLSD mentioned several times that we were focusing on LLSD serialized with JSON or XML over HTTP(S), but there was no reason it couldn't be carried over XMPP or ProtoBufs. it's just that no one seemed to think those use cases were interesting enough to sit down with a text editor and whip up some code. so... even if you dump LLSD moving forward, i would encourage you to not use ProtoBufs to define service interfaces. my experience with large systems and protobufs is you have to make everything optional to cover the use case of two systems running slightly different versions of an interface. that being said, producing a map from LLSD to ProtoBufs should be pretty straight forward. but that's just my 2 cents. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Mar 26, 2011 at 8:54 AM, Izzy Alanis wrote: > +1 to: put aside the existing stuff > > For the purposes of the Intro doc, I think it would be possible to > table the decision between LLSD/LLIDL and something else (protobuf) > for the abstract type system / interface descriptions *if* the doc was > couched in terms of a VWRAP-IDL that we then specify/decide on in the > following IDL/type system doc. > > One thing we should make a decision on, and that I think is fuzzy in > the draft-hamrick-vwrap-intro-01 doc, is whether the serializations > are negotiated between services, or whether VWRAP mandates LLSD as the > only approved serialization. > > Sections 2.3.1: > =A0"Web-based applications may choose to use JSON or XML. > Server-to-server interactions may use the VWRAP specific binary > serialization scheme..." > > Seems to conflict with (2.3.3): > =A0" VWRAP uses the LLSD abstract type system and the LLIDL interface > =A0 =A0 =A0 description language to describe the structure and type seman= tics > =A0 =A0 =A0 of elements in messages sent between systems. =A0Because LLSD= makes > =A0 =A0 =A0 extensive use of variable width, clearly delineated data fiel= ds, > =A0 =A0 =A0 services which consume protocol messages may identify and ext= ract > =A0 =A0 =A0 only those message elements they know how to handle." > > I'd like to take this opportunity to point out that protobuff supports > the same variable width, extensibility, default values, yada yada > yada. > > > > > > > > > > we could couch that in terms of only the IDL, and leave serialization > of messages up to content negotiation between services involved. > > On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii wrote= : >> What we should focus on, is this I believe, are we going to keep LLSD (i= s it >> good enought). Is it really needed or shall we start from scratch, with = the >> aim of using some new viewer / browser. >> >> Opensim (open source virtual platform with alot of grids already) is usi= ng >> LLSD, especially because the viewer LL made is using LLSD. >> >> To be honest I keep saying since the beginning of these working groups (= the >> various ones, ogpx, vwrap, mmox..) we should put aside the existing stuf= f, >> work more with Opensim, since they are the key to this new journey that = is >> open virtual worlds, its good they have HyperGrid already which does som= e >> amazing stuff! >> >> What we need is a consensus, something we all agree on and go forward wi= th >> the docs. >> >> -----Message d'origine----- From: Barry Leiba >> Sent: Saturday, March 26, 2011 10:40 AM >> To: Carlo Wood >> Cc: vwrap@ietf.org >> Subject: Re: [vwrap] Status and future of the VWRAP working group >> >> Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. >> I'm glad to see some discussion going. =A0Izzy is right when he says thi= s: >>> >>> Of course this all may not matter unless somebody actually addresses >>> the underlying issue: That the group needs to start producing documents= . >> >> Indeed. =A0We, the chairs, need to see real progress on the documents... >> particularly the introduction document. >> >> This discussion is a start, and, as I say, I'm pleased to see it, but >> it has to turn into real document editing very soon. >> >> I want to say one other thing: >> >>> Oops, no I said 'we'... but count me out. I still see the same people >>> around here and it's still going to fail just as bad as last time (or, >>> as I expected the first time around... some "standard" is going to >>> be produced that sucks; and that is either going to be ignored, or >>> adopted by a few large "players" who then all get major head aches >>> and problems that they can't fix; and in the end it will be the users >>> who suffer most from having a bad protocol of course :/. >> >> Carlo, Meadhbh is still around, thought she (note gender) has given up >> the editorship of the documents. =A0Your input is welcome -- encouraged >> -- though, of course, if you choose not to participate for whatever >> reason, that's your choice. =A0I think choosing not to participate >> because some particular person is also participating is a poor choice, >> but it's your choice to make. =A0I would like to see you reconsider >> that, if you're willing to do the work. >> >> What I do *not* want to see, and what we won't tolerate, are personal >> attacks on any participant here. =A0Do not engage in name-calling, do >> not question people's integrity, do not malign the companies they work >> for, and do not accuse people of malfeasance because they disagree >> with you. =A0If you present your ideas and others agree with what you >> say, those ideas will make it forward. =A0That's how we aim to work, >> here, and if this working group can continue and make progress, that's >> indeed how we'll work. >> >> So... will we make some progress on the intro document? =A0Can we get >> some real discussion on it, and a draft that shows some level of >> consensus within the nest few weeks? >> >> Barry, as chair >> _______________________________________________ >> 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From izzyalanis@gmail.com Sat Mar 26 11:56:11 2011 Return-Path: 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 9F5953A680A for ; Sat, 26 Mar 2011 11:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 5Ab6Xg4VZBwU for ; Sat, 26 Mar 2011 11:56:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 11A813A6817 for ; Sat, 26 Mar 2011 11:56:08 -0700 (PDT) Received: by qwg5 with SMTP id 5so1378665qwg.31 for ; Sat, 26 Mar 2011 11:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-type:message-id:content-transfer-encoding:cc:x-mailer:from :subject:date:to; bh=qSvJ5cYXOe8oDhB2PdbCrU6DVFb2FZ5mu2VZyGl3UmA=; b=p2weNzFjekOYpKpmlapJEVWiKe8PsuA7u4LYWAE6r4WqAbOubUpC9u85AAX5Onnb8F MUsO1qGJMLJmPVhIU9Bq225tOnjVa2EIiyKXnAgm8U5mfoU1MllbWvrLFOa9BkJ5J4z+ Xw6/whngpcPXMxJSUt6eC8Oq/cXvDPJavJNBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; b=dz4/nx4ppA/HGog/ac1RgVg4rANO7R2WvXJKTN6t6ud5rLWK4pnoqYg43FsGYr4OP2 BKBwbUwz9qK3Q51h4Oc/J4LCdcWgiirEmF8XNkMfiBwTReHFEHLdGN+77ArdVrTe/GFm bATXaI8du7QXadOq+ihMaHSSJNm0eCJIix+rk= Received: by 10.224.9.12 with SMTP id j12mr1746714qaj.61.1301165864591; Sat, 26 Mar 2011 11:57:44 -0700 (PDT) Received: from [192.168.1.104] (c-75-68-52-200.hsd1.nh.comcast.net [75.68.52.200]) by mx.google.com with ESMTPS id m3sm1550311qck.26.2011.03.26.11.57.42 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 11:57:43 -0700 (PDT) References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8C148) Content-Type: text/plain; charset=us-ascii Message-Id: <5308836B-763E-4813-95DE-6033786914D8@gmail.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8C148) From: Izzy Alanis Date: Sat, 26 Mar 2011 14:57:42 -0400 To: Meadhbh Hamrick Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 18:56:11 -0000 I certainly am confused about what you want LLSD to be. Many protocols need mechanisms for both describing structured data in a lang= uage/technology neutral way (via interface definition language) and a concre= te serialized form or forms -- primarily used for transfer, but also for sto= rage/retrieval, archival purposes, etc, etc, etc. Protobuffs doesn't say anything about transfer protocols (neither does LLSD)= , protobuffs doesn't say anything about language/technology stack requiremen= ts (neither does LLSD). > my experience with > large systems and protobufs is you have to make everything optional to > cover the use case of two systems running slightly different versions > of an interface. How was LLSD's extension mechanism different? LLSD and protobuff are not tha= t different except that LLSD allows for multiple serialization forms, which (= IMHO) adds confusion and complexity. For example, serializing LLSD over JSON means you need a specialized LLSD-JS= ON serializer/deserializer. Why? Because the serializer needs to follow the L= LSD imposed rules about default values, required data fields, etc. Explain t= hat to a programmer who thinks, "yay it's JSON, I know how to parse that!" W= ell, you can use that JSON parser, but you'll end up with incomplete data st= ructs. - Izzy On Mar 26, 2011, at 1:31 PM, Meadhbh Hamrick wrote: > fwiw.. i think this discussion indicates a little confusion over what LLSD= is. >=20 > LLSD is not a transfer syntax. it is an abstract type system and > interface description language that defines three transfer syntaxes. > ProtoBufs is not an abstract type system as it's type semantics are > not defined. The objective of LLSD was to allow us to describe > services independent of any particular technology. >=20 > sadly, that was never made abundantly clear in the docs. but in the > list discussion, many of us who had used LLSD mentioned several times > that we were focusing on LLSD serialized with JSON or XML over > HTTP(S), but there was no reason it couldn't be carried over XMPP or > ProtoBufs. it's just that no one seemed to think those use cases were > interesting enough to sit down with a text editor and whip up some > code. >=20 > so... even if you dump LLSD moving forward, i would encourage you to > not use ProtoBufs to define service interfaces. my experience with > large systems and protobufs is you have to make everything optional to > cover the use case of two systems running slightly different versions > of an interface. >=20 > that being said, producing a map from LLSD to ProtoBufs should be > pretty straight forward. >=20 > but that's just my 2 cents. > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >=20 >=20 >=20 > On Sat, Mar 26, 2011 at 8:54 AM, Izzy Alanis wrote:= >> +1 to: put aside the existing stuff >>=20 >> For the purposes of the Intro doc, I think it would be possible to >> table the decision between LLSD/LLIDL and something else (protobuf) >> for the abstract type system / interface descriptions *if* the doc was >> couched in terms of a VWRAP-IDL that we then specify/decide on in the >> following IDL/type system doc. >>=20 >> One thing we should make a decision on, and that I think is fuzzy in >> the draft-hamrick-vwrap-intro-01 doc, is whether the serializations >> are negotiated between services, or whether VWRAP mandates LLSD as the >> only approved serialization. >>=20 >> Sections 2.3.1: >> "Web-based applications may choose to use JSON or XML. >> Server-to-server interactions may use the VWRAP specific binary >> serialization scheme..." >>=20 >> Seems to conflict with (2.3.3): >> " VWRAP uses the LLSD abstract type system and the LLIDL interface >> description language to describe the structure and type semantics >> of elements in messages sent between systems. Because LLSD makes >> extensive use of variable width, clearly delineated data fields, >> services which consume protocol messages may identify and extract >> only those message elements they know how to handle." >>=20 >> I'd like to take this opportunity to point out that protobuff supports >> the same variable width, extensibility, default values, yada yada >> yada. >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> we could couch that in terms of only the IDL, and leave serialization >> of messages up to content negotiation between services involved. >>=20 >> On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii wrote= : >>> What we should focus on, is this I believe, are we going to keep LLSD (i= s it >>> good enought). Is it really needed or shall we start from scratch, with t= he >>> aim of using some new viewer / browser. >>>=20 >>> Opensim (open source virtual platform with alot of grids already) is usi= ng >>> LLSD, especially because the viewer LL made is using LLSD. >>>=20 >>> To be honest I keep saying since the beginning of these working groups (= the >>> various ones, ogpx, vwrap, mmox..) we should put aside the existing stuf= f, >>> work more with Opensim, since they are the key to this new journey that i= s >>> open virtual worlds, its good they have HyperGrid already which does som= e >>> amazing stuff! >>>=20 >>> What we need is a consensus, something we all agree on and go forward wi= th >>> the docs. >>>=20 >>> -----Message d'origine----- From: Barry Leiba >>> Sent: Saturday, March 26, 2011 10:40 AM >>> To: Carlo Wood >>> Cc: vwrap@ietf.org >>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>=20 >>> Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. >>> I'm glad to see some discussion going. Izzy is right when he says this:= >>>>=20 >>>> Of course this all may not matter unless somebody actually addresses >>>> the underlying issue: That the group needs to start producing documents= . >>>=20 >>> Indeed. We, the chairs, need to see real progress on the documents... >>> particularly the introduction document. >>>=20 >>> This discussion is a start, and, as I say, I'm pleased to see it, but >>> it has to turn into real document editing very soon. >>>=20 >>> I want to say one other thing: >>>=20 >>>> Oops, no I said 'we'... but count me out. I still see the same people >>>> around here and it's still going to fail just as bad as last time (or, >>>> as I expected the first time around... some "standard" is going to >>>> be produced that sucks; and that is either going to be ignored, or >>>> adopted by a few large "players" who then all get major head aches >>>> and problems that they can't fix; and in the end it will be the users >>>> who suffer most from having a bad protocol of course :/. >>>=20 >>> Carlo, Meadhbh is still around, thought she (note gender) has given up >>> the editorship of the documents. Your input is welcome -- encouraged >>> -- though, of course, if you choose not to participate for whatever >>> reason, that's your choice. I think choosing not to participate >>> because some particular person is also participating is a poor choice, >>> but it's your choice to make. I would like to see you reconsider >>> that, if you're willing to do the work. >>>=20 >>> What I do *not* want to see, and what we won't tolerate, are personal >>> attacks on any participant here. Do not engage in name-calling, do >>> not question people's integrity, do not malign the companies they work >>> for, and do not accuse people of malfeasance because they disagree >>> with you. If you present your ideas and others agree with what you >>> say, those ideas will make it forward. That's how we aim to work, >>> here, and if this working group can continue and make progress, that's >>> indeed how we'll work. >>>=20 >>> So... will we make some progress on the intro document? Can we get >>> some real discussion on it, and a draft that shows some level of >>> consensus within the nest few weeks? >>>=20 >>> Barry, as chair >>> _______________________________________________ >>> 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 >>>=20 >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >>=20 From mysticaldemina@xrgrid.com Sat Mar 26 12:25:13 2011 Return-Path: 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 F1DF23A6804 for ; Sat, 26 Mar 2011 12:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 BVAW1AqYVwDJ for ; Sat, 26 Mar 2011 12:25:11 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 328133A63D2 for ; Sat, 26 Mar 2011 12:25:11 -0700 (PDT) Received: from [173.49.11.101] (helo=TWEEDY64) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Q3Z8J-000393-5O for vwrap@ietf.org; Sat, 26 Mar 2011 15:26:47 -0400 From: To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com><20110326135320.GC29908@alinoe.com> In-Reply-To: Date: Sat, 26 Mar 2011 15:26:09 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acvrxu/VkArxiOPTQTylsHr+k9xv7AAJDvCw X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 X-ELNK-Trace: be22ee791caf5f441aa676d7e74259b793d4f437769de15075c368fb6e09a8b2f31e13ef02b12505350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.49.11.101 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 19:25:13 -0000 I wouldn't say OpenSim is the future. This still has to be proven. Even SL, even though has a fairly large customer base only fits a narrow set of use cases and this is why we don't see more advanced virtual world applications using it. If fact I think this is one of the main issues with this group. To justify its purpose they need to define the use case it is to be used for. I have trouble understanding the use case outside of SL. And since SL has not show any interest now I find it hard to understand the purpose of this group. M. -----Original Message----- From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of Patnad Babii Sent: Saturday, March 26, 2011 11:03 AM To: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group What we should focus on, is this I believe, are we going to keep LLSD (is it good enought). Is it really needed or shall we start from scratch, with the aim of using some new viewer / browser. Opensim (open source virtual platform with alot of grids already) is using LLSD, especially because the viewer LL made is using LLSD. To be honest I keep saying since the beginning of these working groups (the various ones, ogpx, vwrap, mmox..) we should put aside the existing stuff, work more with Opensim, since they are the key to this new journey that is open virtual worlds, its good they have HyperGrid already which does some amazing stuff! What we need is a consensus, something we all agree on and go forward with the docs. -----Message d'origine----- From: Barry Leiba Sent: Saturday, March 26, 2011 10:40 AM To: Carlo Wood Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. I'm glad to see some discussion going. Izzy is right when he says this: > Of course this all may not matter unless somebody actually addresses > the underlying issue: That the group needs to start producing documents. Indeed. We, the chairs, need to see real progress on the documents... particularly the introduction document. This discussion is a start, and, as I say, I'm pleased to see it, but it has to turn into real document editing very soon. I want to say one other thing: > Oops, no I said 'we'... but count me out. I still see the same people > around here and it's still going to fail just as bad as last time (or, > as I expected the first time around... some "standard" is going to > be produced that sucks; and that is either going to be ignored, or > adopted by a few large "players" who then all get major head aches > and problems that they can't fix; and in the end it will be the users > who suffer most from having a bad protocol of course :/. Carlo, Meadhbh is still around, thought she (note gender) has given up the editorship of the documents. Your input is welcome -- encouraged -- though, of course, if you choose not to participate for whatever reason, that's your choice. I think choosing not to participate because some particular person is also participating is a poor choice, but it's your choice to make. I would like to see you reconsider that, if you're willing to do the work. What I do *not* want to see, and what we won't tolerate, are personal attacks on any participant here. Do not engage in name-calling, do not question people's integrity, do not malign the companies they work for, and do not accuse people of malfeasance because they disagree with you. If you present your ideas and others agree with what you say, those ideas will make it forward. That's how we aim to work, here, and if this working group can continue and make progress, that's indeed how we'll work. So... will we make some progress on the intro document? Can we get some real discussion on it, and a draft that shows some level of consensus within the nest few weeks? Barry, as chair _______________________________________________ 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 From ohmeadhbh@gmail.com Sat Mar 26 12:34:35 2011 Return-Path: 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 DA6B93A682E for ; Sat, 26 Mar 2011 12:34:35 -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 T1hiUaIv2wAy for ; Sat, 26 Mar 2011 12:34:32 -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 778203A63D2 for ; Sat, 26 Mar 2011 12:34:32 -0700 (PDT) Received: by iye19 with SMTP id 19so1904635iye.31 for ; Sat, 26 Mar 2011 12:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dYpNDS346GFh7OcdYDfIB4lMI0Y71+j11jLOiGF8a08=; b=WU67u/2FQKci1Dsf9w1fpd4uT3w/ROcKoFQOVm78H9JrjCulOEaKd5PnRR8RcSIlrb azSN/j3IG9EtfvFUhabbD/0jXsSw1CceqGyU2RTpau55OMtEkvurgYwgY9vixUAePsmY ARH/iOitMPMpM1EMqao6a9GH0AvtJg4yS2VsI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rzIuZUFSoyswHLKxIutX3h1W5DLHX0f9Bw0zVmklVdZ2OM1DWYOWFPvlkSZGl4XFw1 S+iSPSR6GSiq1YCBwBzDY02aeSwCCnf8yudmdKh0wSyaQN/YmKZqFhcZAj7JhY5bWrz3 9/mOqf9gmiq2ztNp7k+koj8o+BjgLqRuLLvS0= Received: by 10.43.66.5 with SMTP id xo5mr3334784icb.71.1301168168168; Sat, 26 Mar 2011 12:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Sat, 26 Mar 2011 12:35:47 -0700 (PDT) In-Reply-To: <5308836B-763E-4813-95DE-6033786914D8@gmail.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <5308836B-763E-4813-95DE-6033786914D8@gmail.com> From: Meadhbh Hamrick Date: Sat, 26 Mar 2011 12:35:47 -0700 Message-ID: To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 19:34:36 -0000 actually protobufs says quite a bit about transfer syntax. as does LLSD. here's a link to an overview of ProtoBuf line encoding. if you read the document, the entire back half of the document describes serialization schemes used to concretize abstract data for transmission over the network. since we use JSON and XML for 2/3 of our wire format specification, we reference the ECMAscript and XML standards rather than replicate them in the LLSD drafts. LLSD and ProtoBufs ARE both transport agnostic, though the only defined interoperability profile for LLSD was transporting messages over HTTP. some people said they were interested in XMPP, but they never produced any documentation for it. LLSD defines multiple transfer syntaxes because there was a requirement that it work with existing XML and JSON tools. The binary format was something added to save space on disk and in packets, though honestly, transferring XML or JSON with gzip content encoding gets you to encoding sizes that are pretty close to binary encoding. and yes, if you use JSON, you have to deal with JSON's flaws. but guess what? if you use XML, you have to deal with XML's flaws. but at the end of the day, some people use XML and some people use JSON. we're not going to tell you which to use, because ultimately it's pretty insignificant compared to the semantics of messages that flow between services. but sure, if you're down with having an argument about why we should all use ProtocolBuffers, be my guest. I'll check in with you in a couple years and see how close you are to consensus. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Mar 26, 2011 at 11:57 AM, Izzy Alanis wrote: > I certainly am confused about what you want LLSD to be. > > Many protocols need mechanisms for both describing structured data in a l= anguage/technology neutral way (via interface definition language) and a co= ncrete serialized form or forms -- primarily used for transfer, but also fo= r storage/retrieval, archival purposes, etc, etc, etc. > > Protobuffs doesn't say anything about transfer protocols (neither does LL= SD), protobuffs doesn't say anything about language/technology stack requir= ements (neither does LLSD). > >> my experience with >> large systems and protobufs is you have to make everything optional to >> cover the use case of two systems running slightly different versions >> of an interface. > > How was LLSD's extension mechanism different? LLSD and protobuff are not = that different except that LLSD allows for multiple serialization forms, wh= ich (IMHO) adds confusion and complexity. > > For example, serializing LLSD over JSON means you need a specialized LLSD= -JSON serializer/deserializer. Why? Because the serializer needs to follow = the LLSD imposed rules about default values, required data fields, etc. Exp= lain that to a programmer who thinks, "yay it's JSON, I know how to parse t= hat!" Well, you can use that JSON parser, but you'll end up with incomplete= data structs. > > - Izzy > > On Mar 26, 2011, at 1:31 PM, Meadhbh Hamrick wrote: > >> fwiw.. i think this discussion indicates a little confusion over what LL= SD is. >> >> LLSD is not a transfer syntax. it is an abstract type system and >> interface description language that defines three transfer syntaxes. >> ProtoBufs is not an abstract type system as it's type semantics are >> not defined. The objective of LLSD was to allow us to describe >> services independent of any particular technology. >> >> sadly, that was never made abundantly clear in the docs. but in the >> list discussion, many of us who had used LLSD mentioned several times >> that we were focusing on LLSD serialized with JSON or XML over >> HTTP(S), but there was no reason it couldn't be carried over XMPP or >> ProtoBufs. it's just that no one seemed to think those use cases were >> interesting enough to sit down with a text editor and whip up some >> code. >> >> so... even if you dump LLSD moving forward, i would encourage you to >> not use ProtoBufs to define service interfaces. my experience with >> large systems and protobufs is you have to make everything optional to >> cover the use case of two systems running slightly different versions >> of an interface. >> >> that being said, producing a map from LLSD to ProtoBufs should be >> pretty straight forward. >> >> but that's just my 2 cents. >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Mar 26, 2011 at 8:54 AM, Izzy Alanis wrot= e: >>> +1 to: put aside the existing stuff >>> >>> For the purposes of the Intro doc, I think it would be possible to >>> table the decision between LLSD/LLIDL and something else (protobuf) >>> for the abstract type system / interface descriptions *if* the doc was >>> couched in terms of a VWRAP-IDL that we then specify/decide on in the >>> following IDL/type system doc. >>> >>> One thing we should make a decision on, and that I think is fuzzy in >>> the draft-hamrick-vwrap-intro-01 doc, is whether the serializations >>> are negotiated between services, or whether VWRAP mandates LLSD as the >>> only approved serialization. >>> >>> Sections 2.3.1: >>> =A0"Web-based applications may choose to use JSON or XML. >>> Server-to-server interactions may use the VWRAP specific binary >>> serialization scheme..." >>> >>> Seems to conflict with (2.3.3): >>> =A0" VWRAP uses the LLSD abstract type system and the LLIDL interface >>> =A0 =A0 =A0 description language to describe the structure and type sem= antics >>> =A0 =A0 =A0 of elements in messages sent between systems. =A0Because LL= SD makes >>> =A0 =A0 =A0 extensive use of variable width, clearly delineated data fi= elds, >>> =A0 =A0 =A0 services which consume protocol messages may identify and e= xtract >>> =A0 =A0 =A0 only those message elements they know how to handle." >>> >>> I'd like to take this opportunity to point out that protobuff supports >>> the same variable width, extensibility, default values, yada yada >>> yada. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> we could couch that in terms of only the IDL, and leave serialization >>> of messages up to content negotiation between services involved. >>> >>> On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii wro= te: >>>> What we should focus on, is this I believe, are we going to keep LLSD = (is it >>>> good enought). Is it really needed or shall we start from scratch, wit= h the >>>> aim of using some new viewer / browser. >>>> >>>> Opensim (open source virtual platform with alot of grids already) is u= sing >>>> LLSD, especially because the viewer LL made is using LLSD. >>>> >>>> To be honest I keep saying since the beginning of these working groups= (the >>>> various ones, ogpx, vwrap, mmox..) we should put aside the existing st= uff, >>>> work more with Opensim, since they are the key to this new journey tha= t is >>>> open virtual worlds, its good they have HyperGrid already which does s= ome >>>> amazing stuff! >>>> >>>> What we need is a consensus, something we all agree on and go forward = with >>>> the docs. >>>> >>>> -----Message d'origine----- From: Barry Leiba >>>> Sent: Saturday, March 26, 2011 10:40 AM >>>> To: Carlo Wood >>>> Cc: vwrap@ietf.org >>>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>> >>>> Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. >>>> I'm glad to see some discussion going. =A0Izzy is right when he says t= his: >>>>> >>>>> Of course this all may not matter unless somebody actually addresses >>>>> the underlying issue: That the group needs to start producing documen= ts. >>>> >>>> Indeed. =A0We, the chairs, need to see real progress on the documents.= .. >>>> particularly the introduction document. >>>> >>>> This discussion is a start, and, as I say, I'm pleased to see it, but >>>> it has to turn into real document editing very soon. >>>> >>>> I want to say one other thing: >>>> >>>>> Oops, no I said 'we'... but count me out. I still see the same people >>>>> around here and it's still going to fail just as bad as last time (or= , >>>>> as I expected the first time around... some "standard" is going to >>>>> be produced that sucks; and that is either going to be ignored, or >>>>> adopted by a few large "players" who then all get major head aches >>>>> and problems that they can't fix; and in the end it will be the users >>>>> who suffer most from having a bad protocol of course :/. >>>> >>>> Carlo, Meadhbh is still around, thought she (note gender) has given up >>>> the editorship of the documents. =A0Your input is welcome -- encourage= d >>>> -- though, of course, if you choose not to participate for whatever >>>> reason, that's your choice. =A0I think choosing not to participate >>>> because some particular person is also participating is a poor choice, >>>> but it's your choice to make. =A0I would like to see you reconsider >>>> that, if you're willing to do the work. >>>> >>>> What I do *not* want to see, and what we won't tolerate, are personal >>>> attacks on any participant here. =A0Do not engage in name-calling, do >>>> not question people's integrity, do not malign the companies they work >>>> for, and do not accuse people of malfeasance because they disagree >>>> with you. =A0If you present your ideas and others agree with what you >>>> say, those ideas will make it forward. =A0That's how we aim to work, >>>> here, and if this working group can continue and make progress, that's >>>> indeed how we'll work. >>>> >>>> So... will we make some progress on the intro document? =A0Can we get >>>> some real discussion on it, and a draft that shows some level of >>>> consensus within the nest few weeks? >>>> >>>> Barry, as chair >>>> _______________________________________________ >>>> 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 mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> > From vaughn.deluca@gmail.com Sat Mar 26 14:42:16 2011 Return-Path: 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 832033A697D for ; Sat, 26 Mar 2011 14:42:16 -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 ep1LfoNSB18I for ; Sat, 26 Mar 2011 14:42:14 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2CE2B3A697C for ; Sat, 26 Mar 2011 14:42:14 -0700 (PDT) Received: by ewy19 with SMTP id 19so927786ewy.31 for ; Sat, 26 Mar 2011 14:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1fMs8dtizQsumoC2QS3mHUmksq/wqWUskvbv/eUDguc=; b=xmEwdLLLIpgys+WY1a/OrK7aR03ib+mPtqX+ueBhVJgVvqMAMTkHuLzPO0xWekYi7Q q9O+3PAcV4g5TnhrKQ9RiNzB9IseGOtDcEWU0i/bTYn9VFwC8EMgASwMmCCkzbNne3D9 YEN2Kdt34bIOQzzPlgXQZmTDYfcxSuOxT+Eds= 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 :cc:content-type; b=ay3QS1X5zGEuFPRGqHIbX/5pZGZTQ60Ux8/0GAAXJZNHkRIO4coNyvaG2bS0W8qGiN P63XkfBdwOMYn5YCXzDPYA5BGLi0trk9/NpvQ4wyyLeGvxUXagFgLexuOmduIRXUSW6j obAqI/VfIrdyIet1XQBOWzE86qLXMGt/Jzy+Q= MIME-Version: 1.0 Received: by 10.213.96.14 with SMTP id f14mr1051274ebn.138.1301175829831; Sat, 26 Mar 2011 14:43:49 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sat, 26 Mar 2011 14:43:49 -0700 (PDT) In-Reply-To: <20110326135320.GC29908@alinoe.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Sat, 26 Mar 2011 22:43:49 +0100 Message-ID: From: Vaughn Deluca To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:42:16 -0000 Carlo writes: >What is wrong here is that I *AM* a major player (or could be): >I have a lot of time, a lot experience and a lot of analytic insight >and understanding of complex communication protocols. Come on Carlo, grow up. You do yourself a disservice by acting as a spoiled child. I fully agree with you that the off-list development was very demotivating, and at several occasions I have complained loudly about that. But when i wrote "major players" i was thinking in terms of input to the group, -of actual work done-, and not at all about company size. So please, act like the professional you are. If you drop the hurt tone, and take a constructive approach, I am very very sure you will be listend to, and become a major player in the sense that i meant it. >Sorry to be this blunt-- but I thought you wanted to know >(from everyone) why they backed out and stopped being responsive. First, yes you were indeed blunt and i think somewhat out of line as well, but i do not want to enter into that discussion here and now. Second No, i did *not* ask why people stopped responding, i asked who was still willing to do some real work here. The first and foremost problem we have is a lack of critical mass, and in particular input from people that have the needed technical background. And clearly you are one of those that we need badly. So please put whatever trouble you may have had with meadhbh behind you. She is no longer editor, and Linden Lab is not interested anymore in VWRAP. Things have changed, and I can see very little reason to stop you from participating here again, and that would be a real solid step towards reviving this group. It would be really nice if you would reconsider your position. --Vaughn On 3/26/11, Carlo Wood wrote: > On Sat, Mar 26, 2011 at 10:41:06AM +0100, Vaughn Deluca wrote: >> Right, we need to produce documents. Part of the reason we are stalled >> is that the current drafts were critisized, most notably by Morgaine, >> but no concrete steps were taken to follow up on the critisism. > > I respect Morgaine (although I don't always agree with her) for the > time she has put to keeping people aware of what was going on. > And if her efforts are the reason that the project stalled then YAY! > That was one hell of job. I didn't have the time to it myself, but > I think it's a step forwards. Anything but just one or two people > dominating the list, producing documents and causing anyone who oppose > (like me) to go silent, and then God Forbid - turning that into a standard. > >> So, i agree with Katherine her proposal (in another tread) and suggest >> we keep working within the current charter. What we could do is the >> absolute bare minimum of change to the drafts to keep us floating, and > > No... See, that's where you make a fatal mistake of taking a step > backwards. This is not about pushing SOME "standard" at all costs. > It's about designing a standard that is clearly technically the best, > so that everyone agrees with that. Imho, we need to start from scratch. > > Oops, no I said 'we'... but count me out. I still see the same people > around here and it's still going to fail just as bad as last time (or, > as I expected the first time around... some "standard" is going to > be produced that sucks; and that is either going to be ignored, or > adopted by a few large "players" who then all get major head aches > and problems that they can't fix; and in the end it will be the users > who suffer most from having a bad protocol of course :/. > >> start a campaign for new blood. This is such a cool project, i simply >> can't imagine we wont be able to attract some new people that can help >> to make it happen. >> >> -- Vaughn > From morgaine.dinova@googlemail.com Sat Mar 26 17:07:53 2011 Return-Path: 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 C88DB3A6984 for ; Sat, 26 Mar 2011 17:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 eFp7Pq9m8MCm for ; Sat, 26 Mar 2011 17:07:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 609C93A697E for ; Sat, 26 Mar 2011 17:07:51 -0700 (PDT) Received: by qwg5 with SMTP id 5so1465687qwg.31 for ; Sat, 26 Mar 2011 17:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Uuu5abJ/oDht94buAnOC9d23F8oPDsjWE8uCXLWEuuI=; b=m2WX4UGlM7IczjUNiWfBaX8yhiPF8dc8mM8JYe7j6WSinUGmHl4TmVYKiHPAHCp9S1 oYZ7UJma5SP3I9f0/8zGNAGTSHZgIRsDkLhu3Z/9diLdMnlYq1VM7hPVyFKBdiYbeXN6 JOv1drE9GwarQBjcGirCgf4BNWF4itx7MMrkI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ml0h2uSGJ3b0vdWyFgy/bqYrsZdbVdDP3wC4l4cgHwPoh8df7UGfYJ89PYYm/jveuj nhHMdBqf3pE00fUREPaIaLr6HGdvlYfVhOgQESUKYPeUQ2a2OaWZeAxAJzvHXxfQca2D BE4LiMlV1EsgFBBl0XbIZDO3NpnuenyP3KqE4= MIME-Version: 1.0 Received: by 10.229.62.8 with SMTP id v8mr2082882qch.33.1301184567464; Sat, 26 Mar 2011 17:09:27 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 26 Mar 2011 17:09:27 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sun, 27 Mar 2011 00:09:27 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180db2ee51ef049f6ba350 Cc: Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 00:07:53 -0000 --90e6ba180db2ee51ef049f6ba350 Content-Type: text/plain; charset=ISO-8859-1 I'm glad to see some renewed participation here! Perhaps the threat of death sharpens the mind. ;-) Since there seems to be some fresh thinking in the air, I am going to add two short points to the discussion. The first is a matter of procedure, and the second is related to our technical direction: - Notwithstanding that the IETF places certain duties on Barry and others to ensure that there is visible progress in the form of documents, I must say that "documents at all costs" is not a particularly good way of achieving technical progress. It's the "documents at all costs" push that gave us several documents previously, only one of which turned out to be usable for interoperation between VWs. Documents churned out before there is agreement on goals and direction are a hindrance to the process, not an indicator of progress, and they waste everyone's time. Progress is certainly not a matter of just putting pen to paper, as has been suggested. Far from it. First we must agree as a group on how a given protocol is going to meet our goals, and drafts then present that formally with hard technical details added. Done the other way around just results in much angst and wasted effort, as happened here. - Given the almost unanimous agreement that crystallized around Crista's thread of a few months ago which could be paraphrased as "The VWRAP documents do nothing for interop between virtual worlds", I would like to suggest that instead of continuing to beat the dead horse of OGP that we still have on our hands, why don't we focus on delivering something that is actually *usable* by compatible groups like Opensim and realXtend and iED? There is a nugget of gold at the heart of the VWRAP concept which can provide exactly that: the idea of *shared asset services*, and a protocol for accessing them. There is a huge amount of activity in our sector of the virtual worlds community. There is also no end of interest in interoperation, but the trouble seems to be that each group is rather narrowly focused on their own particular code base. Where I think a group such as ours can contribute is by providing a lightweight protocol which is easily used by all, without the previous baggage. Simple problems demand simple solutions, and while a massively scalable shared asset service is not exactly simple, it is nevertheless a lot simpler than the much larger task that we had set ourselves previously. Perhaps that would be a good place to start, afresh. Morgaine. ===================================== On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba wrote: > Reminder: If anyone's done anything related to what's below, please > post here and get some discussion going. There's still about two and > a half weeks to get something ready. > > Barry, as chair > > On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba > wrote: > > On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba > wrote: > >>> As for timescales, we already started work on a new Intro in October > and > >>> November, as I described in my first email in this thread. It was > being > >>> done informally, not as an official draft but as input to a totally new > >>> draft. It was not being done as a revision because the previous Intro > >>> simply did not meet key requirements for many contributors, as was > clear > >>> from the group's very intense discussions of September. > >> > >> Can you see if you can get it into reasonable shape to introduce > >> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? That > >> would give people something concrete to work from. > > > > I haven't seen any activity on this, so let me repeat this with a > deadline: > > > > The chairs ask the proponents to please get a new intro document into > > reasonable (not final) shape to introduce publicly, and to submit it > > as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" > > by 10 April (the significance of which will be left for the reader to > > research, should s/he care to). There may, of course, be any > > (reasonable) number of authors listed on the draft, and any one may be > > the name chosen to live in the draft name. > > > > If we're not able to do that, I think we need to seriously question > > whether there's enough real energy to continue. > > > > Barry, as chair > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --90e6ba180db2ee51ef049f6ba350 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm glad to see some renewed participation here!=A0 Perhaps the threat = of death sharpens the mind. ;-)

Since there seems to be some fresh t= hinking in the air, I am going to add two short points to the discussion.= =A0 The first is a matter of procedure, and the second is related to our te= chnical direction:

  • Notwithstanding that the IETF places certain duties on Barry an= d others to ensure that there is visible progress in the form of documents,= I must say that "documents at all costs" is not a particularly g= ood way of achieving technical progress.=A0 It's the "documents at= all costs" push that gave us several documents previously, only one o= f which turned out to be usable for interoperation between VWs.=A0 Document= s churned out before there is agreement on goals and direction are a hindra= nce to the process, not an indicator of progress, and they waste everyone&#= 39;s time.=A0 Progress is certainly not a matter of just putting pen to pap= er, as has been suggested.=A0 Far from it.=A0 First we must agree as a grou= p on how a given protocol is going to meet our goals, and drafts then prese= nt that formally with hard technical details added.=A0 Done the other way a= round just results in much angst and wasted effort, as happened here.
  • Given the almost unanimous agreement that crystallized ar= ound Crista's thread of a few months ago which could be paraphrased as = "The VWRAP documents do nothing for interop between virtual worlds&quo= t;, I would like to suggest that instead of continuing to beat the dead hor= se of OGP that we still have on our hands, why don't we focus on delive= ring something that is actually usable by compatible groups like Ope= nsim and realXtend and iED?=A0 There is a nugget of gold at the heart of th= e VWRAP concept which can provide exactly that:=A0 the idea of shared as= set services, and a protocol for accessing them.

There is a huge amount of activity in our sector of the virtu= al worlds community.=A0 There is also no end of interest in interoperation,= but the trouble seems to be that each group is rather narrowly focused on = their own particular code base.=A0 Where I think a group such as ours can c= ontribute is by providing a lightweight protocol which is easily used by al= l, without the previous baggage.=A0 Simple problems demand simple solutions= , and while a massively scalable shared asset service is not exactly simple= , it is nevertheless a lot simpler than the much larger task that we had se= t ourselves previously.

Perhaps that would be a good place to start, afresh.


Morgain= e.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba= <barryleiba@computer.org> wrote:
Reminder: If anyone's done anything related to what's below, please=
post here and get some discussion going. =A0There's still about two and=
a half weeks to get something ready.

Barry, as chair

On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <barryleiba@computer.org> wrote: > On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <barryleiba@computer.org> wro= te:
>>> As for timescales, we already started work on a new Intro in O= ctober and
>>> November, as I described in my first email in this thread.=A0 = It was being
>>> done informally, not as an official draft but as input to a to= tally new
>>> draft.=A0 It was not being done as a revision because the prev= ious Intro
>>> simply did not meet key requirements for many contributors, as= was clear
>>> from the group's very intense discussions of September. >>
>> Can you see if you can get it into reasonable shape to introduce >> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? = =A0That
>> would give people something concrete to work from.
>
> I haven't seen any activity on this, so let me repeat this with a = deadline:
>
> The chairs ask the proponents to please get a new intro document into<= br> > reasonable (not final) shape to introduce publicly, and to submit it > as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-= 00"
> by 10 April (the significance of which will be left for the reader to<= br> > research, should s/he care to). =A0There may, of course, be any
> (reasonable) number of authors listed on the draft, and any one may be=
> the name chosen to live in the draft name.
>
> If we're not able to do that, I think we need to seriously questio= n
> whether there's enough real energy to continue.
>
> Barry, as chair
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--90e6ba180db2ee51ef049f6ba350-- From izzyalanis@gmail.com Sat Mar 26 17:27:33 2011 Return-Path: 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 794CE28C0E9 for ; Sat, 26 Mar 2011 17:27:33 -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 Lv2BPz3dab5q for ; Sat, 26 Mar 2011 17:27:31 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BCEF028C0E8 for ; Sat, 26 Mar 2011 17:27:30 -0700 (PDT) Received: by fxm15 with SMTP id 15so2107289fxm.31 for ; Sat, 26 Mar 2011 17:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QDsY0ZvukPtDacy5T++htuW5BzDf6dzuwYJwuSM+Dls=; b=IHh+fKtwAYp0nRxISfv+H4KSRsMHiWKx9KY6E8SSrIUJqI1mFUYaIBKgLvHEzQgF+y dZRjruwAhPpI7/n/QTlrgTzy44uDcyIakKotvaIN3Yq0ZfNM6oyxH2HRrray17OwYdS8 idSjxzJDxEYKFnuYNulqhfKzDZdohqg3HddDE= 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 :cc:content-type:content-transfer-encoding; b=aerZNkeXmSZqA1jlCg1NEJJEoSKtJGTqyMi8YZ6bosCAxpIefosNjqt2njT0Wn1eGn cFq1V2uLg3nWci1w6/U7H5HKICOXfuyE2Th6XPqEl04JifGjcXiRn/Cz0LsruK/1HlN9 NxVvPEmC9AOFQ21InQhrVq+5HgfWcws3DTt2M= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr2720794fan.105.1301185746486; Sat, 26 Mar 2011 17:29:06 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sat, 26 Mar 2011 17:29:06 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 26 Mar 2011 20:29:06 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 00:27:33 -0000 Are you suggesting a re-charter around shared services only? Or that we shift the deliverables to push that to the forefront? (In which case, we still really do need an intro doc and to address the messaging semantics) I'm not quite convinced that the charter is unsalvageable. I think the last rev of the intro has a lot of good things in it too -- lots I would like to see changed, but good stuff too. On Sat, Mar 26, 2011 at 8:09 PM, Morgaine wrote: > I'm glad to see some renewed participation here!=A0 Perhaps the threat of > death sharpens the mind. ;-) > > Since there seems to be some fresh thinking in the air, I am going to add > two short points to the discussion.=A0 The first is a matter of procedure= , and > the second is related to our technical direction: > > Notwithstanding that the IETF places certain duties on Barry and others t= o > ensure that there is visible progress in the form of documents, I must sa= y > that "documents at all costs" is not a particularly good way of achieving > technical progress.=A0 It's the "documents at all costs" push that gave u= s > several documents previously, only one of which turned out to be usable f= or > interoperation between VWs.=A0 Documents churned out before there is agre= ement > on goals and direction are a hindrance to the process, not an indicator o= f > progress, and they waste everyone's time.=A0 Progress is certainly not a > matter of just putting pen to paper, as has been suggested.=A0 Far from i= t. > First we must agree as a group on how a given protocol is going to meet o= ur > goals, and drafts then present that formally with hard technical details > added.=A0 Done the other way around just results in much angst and wasted > effort, as happened here. > > Given the almost unanimous agreement that crystallized around Crista's > thread of a few months ago which could be paraphrased as "The VWRAP > documents do nothing for interop between virtual worlds", I would like to > suggest that instead of continuing to beat the dead horse of OGP that we > still have on our hands, why don't we focus on delivering something that = is > actually usable by compatible groups like Opensim and realXtend and iED? > There is a nugget of gold at the heart of the VWRAP concept which can > provide exactly that:=A0 the idea of shared asset services, and a protoco= l for > accessing them. > > There is a huge amount of activity in our sector of the virtual worlds > community.=A0 There is also no end of interest in interoperation, but the > trouble seems to be that each group is rather narrowly focused on their o= wn > particular code base.=A0 Where I think a group such as ours can contribut= e is > by providing a lightweight protocol which is easily used by all, without = the > previous baggage.=A0 Simple problems demand simple solutions, and while a > massively scalable shared asset service is not exactly simple, it is > nevertheless a lot simpler than the much larger task that we had set > ourselves previously. > > Perhaps that would be a good place to start, afresh. > > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba > wrote: >> >> Reminder: If anyone's done anything related to what's below, please >> post here and get some discussion going. =A0There's still about two and >> a half weeks to get something ready. >> >> Barry, as chair >> >> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >> wrote: >> > On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >> > wrote: >> >>> As for timescales, we already started work on a new Intro in October >> >>> and >> >>> November, as I described in my first email in this thread.=A0 It was >> >>> being >> >>> done informally, not as an official draft but as input to a totally >> >>> new >> >>> draft.=A0 It was not being done as a revision because the previous I= ntro >> >>> simply did not meet key requirements for many contributors, as was >> >>> clear >> >>> from the group's very intense discussions of September. >> >> >> >> Can you see if you can get it into reasonable shape to introduce >> >> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =A0Th= at >> >> would give people something concrete to work from. >> > >> > I haven't seen any activity on this, so let me repeat this with a >> > deadline: >> > >> > The chairs ask the proponents to please get a new intro document into >> > reasonable (not final) shape to introduce publicly, and to submit it >> > as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >> > by 10 April (the significance of which will be left for the reader to >> > research, should s/he care to). =A0There may, of course, be any >> > (reasonable) number of authors listed on the draft, and any one may be >> > the name chosen to live in the draft name. >> > >> > If we're not able to do that, I think we need to seriously question >> > whether there's enough real energy to continue. >> > >> > Barry, as chair >> > >> _______________________________________________ >> 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 > > From izzyalanis@gmail.com Sat Mar 26 17:37:56 2011 Return-Path: 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 37BD73A680D for ; Sat, 26 Mar 2011 17:37:56 -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 W2Be05zqtaOV for ; Sat, 26 Mar 2011 17:37:54 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9F2F23A6833 for ; Sat, 26 Mar 2011 17:37:53 -0700 (PDT) Received: by fxm15 with SMTP id 15so2109687fxm.31 for ; Sat, 26 Mar 2011 17:39:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=VgxRY/PPXTHUC75NBgYatU9jX8qDacAniuezeW9Kxus=; b=HaQNdMh3jzjcmA3J9s7N4t3Dz3rBUDMP2YtjOeruJnOQR5g9SNDsAvVNS9gv3SxTd+ hiQ2s1BX4BWEKgXZlrvzZVFctk1YvzjdzSgFC4N/NX7YetK2ek4VZJGz2hn9F4P0GOzk WQowq73Ko3DqedbP9NNpQ+uXR3fUTBIEeIWZU= 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 :cc:content-type:content-transfer-encoding; b=j1iSIgZP4fZzaY9CVg9yrBQxnJRtbbi3gbp6o4lLC37uYYKaQr69BMjulNVzsYUUJW Iz6PeFy3yN7KlsLcy+FaLoKR7Qhlx84sC/RcNS3+y2I3qMhqVL8vSe+TG48FyA/XvD7t rjMWR0HeMuVECdI+obYZ1y41KBNMqdb4jObrY= MIME-Version: 1.0 Received: by 10.223.158.9 with SMTP id d9mr1505832fax.124.1301186369208; Sat, 26 Mar 2011 17:39:29 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sat, 26 Mar 2011 17:39:29 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 26 Mar 2011 20:39:29 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 00:37:56 -0000 Meant to say "shared *asset* services" there... On Sat, Mar 26, 2011 at 8:29 PM, Izzy Alanis wrote: > Are you suggesting a re-charter around shared services only? > Or that we shift the deliverables to push that to the forefront? (In > which case, we still really do need an intro doc and to address the > messaging semantics) > > I'm not quite convinced that the charter is unsalvageable. I think the > last rev of the intro has a lot of good things in it too -- lots I > would like to see changed, but good stuff too. > > > > On Sat, Mar 26, 2011 at 8:09 PM, Morgaine > wrote: >> I'm glad to see some renewed participation here!=A0 Perhaps the threat o= f >> death sharpens the mind. ;-) >> >> Since there seems to be some fresh thinking in the air, I am going to ad= d >> two short points to the discussion.=A0 The first is a matter of procedur= e, and >> the second is related to our technical direction: >> >> Notwithstanding that the IETF places certain duties on Barry and others = to >> ensure that there is visible progress in the form of documents, I must s= ay >> that "documents at all costs" is not a particularly good way of achievin= g >> technical progress.=A0 It's the "documents at all costs" push that gave = us >> several documents previously, only one of which turned out to be usable = for >> interoperation between VWs.=A0 Documents churned out before there is agr= eement >> on goals and direction are a hindrance to the process, not an indicator = of >> progress, and they waste everyone's time.=A0 Progress is certainly not a >> matter of just putting pen to paper, as has been suggested.=A0 Far from = it. >> First we must agree as a group on how a given protocol is going to meet = our >> goals, and drafts then present that formally with hard technical details >> added.=A0 Done the other way around just results in much angst and waste= d >> effort, as happened here. >> >> Given the almost unanimous agreement that crystallized around Crista's >> thread of a few months ago which could be paraphrased as "The VWRAP >> documents do nothing for interop between virtual worlds", I would like t= o >> suggest that instead of continuing to beat the dead horse of OGP that we >> still have on our hands, why don't we focus on delivering something that= is >> actually usable by compatible groups like Opensim and realXtend and iED? >> There is a nugget of gold at the heart of the VWRAP concept which can >> provide exactly that:=A0 the idea of shared asset services, and a protoc= ol for >> accessing them. >> >> There is a huge amount of activity in our sector of the virtual worlds >> community.=A0 There is also no end of interest in interoperation, but th= e >> trouble seems to be that each group is rather narrowly focused on their = own >> particular code base.=A0 Where I think a group such as ours can contribu= te is >> by providing a lightweight protocol which is easily used by all, without= the >> previous baggage.=A0 Simple problems demand simple solutions, and while = a >> massively scalable shared asset service is not exactly simple, it is >> nevertheless a lot simpler than the much larger task that we had set >> ourselves previously. >> >> Perhaps that would be a good place to start, afresh. >> >> >> Morgaine. >> >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba >> wrote: >>> >>> Reminder: If anyone's done anything related to what's below, please >>> post here and get some discussion going. =A0There's still about two and >>> a half weeks to get something ready. >>> >>> Barry, as chair >>> >>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >>> wrote: >>> > On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >>> > wrote: >>> >>> As for timescales, we already started work on a new Intro in Octobe= r >>> >>> and >>> >>> November, as I described in my first email in this thread.=A0 It wa= s >>> >>> being >>> >>> done informally, not as an official draft but as input to a totally >>> >>> new >>> >>> draft.=A0 It was not being done as a revision because the previous = Intro >>> >>> simply did not meet key requirements for many contributors, as was >>> >>> clear >>> >>> from the group's very intense discussions of September. >>> >> >>> >> Can you see if you can get it into reasonable shape to introduce >>> >> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =A0T= hat >>> >> would give people something concrete to work from. >>> > >>> > I haven't seen any activity on this, so let me repeat this with a >>> > deadline: >>> > >>> > The chairs ask the proponents to please get a new intro document into >>> > reasonable (not final) shape to introduce publicly, and to submit it >>> > as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >>> > by 10 April (the significance of which will be left for the reader to >>> > research, should s/he care to). =A0There may, of course, be any >>> > (reasonable) number of authors listed on the draft, and any one may b= e >>> > the name chosen to live in the draft name. >>> > >>> > If we're not able to do that, I think we need to seriously question >>> > whether there's enough real energy to continue. >>> > >>> > Barry, as chair >>> > >>> _______________________________________________ >>> 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 >> >> > From izzyalanis@gmail.com Sat Mar 26 18:04:53 2011 Return-Path: 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 424C528C0E4 for ; Sat, 26 Mar 2011 18:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, 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 3wUCLIlbVU-f for ; Sat, 26 Mar 2011 18:04:51 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 12C8E3A6988 for ; Sat, 26 Mar 2011 18:04:50 -0700 (PDT) Received: by fxm15 with SMTP id 15so2116144fxm.31 for ; Sat, 26 Mar 2011 18:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=90Wuw3h/TFsqoGJwsKiAOwk2FE9MQzLqZiE0/pF/n8s=; b=V+pm6H/oaBKm75Nd/sNWTG0ik9h8A8qK3348eEF5GyUsuZmk5eEFSZZ9sghHMNdAFX 967CvHijtMzkbIXNvHEjgow8aI9C7vlhmB2RdzqTzT9RohqXHU8/lXXnWzzt1k0cosKk OOoyLGIa7LVmXiFsnLV0bFCTEaf4nwtUfiEcI= 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 :cc:content-type:content-transfer-encoding; b=cyqnK9QdM89dJA/jCuWKnVlR8+Lasf2d9vmTYl+q0NabVME15BZW/yKq05UfhiYyY9 N08bJEmA6RkLBCWcrOIx8GbW1HPWQZdZ3MiwDrZke/Vdgcwi1vVB8edgMQXQd9c61erm 9Nfeto6FCsSl70cS67NTX99F9DjdgsEL6neZw= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr2742608fan.105.1301187986631; Sat, 26 Mar 2011 18:06:26 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sat, 26 Mar 2011 18:06:26 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <5308836B-763E-4813-95DE-6033786914D8@gmail.com> Date: Sat, 26 Mar 2011 21:06:26 -0400 Message-ID: From: Izzy Alanis To: Meadhbh Hamrick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 01:04:53 -0000 Lol, I'd never argue that one tool fits all needs for all purposes. But this one is a good fit for a LLSD replacement, and it has a good, active user community, and a corporation with lots of money to back it up. I don't feel like I'm hearing good arguments against protobuf though. > LLSD defines multiple transfer syntaxes because there was a > requirement that it work with existing XML and JSON tools. LLSD imposes extra deserialization rules upon those schemes, so I don't just need an XML parser, I need an LLSD+XML parser. I don't need a JSON parser, I need a LLSD+JSON parser/library. And if I need yet another library anyway, why did it matter that the underlying transfer re-used a XML or JSON syntax? Here are some of my own qualms about protobuf: * What if I want to embed a message inside a container that only supports XML? Such as inside a SOAP or XMPP message? * But there isn't an RFC to really define protocol buffers! * But if it's not specific to VWRAP, what if the protobuf people decide to add things in there that make it... too complicated, inappropriate, too weird... (what happens if we give up control?) I understand you have a vested interest in LLSD and I apologize for my initial brashness calling it 'crap'. But the group has enough problems ahead of it. Trying to invent/standardize a new multi-purpose "Abstract Type System" isn't something the group really needs to do. On Sat, Mar 26, 2011 at 3:35 PM, Meadhbh Hamrick wrot= e: > actually protobufs says quite a bit about transfer syntax. as does LLSD. > > here's a link to an overview of ProtoBuf line encoding. > > if you read the document, the entire back half of the document > describes serialization schemes used to concretize abstract data for > transmission over the network. since we use JSON and XML for 2/3 of > our wire format specification, we reference the ECMAscript and XML > standards rather than replicate them in the LLSD drafts. > > LLSD and ProtoBufs ARE both transport agnostic, though the only > defined interoperability profile for LLSD was transporting messages > over HTTP. some people said they were interested in XMPP, but they > never produced any documentation for it. > > LLSD defines multiple transfer syntaxes because there was a > requirement that it work with existing XML and JSON tools. The binary > format was something added to save space on disk and in packets, > though honestly, transferring XML or JSON with gzip content encoding > gets you to encoding sizes that are pretty close to binary encoding. > > and yes, if you use JSON, you have to deal with JSON's flaws. but > guess what? if you use XML, you have to deal with XML's flaws. but at > the end of the day, some people use XML and some people use JSON. > we're not going to tell you which to use, because ultimately it's > pretty insignificant compared to the semantics of messages that flow > between services. > > but sure, if you're down with having an argument about why we should > all use ProtocolBuffers, be my guest. I'll check in with you in a > couple years and see how close you are to consensus. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Mar 26, 2011 at 11:57 AM, Izzy Alanis wrot= e: >> I certainly am confused about what you want LLSD to be. >> >> Many protocols need mechanisms for both describing structured data in a = language/technology neutral way (via interface definition language) and a c= oncrete serialized form or forms -- primarily used for transfer, but also f= or storage/retrieval, archival purposes, etc, etc, etc. >> >> Protobuffs doesn't say anything about transfer protocols (neither does L= LSD), protobuffs doesn't say anything about language/technology stack requi= rements (neither does LLSD). >> >>> my experience with >>> large systems and protobufs is you have to make everything optional to >>> cover the use case of two systems running slightly different versions >>> of an interface. >> >> How was LLSD's extension mechanism different? LLSD and protobuff are not= that different except that LLSD allows for multiple serialization forms, w= hich (IMHO) adds confusion and complexity. >> >> For example, serializing LLSD over JSON means you need a specialized LLS= D-JSON serializer/deserializer. Why? Because the serializer needs to follow= the LLSD imposed rules about default values, required data fields, etc. Ex= plain that to a programmer who thinks, "yay it's JSON, I know how to parse = that!" Well, you can use that JSON parser, but you'll end up with incomplet= e data structs. >> >> - Izzy >> >> On Mar 26, 2011, at 1:31 PM, Meadhbh Hamrick wrote= : >> >>> fwiw.. i think this discussion indicates a little confusion over what L= LSD is. >>> >>> LLSD is not a transfer syntax. it is an abstract type system and >>> interface description language that defines three transfer syntaxes. >>> ProtoBufs is not an abstract type system as it's type semantics are >>> not defined. The objective of LLSD was to allow us to describe >>> services independent of any particular technology. >>> >>> sadly, that was never made abundantly clear in the docs. but in the >>> list discussion, many of us who had used LLSD mentioned several times >>> that we were focusing on LLSD serialized with JSON or XML over >>> HTTP(S), but there was no reason it couldn't be carried over XMPP or >>> ProtoBufs. it's just that no one seemed to think those use cases were >>> interesting enough to sit down with a text editor and whip up some >>> code. >>> >>> so... even if you dump LLSD moving forward, i would encourage you to >>> not use ProtoBufs to define service interfaces. my experience with >>> large systems and protobufs is you have to make everything optional to >>> cover the use case of two systems running slightly different versions >>> of an interface. >>> >>> that being said, producing a map from LLSD to ProtoBufs should be >>> pretty straight forward. >>> >>> but that's just my 2 cents. >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Sat, Mar 26, 2011 at 8:54 AM, Izzy Alanis wro= te: >>>> +1 to: put aside the existing stuff >>>> >>>> For the purposes of the Intro doc, I think it would be possible to >>>> table the decision between LLSD/LLIDL and something else (protobuf) >>>> for the abstract type system / interface descriptions *if* the doc was >>>> couched in terms of a VWRAP-IDL that we then specify/decide on in the >>>> following IDL/type system doc. >>>> >>>> One thing we should make a decision on, and that I think is fuzzy in >>>> the draft-hamrick-vwrap-intro-01 doc, is whether the serializations >>>> are negotiated between services, or whether VWRAP mandates LLSD as the >>>> only approved serialization. >>>> >>>> Sections 2.3.1: >>>> =A0"Web-based applications may choose to use JSON or XML. >>>> Server-to-server interactions may use the VWRAP specific binary >>>> serialization scheme..." >>>> >>>> Seems to conflict with (2.3.3): >>>> =A0" VWRAP uses the LLSD abstract type system and the LLIDL interface >>>> =A0 =A0 =A0 description language to describe the structure and type se= mantics >>>> =A0 =A0 =A0 of elements in messages sent between systems. =A0Because L= LSD makes >>>> =A0 =A0 =A0 extensive use of variable width, clearly delineated data f= ields, >>>> =A0 =A0 =A0 services which consume protocol messages may identify and = extract >>>> =A0 =A0 =A0 only those message elements they know how to handle." >>>> >>>> I'd like to take this opportunity to point out that protobuff supports >>>> the same variable width, extensibility, default values, yada yada >>>> yada. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> we could couch that in terms of only the IDL, and leave serialization >>>> of messages up to content negotiation between services involved. >>>> >>>> On Sat, Mar 26, 2011 at 11:03 AM, Patnad Babii wr= ote: >>>>> What we should focus on, is this I believe, are we going to keep LLSD= (is it >>>>> good enought). Is it really needed or shall we start from scratch, wi= th the >>>>> aim of using some new viewer / browser. >>>>> >>>>> Opensim (open source virtual platform with alot of grids already) is = using >>>>> LLSD, especially because the viewer LL made is using LLSD. >>>>> >>>>> To be honest I keep saying since the beginning of these working group= s (the >>>>> various ones, ogpx, vwrap, mmox..) we should put aside the existing s= tuff, >>>>> work more with Opensim, since they are the key to this new journey th= at is >>>>> open virtual worlds, its good they have HyperGrid already which does = some >>>>> amazing stuff! >>>>> >>>>> What we need is a consensus, something we all agree on and go forward= with >>>>> the docs. >>>>> >>>>> -----Message d'origine----- From: Barry Leiba >>>>> Sent: Saturday, March 26, 2011 10:40 AM >>>>> To: Carlo Wood >>>>> Cc: vwrap@ietf.org >>>>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>>> >>>>> Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. >>>>> I'm glad to see some discussion going. =A0Izzy is right when he says = this: >>>>>> >>>>>> Of course this all may not matter unless somebody actually addresses >>>>>> the underlying issue: That the group needs to start producing docume= nts. >>>>> >>>>> Indeed. =A0We, the chairs, need to see real progress on the documents= ... >>>>> particularly the introduction document. >>>>> >>>>> This discussion is a start, and, as I say, I'm pleased to see it, but >>>>> it has to turn into real document editing very soon. >>>>> >>>>> I want to say one other thing: >>>>> >>>>>> Oops, no I said 'we'... but count me out. I still see the same peopl= e >>>>>> around here and it's still going to fail just as bad as last time (o= r, >>>>>> as I expected the first time around... some "standard" is going to >>>>>> be produced that sucks; and that is either going to be ignored, or >>>>>> adopted by a few large "players" who then all get major head aches >>>>>> and problems that they can't fix; and in the end it will be the user= s >>>>>> who suffer most from having a bad protocol of course :/. >>>>> >>>>> Carlo, Meadhbh is still around, thought she (note gender) has given u= p >>>>> the editorship of the documents. =A0Your input is welcome -- encourag= ed >>>>> -- though, of course, if you choose not to participate for whatever >>>>> reason, that's your choice. =A0I think choosing not to participate >>>>> because some particular person is also participating is a poor choice= , >>>>> but it's your choice to make. =A0I would like to see you reconsider >>>>> that, if you're willing to do the work. >>>>> >>>>> What I do *not* want to see, and what we won't tolerate, are personal >>>>> attacks on any participant here. =A0Do not engage in name-calling, do >>>>> not question people's integrity, do not malign the companies they wor= k >>>>> for, and do not accuse people of malfeasance because they disagree >>>>> with you. =A0If you present your ideas and others agree with what you >>>>> say, those ideas will make it forward. =A0That's how we aim to work, >>>>> here, and if this working group can continue and make progress, that'= s >>>>> indeed how we'll work. >>>>> >>>>> So... will we make some progress on the intro document? =A0Can we get >>>>> some real discussion on it, and a draft that shows some level of >>>>> consensus within the nest few weeks? >>>>> >>>>> Barry, as chair >>>>> _______________________________________________ >>>>> 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 mailing list >>>> vwrap@ietf.org >>>> https://www.ietf.org/mailman/listinfo/vwrap >>>> >> > From dzonatas@gmail.com Sat Mar 26 18:40:42 2011 Return-Path: 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 BC94F28C0E4 for ; Sat, 26 Mar 2011 18:40:42 -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 w0c3NBZ+Oizk for ; Sat, 26 Mar 2011 18:40:41 -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 31E3B28C0CE for ; Sat, 26 Mar 2011 18:40:41 -0700 (PDT) Received: by iye19 with SMTP id 19so2093599iye.31 for ; Sat, 26 Mar 2011 18:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vuVAYIacWmI2IjBh48HfhExwl+RU5FuQjpB52tIFbZA=; b=uF8oA1aJ7mHZ9KW2e3RoStmbR+D2wp1kx9SdWDJgDTN0mb6ULVL4lz/fDj7MV4WE6i K4PNnE9Jh3fDlqgEWz3RfKUP8vIfibQ7xqyDVDtcD83+xZJsvINHDpHXttAXLs6c3aE9 Rh+ELqljE+AXYXduYfLBtMx+d7ScJCjtdVKIw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=KOxkCSIz8cXFDfPH7aE4JvXJyMgcLUdErJ/Q88qxFBXbfKVy6U3rkBt708rJ/zDsZZ WbE4CXsiC5E0Tz8o/uItfQ0+6PFwz1d2Vq2ptfRmmL7mRnCWxTlUVds0vm64Rf6S9Asx vZBewAXY4n0W1Hm4UFlII17TjL/Fx23qvM8rQ= Received: by 10.43.60.210 with SMTP id wt18mr3906640icb.25.1301190137509; Sat, 26 Mar 2011 18:42:17 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i20sm1807901iby.48.2011.03.26.18.42.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Mar 2011 18:42:16 -0700 (PDT) Message-ID: <4D8E95D6.3080102@gmail.com> Date: Sat, 26 Mar 2011 18:41:42 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Izzy Alanis References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 01:40:42 -0000 If there was focus only on the login (agent domain) and inventory services, then I think we will get some where. Yes, we know there are issues with inventory that are already in the simulator side, so this is the suggestion to build apart from those issues. Start from there. Izzy Alanis wrote: > Are you suggesting a re-charter around shared services only? > Or that we shift the deliverables to push that to the forefront? (In > which case, we still really do need an intro doc and to address the > messaging semantics) > > I'm not quite convinced that the charter is unsalvageable. I think the > last rev of the intro has a lot of good things in it too -- lots I > would like to see changed, but good stuff too. > > > > On Sat, Mar 26, 2011 at 8:09 PM, Morgaine > wrote: > >> I'm glad to see some renewed participation here!� Perhaps the threat of >> death sharpens the mind. ;-) >> >> Since there seems to be some fresh thinking in the air, I am going to add >> two short points to the discussion.� The first is a matter of procedure, and >> the second is related to our technical direction: >> >> Notwithstanding that the IETF places certain duties on Barry and others to >> ensure that there is visible progress in the form of documents, I must say >> that "documents at all costs" is not a particularly good way of achieving >> technical progress.� It's the "documents at all costs" push that gave us >> several documents previously, only one of which turned out to be usable for >> interoperation between VWs.� Documents churned out before there is agreement >> on goals and direction are a hindrance to the process, not an indicator of >> progress, and they waste everyone's time.� Progress is certainly not a >> matter of just putting pen to paper, as has been suggested.� Far from it. >> First we must agree as a group on how a given protocol is going to meet our >> goals, and drafts then present that formally with hard technical details >> added.� Done the other way around just results in much angst and wasted >> effort, as happened here. >> >> Given the almost unanimous agreement that crystallized around Crista's >> thread of a few months ago which could be paraphrased as "The VWRAP >> documents do nothing for interop between virtual worlds", I would like to >> suggest that instead of continuing to beat the dead horse of OGP that we >> still have on our hands, why don't we focus on delivering something that is >> actually usable by compatible groups like Opensim and realXtend and iED? >> There is a nugget of gold at the heart of the VWRAP concept which can >> provide exactly that:� the idea of shared asset services, and a protocol for >> accessing them. >> >> There is a huge amount of activity in our sector of the virtual worlds >> community.� There is also no end of interest in interoperation, but the >> trouble seems to be that each group is rather narrowly focused on their own >> particular code base.� Where I think a group such as ours can contribute is >> by providing a lightweight protocol which is easily used by all, without the >> previous baggage.� Simple problems demand simple solutions, and while a >> massively scalable shared asset service is not exactly simple, it is >> nevertheless a lot simpler than the much larger task that we had set >> ourselves previously. >> >> Perhaps that would be a good place to start, afresh. >> >> >> Morgaine. >> >> >> >> >> >> >> ===================================== >> >> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba >> wrote: >> >>> Reminder: If anyone's done anything related to what's below, please >>> post here and get some discussion going. �There's still about two and >>> a half weeks to get something ready. >>> >>> Barry, as chair >>> >>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >>> wrote: >>> >>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >>>> wrote: >>>> >>>>>> As for timescales, we already started work on a new Intro in October >>>>>> and >>>>>> November, as I described in my first email in this thread.� It was >>>>>> being >>>>>> done informally, not as an official draft but as input to a totally >>>>>> new >>>>>> draft.� It was not being done as a revision because the previous Intro >>>>>> simply did not meet key requirements for many contributors, as was >>>>>> clear >>>>>> from the group's very intense discussions of September. >>>>>> >>>>> Can you see if you can get it into reasonable shape to introduce >>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? �That >>>>> would give people something concrete to work from. >>>>> >>>> I haven't seen any activity on this, so let me repeat this with a >>>> deadline: >>>> >>>> The chairs ask the proponents to please get a new intro document into >>>> reasonable (not final) shape to introduce publicly, and to submit it >>>> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >>>> by 10 April (the significance of which will be left for the reader to >>>> research, should s/he care to). �There may, of course, be any >>>> (reasonable) number of authors listed on the draft, and any one may be >>>> the name chosen to live in the draft name. >>>> >>>> If we're not able to do that, I think we need to seriously question >>>> whether there's enough real energy to continue. >>>> >>>> Barry, as chair >>>> >>>> >>> _______________________________________________ >>> 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Sat Mar 26 19:10:17 2011 Return-Path: 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 0E7B228C0ED for ; Sat, 26 Mar 2011 19:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 IynWus3Ku3Gz for ; Sat, 26 Mar 2011 19:10:15 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id BDCD228C0CE for ; Sat, 26 Mar 2011 19:10:14 -0700 (PDT) Received: by qyk29 with SMTP id 29so426918qyk.10 for ; Sat, 26 Mar 2011 19:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Qw88X3XtkAfciXbq6MKgubVQMp8pdQfT8NtUMu5Wq0s=; b=Vh2xNMH2s23qNVc5C1kcgseknepzBJ0buXo4mzNlP4iU9X16GheRXZcBCynWEASGto 3EM6nJhnH9tfWiFTEf4N9k8NV5roTWYeo0dsmLwEZ9apf/w1/yuYm6V0i7Q9IME7IuRa gnK0hQAtMMv11uJUIBwfVKoyNfuE8iGUKaiSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=xxhMvWMezum6MqDmVoGvSWJVC6c05WUAmFNPKtO0SZe7HhQU3FoKGL2ChL3cuXq3AW zc7CTSQdEYT6MhYaLEFhoLhFidGkRNFrSHLvJ7BQLruvQDDFyCPpcImCF80VN1nntIH+ dQ+rbmqyVuBDDJmSFFNxXj/CSHBPDFhQOA9tk= MIME-Version: 1.0 Received: by 10.229.62.8 with SMTP id v8mr2132611qch.33.1301191910877; Sat, 26 Mar 2011 19:11:50 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sat, 26 Mar 2011 19:11:50 -0700 (PDT) In-Reply-To: <4D8E95D6.3080102@gmail.com> References: <4D8E95D6.3080102@gmail.com> Date: Sun, 27 Mar 2011 03:11:50 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180db2a1e962049f6d59b6 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 02:10:17 -0000 --90e6ba180db2a1e962049f6d59b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, server-side inventories are one of the worst design decisions of th= e existing implementations. They give us no end of problems, such as the impossibility of high-speed client-side searching and regular lag issues, not to mention being non-portable because each world provider would implement them differently. They're also non-scalable because they're centralized, and non supportive o= f VW tourism because a given world provider would control what can be put int= o them, instead of the traveling user being in control. Inventories need to be client-side (I refer to the trees of asset metadata, not the asset data, in case that's not clear), with an auto sync of deltas to a configured asset service for resilience/backup. That way only those people who do not look after their local inventory resources will suffer client-server transport lag to recreate them, and the full power of client-side CPUs and client-side databases and scripting can be deployed to make inventories a real powerhouse. All we really need are shared asset services that are independent of the world providers. That alone is enough to virtually ensure portability, interoperability, and scalability, as long as a lightweight protocol can be found that is also extensible to support tomorrow's worlds. Making a standard to support only what we're doing today isn't particularly interesting. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol wrote: > If there was focus only on the login (agent domain) and inventory service= s, > then I think we will get some where. > > Yes, we know there are issues with inventory that are already in the > simulator side, so this is the suggestion to build apart from those issue= s. > Start from there. > > > > Izzy Alanis wrote: > >> Are you suggesting a re-charter around shared services only? >> Or that we shift the deliverables to push that to the forefront? (In >> which case, we still really do need an intro doc and to address the >> messaging semantics) >> >> I'm not quite convinced that the charter is unsalvageable. I think the >> last rev of the intro has a lot of good things in it too -- lots I >> would like to see changed, but good stuff too. >> >> >> >> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine >> wrote: >> >> >>> I'm glad to see some renewed participation here!=EF=BF=BD Perhaps the t= hreat of >>> death sharpens the mind. ;-) >>> >>> Since there seems to be some fresh thinking in the air, I am going to a= dd >>> two short points to the discussion.=EF=BF=BD The first is a matter of p= rocedure, >>> and >>> the second is related to our technical direction: >>> >>> Notwithstanding that the IETF places certain duties on Barry and others >>> to >>> ensure that there is visible progress in the form of documents, I must >>> say >>> that "documents at all costs" is not a particularly good way of achievi= ng >>> technical progress.=EF=BF=BD It's the "documents at all costs" push tha= t gave us >>> several documents previously, only one of which turned out to be usable >>> for >>> interoperation between VWs.=EF=BF=BD Documents churned out before there= is >>> agreement >>> on goals and direction are a hindrance to the process, not an indicator >>> of >>> progress, and they waste everyone's time.=EF=BF=BD Progress is certainl= y not a >>> matter of just putting pen to paper, as has been suggested.=EF=BF=BD Fa= r from it. >>> First we must agree as a group on how a given protocol is going to meet >>> our >>> goals, and drafts then present that formally with hard technical detail= s >>> added.=EF=BF=BD Done the other way around just results in much angst an= d wasted >>> effort, as happened here. >>> >>> Given the almost unanimous agreement that crystallized around Crista's >>> thread of a few months ago which could be paraphrased as "The VWRAP >>> documents do nothing for interop between virtual worlds", I would like = to >>> suggest that instead of continuing to beat the dead horse of OGP that w= e >>> still have on our hands, why don't we focus on delivering something tha= t >>> is >>> actually usable by compatible groups like Opensim and realXtend and iED= ? >>> There is a nugget of gold at the heart of the VWRAP concept which can >>> provide exactly that:=EF=BF=BD the idea of shared asset services, and a= protocol >>> for >>> accessing them. >>> >>> There is a huge amount of activity in our sector of the virtual worlds >>> community.=EF=BF=BD There is also no end of interest in interoperation,= but the >>> trouble seems to be that each group is rather narrowly focused on their >>> own >>> particular code base.=EF=BF=BD Where I think a group such as ours can c= ontribute >>> is >>> by providing a lightweight protocol which is easily used by all, withou= t >>> the >>> previous baggage.=EF=BF=BD Simple problems demand simple solutions, and= while a >>> massively scalable shared asset service is not exactly simple, it is >>> nevertheless a lot simpler than the much larger task that we had set >>> ourselves previously. >>> >>> Perhaps that would be a good place to start, afresh. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba >>> wrote: >>> >>> >>>> Reminder: If anyone's done anything related to what's below, please >>>> post here and get some discussion going. =EF=BF=BDThere's still about = two and >>>> a half weeks to get something ready. >>>> >>>> Barry, as chair >>>> >>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >>>> wrote: >>>> >>>> >>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >>>>> wrote: >>>>> >>>>> >>>>>> As for timescales, we already started work on a new Intro in October >>>>>>> and >>>>>>> November, as I described in my first email in this thread.=EF=BF=BD= It was >>>>>>> being >>>>>>> done informally, not as an official draft but as input to a totally >>>>>>> new >>>>>>> draft.=EF=BF=BD It was not being done as a revision because the pre= vious >>>>>>> Intro >>>>>>> simply did not meet key requirements for many contributors, as was >>>>>>> clear >>>>>>> from the group's very intense discussions of September. >>>>>>> >>>>>>> >>>>>> Can you see if you can get it into reasonable shape to introduce >>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =EF= =BF=BDThat >>>>>> would give people something concrete to work from. >>>>>> >>>>>> >>>>> I haven't seen any activity on this, so let me repeat this with a >>>>> deadline: >>>>> >>>>> The chairs ask the proponents to please get a new intro document into >>>>> reasonable (not final) shape to introduce publicly, and to submit it >>>>> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >>>>> by 10 April (the significance of which will be left for the reader to >>>>> research, should s/he care to). =EF=BF=BDThere may, of course, be any >>>>> (reasonable) number of authors listed on the draft, and any one may b= e >>>>> the name chosen to live in the draft name. >>>>> >>>>> If we're not able to do that, I think we need to seriously question >>>>> whether there's enough real energy to continue. >>>>> >>>>> Barry, as chair >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --90e6ba180db2a1e962049f6d59b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Indeed, server-side inventories are one of the worst design decisions of th= e existing implementations.

They give us no end of problems, such as= the impossibility of high-speed client-side searching and regular lag issu= es, not to mention being non-portable because each world provider would imp= lement them differently.=C2=A0 They're also non-scalable because they&#= 39;re centralized, and non supportive of VW tourism because a given world p= rovider would control what can be put into them, instead of the traveling u= ser being in control.

Inventories need to be client-side (I refer to the trees of asset metad= ata, not the asset data, in case that's not clear), with an auto sync o= f deltas to a configured asset service for resilience/backup.=C2=A0 That wa= y only those people who do not look after their local inventory resources w= ill suffer client-server transport lag to recreate them, and the full power= of client-side CPUs and client-side databases and scripting can be deploye= d to make inventories a real powerhouse.

All we really need are shared asset services that are independent of th= e world providers.=C2=A0 That alone is enough to virtually ensure portabili= ty, interoperability, and scalability, as long as a lightweight protocol ca= n be found that is also extensible to support tomorrow's worlds.=C2=A0 = Making a standard to support only what we're doing today isn't part= icularly interesting.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas S= ol <dzonatas@gma= il.com> wrote:
If there was focu= s only on the login (agent domain) and inventory services, then I think we = will get some where.

Yes, we know there are issues with inventory that are already in the simula= tor side, so this is the suggestion to build apart from those issues. Start= from there.



Izzy Alanis wrote:
Are you suggesting a re-charter around shared services only?
Or that we shift the deliverables to push that to the forefront? (In
which case, we still really do need an intro doc and to address the
messaging semantics)

I'm not quite convinced that the charter is unsalvageable. I think the<= br> last rev of the intro has a lot of good things in it too -- lots I
would like to see changed, but good stuff too.



On Sat, Mar 26, 2011 at 8:09 PM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
=C2=A0
I'm glad to see some renewed participation here!=EF=BF=BD Perhaps the t= hreat of
death sharpens the mind. ;-)

Since there seems to be some fresh thinking in the air, I am going to add two short points to the discussion.=EF=BF=BD The first is a matter of proce= dure, and
the second is related to our technical direction:

Notwithstanding that the IETF places certain duties on Barry and others to<= br> ensure that there is visible progress in the form of documents, I must say<= br> that "documents at all costs" is not a particularly good way of a= chieving
technical progress.=EF=BF=BD It's the "documents at all costs"= ; push that gave us
several documents previously, only one of which turned out to be usable for=
interoperation between VWs.=EF=BF=BD Documents churned out before there is = agreement
on goals and direction are a hindrance to the process, not an indicator of<= br> progress, and they waste everyone's time.=EF=BF=BD Progress is certainl= y not a
matter of just putting pen to paper, as has been suggested.=EF=BF=BD Far fr= om it.
First we must agree as a group on how a given protocol is going to meet our=
goals, and drafts then present that formally with hard technical details added.=EF=BF=BD Done the other way around just results in much angst and wa= sted
effort, as happened here.

Given the almost unanimous agreement that crystallized around Crista's<= br> thread of a few months ago which could be paraphrased as "The VWRAP documents do nothing for interop between virtual worlds", I would like= to
suggest that instead of continuing to beat the dead horse of OGP that we still have on our hands, why don't we focus on delivering something tha= t is
actually usable by compatible groups like Opensim and realXtend and iED? There is a nugget of gold at the heart of the VWRAP concept which can
provide exactly that:=EF=BF=BD the idea of shared asset services, and a pro= tocol for
accessing them.

There is a huge amount of activity in our sector of the virtual worlds
community.=EF=BF=BD There is also no end of interest in interoperation, but= the
trouble seems to be that each group is rather narrowly focused on their own=
particular code base.=EF=BF=BD Where I think a group such as ours can contr= ibute is
by providing a lightweight protocol which is easily used by all, without th= e
previous baggage.=EF=BF=BD Simple problems demand simple solutions, and whi= le a
massively scalable shared asset service is not exactly simple, it is
nevertheless a lot simpler than the much larger task that we had set
ourselves previously.

Perhaps that would be a good place to start, afresh.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba <barryleiba@computer.org>
wrote:
=C2=A0 =C2=A0
Reminder: If anyone's done anything related to what's below, please=
post here and get some discussion going. =EF=BF=BDThere's still about t= wo and
a half weeks to get something ready.

Barry, as chair

On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <barryleiba@computer.org>
wrote:
=C2=A0 =C2=A0 =C2=A0
On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <barryleiba@computer.org>
wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0
As for timescales, we already started work on a new Intro in October
and
November, as I described in my first email in this thread.=EF=BF=BD It was<= br> being
done informally, not as an official draft but as input to a totally
new
draft.=EF=BF=BD It was not being done as a revision because the previous In= tro
simply did not meet key requirements for many contributors, as was
clear
from the group's very intense discussions of September.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
Can you see if you can get it into reasonable shape to introduce
publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =EF=BF=BDTh= at
would give people something concrete to work from.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
I haven't seen any activity on this, so let me repeat this with a
deadline:

The chairs ask the proponents to please get a new intro document into
reasonable (not final) shape to introduce publicly, and to submit it
as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00&qu= ot;
by 10 April (the significance of which will be left for the reader to
research, should s/he care to). =EF=BF=BDThere may, of course, be any
(reasonable) number of authors listed on the draft, and any one may be
the name chosen to live in the draft name.

If we're not able to do that, I think we need to seriously question
whether there's enough real energy to continue.

Barry, as chair

=C2=A0 =C2=A0 =C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap
=C2=A0 =C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


=C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

=C2=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--90e6ba180db2a1e962049f6d59b6-- From carlo@alinoe.com Sun Mar 27 06:17:17 2011 Return-Path: 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 E8FF328C14D for ; Sun, 27 Mar 2011 06:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 bHtbUEFFqmJQ for ; Sun, 27 Mar 2011 06:17:14 -0700 (PDT) Received: from fep19.mx.upcmail.net (fep19.mx.upcmail.net [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 8764A3A67E3 for ; Sun, 27 Mar 2011 06:17:12 -0700 (PDT) Received: from edge02.upcmail.net ([192.168.13.237]) by viefep19-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110327131847.ECYS14354.viefep19-int.chello.at@edge02.upcmail.net>; Sun, 27 Mar 2011 15:18:47 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upcmail.net with edge id QDJj1g01g0FlQed02DJklW; Sun, 27 Mar 2011 15:18:47 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q3prf-0004Kc-Fh; Sun, 27 Mar 2011 15:18:43 +0200 Date: Sun, 27 Mar 2011 15:18:43 +0200 From: Carlo Wood To: Vaughn Deluca Message-ID: <20110327131843.GA15165@alinoe.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=Nww7yNiXF4C1XGF+VcigPkOcTpD8wJaI1KQuZlH5eEk= c=1 sm=0 a=XYJHFtupD_QA:10 a=I88v0MqpzI0A:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=dKdm_e4O5-6pqlAFR1MA:9 a=aUq_V9RlMDNtwSZR3dkA:7 a=UY8ZIzFfNKdW2VOCqxypaDBTbKkA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=KYhvDgmwFmovhZO9:21 a=A-1nkRnCL80GHPor:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 13:17:18 -0000 On Sat, Mar 26, 2011 at 10:43:49PM +0100, Vaughn Deluca wrote: > problem we have is a lack of critical mass, and in particular input > from people that have the needed technical background. And clearly > you are one of those that we need badly. The way I'd like to move forward is anything but producing documents fast however; and that seems to be the requirement. If you want input from me regarding the survival of this group; I'd create a wiki that everyone who requests it can edit. The first and most important part of that wiki would be a glossary with every word that is frequently used in the discussions. That list of words should be complete rather quickly, then people can add their definitions to it. If two people have different definitions then those definitions should be signed; Once, for a particular word, everyone has added the definitions and/or remarks to the wiki (all on one page per word), we can start a discussion on this list on how to reformulize and change the definition of that word. Some might have to change their semantics, but in the end the goal would be that every word has one defintion, used and understood by everyone -- and clearly documented on the wiki, with discussion history as usual. If a discussion gets completely stuck on semantics, then people can just sign (put their name under) the definition the want and we'd just count the signatures and pick one. After all, it's just semantics and has nothing to do with what the protocol REALLY will do. Only then, we can take the next step; for which I'd also use the wiki. Also, as I wrote in old posts before... I am still CONVINCED that we can impossibly create a protocol that will address everything that will be needed in the future. All we can do is create something that is a good starting point and FOCUS on flexibility: create a protocol that can evolve. In order to do that, we need (further completely protocol neutral) protocol negotiation for every p2p link that is created in the process, which allows such evolution. The use of XML as basis for a protocol would mean the following: 1) It takes overhead, so it's not possible to use it for highbandwidth usage (ie video, or file transfers). But it could do at out-of-band control channel. 2) If it's pure XML than we won't have to worry about the implementation of serializing/deserializing as much, although that only really has it's advantages when we will need VWRAP to work for implementations in multiple programming languages before it gets accepted widely. As far as I can see, we will need C# and C++, and most likely C for religious reasons. 3) The ONLY benefit that XML has (on top of existing serialization libraries) is that it is extensible: You can add new parameters without confusing old code that doesn't expect it. Point 3, however, is just a weak attempt to be flexible. Imho, it is by far not flexible enough. We'd still need a well defined way for the evolving protocol negotiation, and once that is in place, we won't really need this feature of XML anymore. Thus, provided we add "evolving protocol negotiation", we should probably choose the serialization/deserialization method based on grounds that I can't judge at this point in the design. So for the near future: - Glossary and agreement on definitions of used jargon. - Abstract agreement on the use of an evolving protocol. - Definition of all possible p2p connection for which serialization is necessary. - Choice of what serialization mechanism is used where. - Abstract discussion (and agreement) of the use of Abelian operators for distributed states and identity authorities (see another old post from me). If we don't do that before anything else, we'd just shoot ourself in the foot. - etc This is no doubt the work of years, and won't lead to any document any time soon. -- Carlo Wood From toni@playsign.net Sat Mar 26 14:29:48 2011 Return-Path: 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 46A6E28C0DF for ; Sat, 26 Mar 2011 14:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_38=0.6] 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 lhQZZkQ9RIho for ; Sat, 26 Mar 2011 14:29:46 -0700 (PDT) Received: from dionysos.netplaza.fi (mail.utanet.fi [80.75.96.37]) by core3.amsl.com (Postfix) with ESMTP id 6F9743A6978 for ; Sat, 26 Mar 2011 14:29:44 -0700 (PDT) Received: from [192.168.0.106] (85-23-6-12.bb.dnainternet.fi [85.23.6.12]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.utanet.fi (Postfix) with ESMTP id 17439160184 for ; Sat, 26 Mar 2011 23:31:19 +0200 (EET) From: Toni Alatalo To: vwrap@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Sat, 26 Mar 2011 23:31:17 +0200 Message-ID: <1301175077.17122.617.camel@pulkka> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 27 Mar 2011 06:50:26 -0700 Subject: [vwrap] realXtend is interested in implementing, and human friendly URNs X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 21:58:53 -0000 Hi, I'm sorry for not participating here earlier. Just a quick note to say that we are interested in implementing good VW standards in the realXtend project -- the long term goal of the project is standardization, like the frontpage says right at start: "realXtend speeds up the development of the global standardized 3D internet of virtual worlds". Our strategy for it has been to implement quickly what we need, so haven't had much time for talks (the Finnish style :) But using existing standards such as HTTP, ECMAScript (Javascript), XMPP, COLLADA etc., via existing open source libs (qt, telepathy, openassetimport, ..) So if there are people here who can work on specs etc., we're happy to work both on prototyping and adopting the already existing implementations, which are already in production use, to use the standards. We can also give commit rights for developers from anywhere. Our very basics are put together now, the Tundra SDK is close to being frozen for 1.0, so can now take a breath a bit and look into standards and interop more. The requirements from our part are somewhat clear, 'cause the implementation and demos feature the basics of what we need. So far we've done very little regarding recent VWRAP output, but it's still a beginning: this handles vwrap calmj launch docs in the internal web viewer in Naali which can be used as the login UI / startup screen, https://github.com/realXtend/naali/blob/tundra/bin/pymodules/login/webui.py .. the plan is to use that against the simiangrid integration on the Tundra server side, which is at https://github.com/realXtend/naali/blob/tundra/bin/pymodules/simiangrid/auth.py (currently only works for simple username+password auth against simiangrid) One reason why we haven't participated earlier in VWRAP is that our focus has been on the scene functionality and application APIs. The equivalent of the DOM in the html land basically. IIRC it was John Hurliman who said on IRC last autumn or so that it's still out of scope for VWRAP, that you perhaps get to it in some years? For authentication and such we are happy to use existing things like openid/oath/something if they are good, and I trust this group to tell what works :) One reason why I started work on the simiangrid integration was to get OpenID auth back to our new Tundra platform -- the Opensimulator based Taiga had it since the beginning 'cause we implemented it to Cable Beach (the old version of simiangrid, and a standards effort that John merged to VWRAP). For scene / application functionality we are proposing the entity-component model, which is implemented in Naali/Tundra and also for partial functionality in the ModRex module for Opensimulator. Opensimulator would also want it for core, but it's not there yet. For more info, there's a draft article submitted for a magazine, currently under review: https://github.com/realXtend/doc/blob/master/arch_article/simple.pdf?raw=true (also a html view is available, but github fails to show the images there: https://github.com/realXtend/doc/blob/master/arch_article/simple.rst . Any comments about the article are very welcome btw! Google protobufs, or something like that, is fine for messaging. We are currently using the knet library for networking -- it is application independent, not VW specific, just a basic udp lib like enet, but it can run over tcp as well. Has a message description system similar to protobufs, but the serialization is independent of the transport so allows using protobufs or any other serialization too. There is two reasons for using knet currently: a) it performed better than enet regarding flow control in our tests b) it is written by the guy (Jukka Jylänki) who integrated it to Naali/Tundra, and the job had to be done really quickly (in a month or so last autumn). The lib does predate reX and wasn't originally made for VWs so is not a worst case of NIH :) Code is at https://bitbucket.org/clb/knet/ and docs (good! better than enet or almost any similar udp lib?) at http://clb.demon.fi/knet/ Finally a bit about URNs, as that is the reason what drove me to look into standards now. I'd like to implement URN asset references, as a simple way to put objects in scenes without needing to worry about locations and to support both offline & online use etc. This is my current draft: xxx:std:cube.mesh #a standard 1,1,1 cube that everyone agrees on xxx:std:teapot.mesh #come on, we could have this at least?-) xxx:rex:white_tailed_deer.mesh #currently in http://www.realxtend.org/world/lvm/White_Tailed_Deer/ .. but is not really tied to this world. is currently reX's best shot at making a white tailed deer, not necessarily what everyone agrees for standard. The namespace idea is similar to the existing: urn:ietf:rfc:2648 I wanted to make a new little demo where can walk around as the deer, in a different setting than the scene in that 'lvm' (Chesapeake bay, actually) project. Could just use http refs, but would not like to break how our little demo scenes work also offline. Eventually plan to use content based addressing for the actual data fetching, like magnet / something bittorrent style, which I saw had been discussed here too extensively. But on top of that, I'd want named refs to give two things: 1) nice human usable names 2) mutability The idea is that if that named asset is updated, the refs should pick up the new version. I think this is a bit similar to how inventory works in SL (am not sure, haven't used inventories much, we don't basically use them at all in reX anymore .. for Tundra there isn't even an implementation, and it would be an application level thing / a script anyway). The question is: what should 'xxx' be?-) My current idea is name:std:cube.mesh but 'name' feels stupid as a URN scheme, 'cause every URN is a name :o .. urn:file:std:mesh.cube might kind of make sense, 'cause it is a filename in the end, but that seems bad 'cause file: is also a URL type of course. urn:filename? I don't think this should be VW specific. ~Toni BTW: I've no idea whether it's better to keep this work here, or restart somehow, but I do hope that some sort of standards and interops efforts continue. Am still mostly interested in the 3d scene stuff, for example I'm fairly certain that we can have JS level interoperability in e.g. Naali, OpenWonderland and Sirikata so that api-wise simple things like camera animation scripts can work in all. For example a decent 3rd person camera implementation basically only needs raycasting or some other way to get occlusion info from the scene, and means to move and rotate the camera. But then the camera movement logic code itself can be very complex. From vaughn.deluca@gmail.com Sun Mar 27 07:35:43 2011 Return-Path: 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 5FDD83A67D6 for ; Sun, 27 Mar 2011 07:35:43 -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 JoH1QszqbaTA for ; Sun, 27 Mar 2011 07:35:41 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4AF233A6863 for ; Sun, 27 Mar 2011 07:35:41 -0700 (PDT) Received: by ewy19 with SMTP id 19so1064352ewy.31 for ; Sun, 27 Mar 2011 07:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3UUZMZ2pqjbXfhbGycEJsE817iedQ0lpHVLvBs79pFs=; b=oMMHLdk7ToJU78k8FtEyr/ozto3Optkb7niIUocZKvlLcBiaIsx2zckjZmBhg0EQz1 imPI3cfEsq/16vdv2GgsmrKHG2Tx6Og6D3gaU9J6VCEDWO/F1Wvj0XLHfdo5KV42/rh4 sHddPXZ2mBMcKhzPdKWYUXxorgKlimAcsfkJ4= 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 :cc:content-type:content-transfer-encoding; b=fDFk/0ZuYRvwtSqTULTfLZLimFlHrn893MFX1rqoYUK+soSprNQhXZ/6r8gOAtmPyP LNphNcnBJKGKWxZZTLYK5FexTTKhl7nQyfGGHdd1maA4Rf9mBRqoH1UeoJIAZRS+VJZ6 FQ8fhojp0bRgXw3dwq4YF1F9JD2H0/LHcyTzs= MIME-Version: 1.0 Received: by 10.213.8.143 with SMTP id h15mr63272ebh.138.1301236635900; Sun, 27 Mar 2011 07:37:15 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sun, 27 Mar 2011 07:37:15 -0700 (PDT) In-Reply-To: References: <4D8E95D6.3080102@gmail.com> Date: Sun, 27 Mar 2011 16:37:15 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 14:35:43 -0000 Morgaine, All very well, but you did not answer Izzy's question about rechartering. I agree with Izzy that it is by no means clear that the current charter is unsalvageable. For instance, your post below you write: >All we really need are shared asset services that are independent of the w= orld providers. I my view this is square within the current charter were it says: "Within a VWRAP virtual environment, services may be deployed by multiple organizations having varying policies and trust domains." I have always read that as meaning that an inventory could be *anywhere* and owned by *anybody*, and that surely covers my own client side inventory as well (possibly implemented as a personal asset service running on my own machine?) The decision to have server side inventory is clearly the choice of that servers operator, and it is my chose use that inventory if that suits me. If client side inventory is superior that will become clear by users preferring to use it. I fail to see how our current approach is an obstacle on this path. Can you point out what part of the charter needs to be changed, or better make a proposal for that change so we have something concrete to work from? I strongly feel we need to build some consensus in this group, and to do so we need to be crystal clear about our aims. We should start front be very top. You had a first attempt at restructuring the intro document, but we need to address the charter first. My view is that it is not yet needed to change that, and if you feel different this is the time to say so. -- Vaughn On 3/27/11, Morgaine wrote: > Indeed, server-side inventories are one of the worst design decisions of = the > existing implementations. > > They give us no end of problems, such as the impossibility of high-speed > client-side searching and regular lag issues, not to mention being > non-portable because each world provider would implement them differently= . > They're also non-scalable because they're centralized, and non supportive= of > VW tourism because a given world provider would control what can be put i= nto > them, instead of the traveling user being in control. > > Inventories need to be client-side (I refer to the trees of asset metadat= a, > not the asset data, in case that's not clear), with an auto sync of delta= s > to a configured asset service for resilience/backup. That way only those > people who do not look after their local inventory resources will suffer > client-server transport lag to recreate them, and the full power of > client-side CPUs and client-side databases and scripting can be deployed = to > make inventories a real powerhouse. > > All we really need are shared asset services that are independent of the > world providers. That alone is enough to virtually ensure portability, > interoperability, and scalability, as long as a lightweight protocol can = be > found that is also extensible to support tomorrow's worlds. Making a > standard to support only what we're doing today isn't particularly > interesting. > > > Morgaine. > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol wrote: > >> If there was focus only on the login (agent domain) and inventory >> services, >> then I think we will get some where. >> >> Yes, we know there are issues with inventory that are already in the >> simulator side, so this is the suggestion to build apart from those >> issues. >> Start from there. >> >> >> >> Izzy Alanis wrote: >> >>> Are you suggesting a re-charter around shared services only? >>> Or that we shift the deliverables to push that to the forefront? (In >>> which case, we still really do need an intro doc and to address the >>> messaging semantics) >>> >>> I'm not quite convinced that the charter is unsalvageable. I think the >>> last rev of the intro has a lot of good things in it too -- lots I >>> would like to see changed, but good stuff too. >>> >>> >>> >>> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine >>> wrote: >>> >>> >>>> I'm glad to see some renewed participation here!=EF=BF=BD Perhaps the = threat of >>>> death sharpens the mind. ;-) >>>> >>>> Since there seems to be some fresh thinking in the air, I am going to >>>> add >>>> two short points to the discussion.=EF=BF=BD The first is a matter of = procedure, >>>> and >>>> the second is related to our technical direction: >>>> >>>> Notwithstanding that the IETF places certain duties on Barry and other= s >>>> to >>>> ensure that there is visible progress in the form of documents, I must >>>> say >>>> that "documents at all costs" is not a particularly good way of >>>> achieving >>>> technical progress.=EF=BF=BD It's the "documents at all costs" push th= at gave us >>>> several documents previously, only one of which turned out to be usabl= e >>>> for >>>> interoperation between VWs.=EF=BF=BD Documents churned out before ther= e is >>>> agreement >>>> on goals and direction are a hindrance to the process, not an indicato= r >>>> of >>>> progress, and they waste everyone's time.=EF=BF=BD Progress is certain= ly not a >>>> matter of just putting pen to paper, as has been suggested.=EF=BF=BD F= ar from >>>> it. >>>> First we must agree as a group on how a given protocol is going to mee= t >>>> our >>>> goals, and drafts then present that formally with hard technical detai= ls >>>> added.=EF=BF=BD Done the other way around just results in much angst a= nd wasted >>>> effort, as happened here. >>>> >>>> Given the almost unanimous agreement that crystallized around Crista's >>>> thread of a few months ago which could be paraphrased as "The VWRAP >>>> documents do nothing for interop between virtual worlds", I would like >>>> to >>>> suggest that instead of continuing to beat the dead horse of OGP that = we >>>> still have on our hands, why don't we focus on delivering something th= at >>>> is >>>> actually usable by compatible groups like Opensim and realXtend and iE= D? >>>> There is a nugget of gold at the heart of the VWRAP concept which can >>>> provide exactly that:=EF=BF=BD the idea of shared asset services, and = a protocol >>>> for >>>> accessing them. >>>> >>>> There is a huge amount of activity in our sector of the virtual worlds >>>> community.=EF=BF=BD There is also no end of interest in interoperation= , but the >>>> trouble seems to be that each group is rather narrowly focused on thei= r >>>> own >>>> particular code base.=EF=BF=BD Where I think a group such as ours can = contribute >>>> is >>>> by providing a lightweight protocol which is easily used by all, witho= ut >>>> the >>>> previous baggage.=EF=BF=BD Simple problems demand simple solutions, an= d while a >>>> massively scalable shared asset service is not exactly simple, it is >>>> nevertheless a lot simpler than the much larger task that we had set >>>> ourselves previously. >>>> >>>> Perhaps that would be a good place to start, afresh. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba >>>> wrote: >>>> >>>> >>>>> Reminder: If anyone's done anything related to what's below, please >>>>> post here and get some discussion going. =EF=BF=BDThere's still about= two and >>>>> a half weeks to get something ready. >>>>> >>>>> Barry, as chair >>>>> >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >>>>> wrote: >>>>> >>>>> >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >>>>>> wrote: >>>>>> >>>>>> >>>>>>> As for timescales, we already started work on a new Intro in Octobe= r >>>>>>>> and >>>>>>>> November, as I described in my first email in this thread.=EF=BF= =BD It was >>>>>>>> being >>>>>>>> done informally, not as an official draft but as input to a totall= y >>>>>>>> new >>>>>>>> draft.=EF=BF=BD It was not being done as a revision because the pr= evious >>>>>>>> Intro >>>>>>>> simply did not meet key requirements for many contributors, as was >>>>>>>> clear >>>>>>>> from the group's very intense discussions of September. >>>>>>>> >>>>>>>> >>>>>>> Can you see if you can get it into reasonable shape to introduce >>>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? =EF= =BF=BDThat >>>>>>> would give people something concrete to work from. >>>>>>> >>>>>>> >>>>>> I haven't seen any activity on this, so let me repeat this with a >>>>>> deadline: >>>>>> >>>>>> The chairs ask the proponents to please get a new intro document int= o >>>>>> reasonable (not final) shape to introduce publicly, and to submit it >>>>>> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-00" >>>>>> by 10 April (the significance of which will be left for the reader t= o >>>>>> research, should s/he care to). =EF=BF=BDThere may, of course, be an= y >>>>>> (reasonable) number of authors listed on the draft, and any one may = be >>>>>> the name chosen to live in the draft name. >>>>>> >>>>>> If we're not able to do that, I think we need to seriously question >>>>>> whether there's enough real energy to continue. >>>>>> >>>>>> Barry, as chair >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >>> >>> >>> >> >> >> -- >> --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> > From dzonatas@gmail.com Sun Mar 27 08:45:13 2011 Return-Path: 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 B3C1E3A6873 for ; Sun, 27 Mar 2011 08:45:13 -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 rwmDBdFqCKGJ for ; Sun, 27 Mar 2011 08:45:12 -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 AF4123A686C for ; Sun, 27 Mar 2011 08:45:12 -0700 (PDT) Received: by iye19 with SMTP id 19so2537872iye.31 for ; Sun, 27 Mar 2011 08:46:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=cVF5LtFYoA+RUXTK0BI1mrf5b5oBkoHNECzXPtfEzh4=; b=sW5ISpaULDzlCMwgn9cJsPL8Yy1BflRFJpVuh0KQHK6gMsOzzk2StyWGssMg2dzGfR NuHRqMsv6mRe+zQSwxkYlEFY3WCnitaw1zIKe3o0+btUondYsbPnJoqWLb3iMdc4i1rD viLfKOF35YzKRGhKOk1i2LEVMLsSps7Zl7AVk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=OjSRy4O7qgPH4hTq7g8BJZXd2U2nnGTp2C5IItseRbcMWWVqScTDT7pTVeroopwOln MhXyhSWQswq9EB269sRaMcrBX3X7c8dRKJnx6Q/aKyhxtMMGL0H6Dt/MPkGiO+tHsIh9 E1ynFXDPiX5gKR9uhY4Ao/oDt0WN8nhKTPHCI= Received: by 10.43.58.135 with SMTP id wk7mr4803903icb.433.1301240809379; Sun, 27 Mar 2011 08:46:49 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo11sm2157530icb.8.2011.03.27.08.46.47 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2011 08:46:48 -0700 (PDT) Message-ID: <4D8F5BEA.3090603@gmail.com> Date: Sun, 27 Mar 2011 08:46:50 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: <4D8E95D6.3080102@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 15:45:13 -0000 As pointed out earlier, there is documentation on client-side REST based abilities. http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/SNOW-375_Resources That doesn't have to be HTTP. It is just easiest to demonstrate with HTTP. As for who owns inventories, of course it is a mistake to assume the server-side owns inventories. The avatar own's their inventories. We've talked about the manufactured objects in which different people own different parts of an object, and how to deal with such issue. The current design is not even able to handle this complex. Vaughn Deluca wrote: > Can you point out what part of the charter needs to be changed, or > better make a proposal for that change so we have something concrete > to work from? > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Sun Mar 27 10:24:18 2011 Return-Path: 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 C66083A67D1 for ; Sun, 27 Mar 2011 10:24:18 -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 HW-tJVBHr4mZ for ; Sun, 27 Mar 2011 10:24:17 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id AF3B23A67C1 for ; Sun, 27 Mar 2011 10:24:16 -0700 (PDT) Received: by eye13 with SMTP id 13so1066155eye.31 for ; Sun, 27 Mar 2011 10:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WgyKp4ksvD1hHZlgXVLlLfN+alW0ThVMSvzRfM3lQaQ=; b=mgafFO1tQc6FQ5BHFCt6UW1hAfXkuX6L0gBpTtcEEs8+b/yExgdiVpWTXXzHtX7eFV runjURMgbTmUzXO+cy2+D2vGS1JPDvMjnE0YNlsetnvPv5ZmldTSsCjD37IXZzaWbI3b Wkr4M3hMEoe5djGvcEE/6lAPNUyReQX9a5zN4= 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 :cc:content-type; b=a/j61dWYM5etczhXtHDYuqdD3hzyMK/sg9fPb1rn/ynFmq8OMnAJFub1junpXiLP8G QN23YzKyiBiPR7W6koWTM1KDeeXk7jgcrNpWMp6KDOJ78VI6KwgdigNnttfgjyw293ib EnbGLRvtcjiTfZGc9J4tb03lBkyGb4F4+9mcc= MIME-Version: 1.0 Received: by 10.213.29.211 with SMTP id r19mr827220ebc.119.1301246753026; Sun, 27 Mar 2011 10:25:53 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sun, 27 Mar 2011 10:25:52 -0700 (PDT) In-Reply-To: <20110327131843.GA15165@alinoe.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Sun, 27 Mar 2011 19:25:52 +0200 Message-ID: From: Vaughn Deluca To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 17:24:18 -0000 Great!, thanks a lot for the constructive input! I disagree however that this "won't lead to any document any time soon" It depends on the definition of "document" I might be a while before it produces an RFC, but I certainly would call the glossary, wiki pages documenting group consensus, and Definitions "documents". I like the wiki idea, (something along those lines was suggested by Morgaine also). I just requested a password, and it seems i can edit the Wiki :) I will put up a VWRAP glossary page later today. On 3/27/11, Carlo Wood wrote: > On Sat, Mar 26, 2011 at 10:43:49PM +0100, Vaughn Deluca wrote: >> problem we have is a lack of critical mass, and in particular input >> from people that have the needed technical background. And clearly >> you are one of those that we need badly. > > The way I'd like to move forward is anything but producing > documents fast however; and that seems to be the requirement. > > If you want input from me regarding the survival of this group; > I'd create a wiki that everyone who requests it can edit. > The first and most important part of that wiki would be a glossary > with every word that is frequently used in the discussions. > That list of words should be complete rather quickly, then > people can add their definitions to it. If two people have > different definitions then those definitions should be signed; > Once, for a particular word, everyone has added the definitions > and/or remarks to the wiki (all on one page per word), we can > start a discussion on this list on how to reformulize and change > the definition of that word. Some might have to change their > semantics, but in the end the goal would be that every word > has one defintion, used and understood by everyone -- and > clearly documented on the wiki, with discussion history as > usual. If a discussion gets completely stuck on semantics, > then people can just sign (put their name under) the definition > the want and we'd just count the signatures and pick one. > After all, it's just semantics and has nothing to do with what > the protocol REALLY will do. > > Only then, we can take the next step; for which I'd also > use the wiki. > > Also, as I wrote in old posts before... I am still CONVINCED that > we can impossibly create a protocol that will address everything > that will be needed in the future. All we can do is create something > that is a good starting point and FOCUS on flexibility: create > a protocol that can evolve. In order to do that, we need (further > completely protocol neutral) protocol negotiation for every p2p > link that is created in the process, which allows such evolution. > > The use of XML as basis for a protocol would mean the following: > 1) It takes overhead, so it's not possible to use it for > highbandwidth usage (ie video, or file transfers). But it could > do at out-of-band control channel. > 2) If it's pure XML than we won't have to worry about the > implementation of serializing/deserializing as much, although > that only really has it's advantages when we will need VWRAP > to work for implementations in multiple programming languages > before it gets accepted widely. As far as I can see, we will > need C# and C++, and most likely C for religious reasons. > 3) The ONLY benefit that XML has (on top of existing serialization > libraries) is that it is extensible: You can add new parameters > without confusing old code that doesn't expect it. > > Point 3, however, is just a weak attempt to be flexible. Imho, > it is by far not flexible enough. We'd still need a well defined > way for the evolving protocol negotiation, and once that is in > place, we won't really need this feature of XML anymore. > > Thus, provided we add "evolving protocol negotiation", we should > probably choose the serialization/deserialization method based on > grounds that I can't judge at this point in the design. > > So for the near future: > - Glossary and agreement on definitions of used jargon. > - Abstract agreement on the use of an evolving protocol. > - Definition of all possible p2p connection for which serialization is > necessary. > - Choice of what serialization mechanism is used where. > - Abstract discussion (and agreement) of the use of Abelian operators > for distributed states and identity authorities (see another > old post from me). If we don't do that before anything else, > we'd just shoot ourself in the foot. > - etc > > This is no doubt the work of years, and won't lead to any document > any time soon. > > -- > Carlo Wood > From vaughn.deluca@gmail.com Sun Mar 27 14:16:22 2011 Return-Path: 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 3ED0228C157 for ; Sun, 27 Mar 2011 14:16:22 -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 joK2CzxaWmsr for ; Sun, 27 Mar 2011 14:16:21 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D120828C148 for ; Sun, 27 Mar 2011 14:16:20 -0700 (PDT) Received: by ewy19 with SMTP id 19so1132633ewy.31 for ; Sun, 27 Mar 2011 14:17:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4nJIG8vsR1v3e3UolWE9X6OSJZ6Sp+LKqwWEchtRYJk=; b=AigRP+/E48MgoGWuASgyasuaLPP2J1pKaLLVOJRXT3nyJMDmzxye3ohUZlUgpxoX54 WqYwHHK6bJt3uGb3/07+R+LU7O9o2pVLwk2Xz5ejUflHxle8fFWtpFoX9mQYm4elPrEk M9wHtDMSvDyIKV4ZpPlAVNaI4YSfP661bFzE4= 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 :cc:content-type; b=JLl3ys2dHFEw6CgqVG5I4gpD9C08v8gOYXQ1xSjBCr6jvwyiFCAQNTmuzTS34V7fWq GTCAaLiB0xpygkdaBauJfbxFiJn0+uf9zGUC+hB8uUtDP8+2l65cJwYLQOAuqgBNu2mT I32ZzDCoH1/OaJxg9xMgtzY1F3OWtCR9qUIO4= MIME-Version: 1.0 Received: by 10.213.107.133 with SMTP id b5mr1424583ebp.81.1301260677183; Sun, 27 Mar 2011 14:17:57 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sun, 27 Mar 2011 14:17:57 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Sun, 27 Mar 2011 23:17:57 +0200 Message-ID: From: Vaughn Deluca To: Carlo Wood Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , Meadhbh Hamrick , Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 21:16:22 -0000 Done -- (at least the very first step). On 3/27/11, Vaughn Deluca wrote: > Great!, thanks a lot for the constructive input! > > I disagree however that this "won't lead to any document any time > soon" It depends on the definition of "document" I might be a while > before it produces an RFC, but I certainly would call the glossary, > wiki pages documenting group consensus, and Definitions "documents". > > I like the wiki idea, (something along those lines was suggested by > Morgaine also). I just requested a password, and it seems i can edit > the Wiki :) I will put up a VWRAP glossary page later today. > > On 3/27/11, Carlo Wood wrote: >> On Sat, Mar 26, 2011 at 10:43:49PM +0100, Vaughn Deluca wrote: >>> problem we have is a lack of critical mass, and in particular input >>> from people that have the needed technical background. And clearly >>> you are one of those that we need badly. >> >> The way I'd like to move forward is anything but producing >> documents fast however; and that seems to be the requirement. >> >> If you want input from me regarding the survival of this group; >> I'd create a wiki that everyone who requests it can edit. >> The first and most important part of that wiki would be a glossary >> with every word that is frequently used in the discussions. >> That list of words should be complete rather quickly, then >> people can add their definitions to it. If two people have >> different definitions then those definitions should be signed; >> Once, for a particular word, everyone has added the definitions >> and/or remarks to the wiki (all on one page per word), we can >> start a discussion on this list on how to reformulize and change >> the definition of that word. Some might have to change their >> semantics, but in the end the goal would be that every word >> has one defintion, used and understood by everyone -- and >> clearly documented on the wiki, with discussion history as >> usual. If a discussion gets completely stuck on semantics, >> then people can just sign (put their name under) the definition >> the want and we'd just count the signatures and pick one. >> After all, it's just semantics and has nothing to do with what >> the protocol REALLY will do. >> >> Only then, we can take the next step; for which I'd also >> use the wiki. >> >> Also, as I wrote in old posts before... I am still CONVINCED that >> we can impossibly create a protocol that will address everything >> that will be needed in the future. All we can do is create something >> that is a good starting point and FOCUS on flexibility: create >> a protocol that can evolve. In order to do that, we need (further >> completely protocol neutral) protocol negotiation for every p2p >> link that is created in the process, which allows such evolution. >> >> The use of XML as basis for a protocol would mean the following: >> 1) It takes overhead, so it's not possible to use it for >> highbandwidth usage (ie video, or file transfers). But it could >> do at out-of-band control channel. >> 2) If it's pure XML than we won't have to worry about the >> implementation of serializing/deserializing as much, although >> that only really has it's advantages when we will need VWRAP >> to work for implementations in multiple programming languages >> before it gets accepted widely. As far as I can see, we will >> need C# and C++, and most likely C for religious reasons. >> 3) The ONLY benefit that XML has (on top of existing serialization >> libraries) is that it is extensible: You can add new parameters >> without confusing old code that doesn't expect it. >> >> Point 3, however, is just a weak attempt to be flexible. Imho, >> it is by far not flexible enough. We'd still need a well defined >> way for the evolving protocol negotiation, and once that is in >> place, we won't really need this feature of XML anymore. >> >> Thus, provided we add "evolving protocol negotiation", we should >> probably choose the serialization/deserialization method based on >> grounds that I can't judge at this point in the design. >> >> So for the near future: >> - Glossary and agreement on definitions of used jargon. >> - Abstract agreement on the use of an evolving protocol. >> - Definition of all possible p2p connection for which serialization is >> necessary. >> - Choice of what serialization mechanism is used where. >> - Abstract discussion (and agreement) of the use of Abelian operators >> for distributed states and identity authorities (see another >> old post from me). If we don't do that before anything else, >> we'd just shoot ourself in the foot. >> - etc >> >> This is no doubt the work of years, and won't lead to any document >> any time soon. >> >> -- >> Carlo Wood >> > From fleep513@gmail.com Sun Mar 27 15:40:49 2011 Return-Path: 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 3202A28C16B for ; Sun, 27 Mar 2011 15:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 9HHM0xX4qfNu for ; Sun, 27 Mar 2011 15:40:47 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 51D7F28C0E2 for ; Sun, 27 Mar 2011 15:40:47 -0700 (PDT) Received: by ywi6 with SMTP id 6so1128120ywi.31 for ; Sun, 27 Mar 2011 15:42:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ASIqMr8Va/wb3veIIAY7xZOonfs8qj8AwM09tpgOCV8=; b=m1L32CwB8/BJWlTLhABZ/fNV2Uj5d8v8ecwjTqcAOU9gGH5c+ttlUzgg6RnR8XTKjQ P+Fmt6OE8HgEUrUJHzipvspE68Dde9QuiGOzFwb7rWR9PuIm7yAlxRkczwI/fLbi28Np pQoM7GEGR3XNw7S9R1AmsXjIOtGsVZo/eqnNs= 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=kX84AO6Zv8FSSViI842q1I5Wh7ZEp+3Y2FI//nCCwEpzF/vci8HMV+y1BBDBGyfQJI cPZpfg8XHjdvtqykl4eR1bh0YhZhhCT2mkeJ7hd3qdZkO6yXNg20vdCs6FiQJUgRArVh 6H8xmMu6soCXrmkcnOnZyk2Dq0+pfw2lL6upw= MIME-Version: 1.0 Received: by 10.90.173.9 with SMTP id v9mr3295435age.79.1301265742670; Sun, 27 Mar 2011 15:42:22 -0700 (PDT) Received: by 10.90.89.5 with HTTP; Sun, 27 Mar 2011 15:42:22 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Sun, 27 Mar 2011 18:42:22 -0400 Message-ID: From: Fleep Tuque To: "" Content-Type: multipart/alternative; boundary=00163630e91759aac2049f7e8ab3 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:40:49 -0000 --00163630e91759aac2049f7e8ab3 Content-Type: text/plain; charset=ISO-8859-1 We've discussed the wiki concept several times and several of us started a wiki some months ago, but Peter reminded us that there is an official wiki that should be used for these efforts. See his message below. - 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 ---------- Forwarded message ---------- From: Peter Saint-Andre Date: Thu, Jan 20, 2011 at 10:04 PM Subject: Re: [vwrap] Status and future of the VWRAP working group To: vwrap@ietf.org With my area director hat on: a.) I like the idea of collaborative effort at a wiki. This lowers the barriers to entry. A big +1. b.) I'd prefer to see this happen at the official working group wiki: http://trac.tools.ietf.org/wg/vwrap/trac/wiki The main factor here is the IETF's policy on contributions, a.k.a. "Note Well"... http://www.ietf.org/about/note-well.html I am not a lawyer, but I doubt that work happening at a wiki site somewhere else is covered under "Note Well". The last thing we want is ambiguity about copyrights and patents, so I strongly encourage folks to do this work at the Trac URL I posted above. To request login credentials, go here: http://trac.tools.ietf.org/tools/loginmgr/newlogin Thanks! Peter UC Second Life: http://homepages.uc.edu/secondlife OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php --00163630e91759aac2049f7e8ab3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've discussed the wiki concept several times and several of us starte= d a wiki some months ago, but Peter reminded us that there is an official w= iki that should be used for these efforts. =A0See his message below.

- Chris/Fleep

Chris M. Collins (SL:= Fleep Tuque)
Project Manager, UC Second Life=A0
Second= Life Ambassador, Ohio Learning Network=A0
UCit Instructional &am= p; Research Computing
University of Cincinnati=A0
406E Zimmer Hall
PO Bo= x 210088
Cincinnati, OH 45221-0088


---------- Forwarded message ----------
Fr= om:=A0Peter Saint-Andre=A0<stpeter@stpeter.im>
Date: Thu, Jan 20, 2011 at 10:04 PM
Subject: Re: [vwrap] Status and futu= re of the VWRAP working group
To: vwra= p@ietf.org


With my area director hat on:

a.) I like t= he idea of collaborative effort at a wiki. This lowers the
barriers to entry. A big +1.

b.) I'd prefer to see this happen a= t the official working group wiki:

=A0 =A0http://trac.tools.ietf.or= g/wg/vwrap/trac/wiki

The main factor here is the IETF's policy on contributions, a.k.a. = "Note
Well"...

=A0 =A0http://www.ietf.org/about/note-well.h= tml

I am not a lawyer, but I doubt that work happening at a wiki site
so= mewhere else is covered under "Note Well". The last thing we want= is
ambiguity about copyrights and patents, so I strongly encourage folk= s to
do this work at the Trac URL I posted above.

To request login creden= tials, go here:

=A0 =A0http://trac.tools.ietf.org/tools/loginm= gr/newlogin

Thanks!

Peter




--00163630e91759aac2049f7e8ab3-- From vaughn.deluca@gmail.com Sun Mar 27 15:47:37 2011 Return-Path: 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 66EA428C17D for ; Sun, 27 Mar 2011 15:47:37 -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 Nyj5dJXq+sfD for ; Sun, 27 Mar 2011 15:47:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 12BF928C0EE for ; Sun, 27 Mar 2011 15:47:35 -0700 (PDT) Received: by ewy19 with SMTP id 19so1146517ewy.31 for ; Sun, 27 Mar 2011 15:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=50ypiLn8VNlYEphFPrnny+SXV7yhBGyDcBpLtJ1qIvU=; b=qj2DPOMBdWLiTBSGPoMfiDp6hW7+Tex4zRUbJrjPyuU1ytsohg2nsBHWdfnrC03yp8 WoOytfNAI4gIUKn12vJteQjKhRtZ4KWusMQtP3b13BtEixWqRan8B+4D/42USy+reNlZ lvVPjqgeryc9PQPFx3CY1rkmtesnnaa4LlEiY= 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 :cc:content-type; b=ngSV6ab+W0uenv9aqwObwZDjQwtzqX3FFpU4TTwVPXF+P0NGHntequqc4RqTKzsnip oEDjq0QcMzA/3NvoRBGc6DDXhzk/vIfTGy7VDHavfV93leoFnwaqcRbTmCvIwIambksV 0ys5Yykq7nVtSBSFrmyA8kpQG9Sxdx6V1ZU+4= MIME-Version: 1.0 Received: by 10.213.107.17 with SMTP id z17mr1432927ebo.100.1301266152130; Sun, 27 Mar 2011 15:49:12 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Sun, 27 Mar 2011 15:49:12 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Mon, 28 Mar 2011 00:49:12 +0200 Message-ID: From: Vaughn Deluca To: Fleep Tuque Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 22:47:37 -0000 > I'd prefer to see this happen at the official working group wiki: > http://trac.tools.ietf.org/wg/vwrap/trac/wiki And that is were it is now. :) --Vaughn On 3/28/11, Fleep Tuque wrote: > We've discussed the wiki concept several times and several of us started a > wiki some months ago, but Peter reminded us that there is an official wiki > that should be used for these efforts. See his message below. > > - 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 > > > ---------- Forwarded message ---------- > From: Peter Saint-Andre > Date: Thu, Jan 20, 2011 at 10:04 PM > Subject: Re: [vwrap] Status and future of the VWRAP working group > To: vwrap@ietf.org > > > With my area director hat on: > > a.) I like the idea of collaborative effort at a wiki. This lowers the > barriers to entry. A big +1. > > b.) I'd prefer to see this happen at the official working group wiki: > > http://trac.tools.ietf.org/wg/vwrap/trac/wiki > > The main factor here is the IETF's policy on contributions, a.k.a. "Note > Well"... > > http://www.ietf.org/about/note-well.html > > I am not a lawyer, but I doubt that work happening at a wiki site > somewhere else is covered under "Note Well". The last thing we want is > ambiguity about copyrights and patents, so I strongly encourage folks to > do this work at the Trac URL I posted above. > > To request login credentials, go here: > > http://trac.tools.ietf.org/tools/loginmgr/newlogin > > Thanks! > > Peter > > UC Second Life: http://homepages.uc.edu/secondlife > OLN Second Life: http://www.oln.org/emerging_technologies/emtech.php > From morgaine.dinova@googlemail.com Sun Mar 27 17:15:59 2011 Return-Path: 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 427D328C17A for ; Sun, 27 Mar 2011 17:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 PpreaD3TdqSL for ; Sun, 27 Mar 2011 17:15:56 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 666A528C16E for ; Sun, 27 Mar 2011 17:15:56 -0700 (PDT) Received: by qyk7 with SMTP id 7so1727452qyk.10 for ; Sun, 27 Mar 2011 17:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ps+SGVi2Aus261Sn1Syxg880u1jciNDA8pmXEha5Kxo=; b=SFTnTKS1AoeczOImnqwB6eMqCsRlhYPAjTAo6NOTMVqQ4M20c3eRCmvfEkmoQ2hp4Q GbkDf0fd92TvUBCmSO3tw7Ocz93EsBA3T1j3j1VAOxtcFJPtGSwU4G729xEi6vxb5ZMh IzKuQBum0Nwxx+DeLm+PSGBzOYdUANQJOD5v0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=rn73qCpvV+wD9qL65da9B8sWGC4xYw0+ueXxKdr8GPlbYs703U5OV8wWBJUQwsx37I 7HjVyEq46xEfvIZM3UJNK4EE1go8WsHNuFFlyjIJait0mzBRR3cKzXRt/U190UVBotk8 ctdoX8rXCtY6K6Pdr7viKhKUGPN58HMyzoTBo= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr2761867qcr.71.1301271453230; Sun, 27 Mar 2011 17:17:33 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Sun, 27 Mar 2011 17:17:32 -0700 (PDT) In-Reply-To: References: <4D8E95D6.3080102@gmail.com> Date: Mon, 28 Mar 2011 01:17:32 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caeb9e698049f7fde8b Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 00:15:59 -0000 --000e0cd25caeb9e698049f7fde8b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I may have unconconsciously been evading the question of rechartering up to now, possibly because it was and is such a pain point. No more evading though, if we want to get something done. Re-chartering seems inevitable to me, because the existing charter failed s= o very dramatically to guide us towards the requirement that we recently made explicit, namely interoperation between virtual worlds. I'm not too surprised at that failure, since it has been very clear from th= e start that everybody except the main sponsoring companies expected interop between virtual worlds to materialize from our work. Consequently, I could see the problem coming our way once the realization that it wasn't on the agenda finally hit home more widely. Crista did us a great service by triggering that understanding within the group. Armed with that understanding now, it is easy to see how the charter sold u= s a bridge. After all, nowhere does it state that the goal is interoperation between virtual worlds, so it has been wishful thinking alone that made so many people expect otherwise. While it mentions asset services being run b= y more than one organization, it never stated that these asset services could serve multiple virtual worlds and hence act as the essential bridge for interop of assets between them. Again, it was just wishful thinking that made some people interpret it that way, but as we now know, it was not the design goal. There are many such occurrences in the charter. It seems to vaguely use th= e language of interop, but only in respect of growing virtual worlds by addin= g regions to them (ie. it's an *intra*-world protocol, not *inter*-world). I= t does not offer anything to allow such virtual worlds to interoperate in the way most people expect, for example supporting virtual tourism between them= . Since the charter does not expressly state what we want, it is incorrect, o= r worse, misdirecting. I see no alternative to rechartering if we expect the outcome to be interop between virtual worlds. If we do not recharter, it will not describe our goals, and it will not be meaningful to other readers. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On Sun, Mar 27, 2011 at 3:37 PM, Vaughn Deluca wro= te: > Morgaine, > > All very well, but you did not answer Izzy's question about rechartering. > I agree with Izzy that it is by no means clear that the current > charter is unsalvageable. > > For instance, your post below you write: > >All we really need are shared asset services that are independent of the > world providers. > > I my view this is square within the current charter were it says: > > "Within a VWRAP virtual environment, services may be deployed by > multiple organizations having varying policies and trust domains." > > I have always read that as meaning that an inventory could be > *anywhere* and owned by *anybody*, and that surely covers my own > client side inventory as well (possibly implemented as a personal > asset service running on my own machine?) > > The decision to have server side inventory is clearly the choice of > that servers operator, and it is my chose use that inventory if that > suits me. If client side inventory is superior that will become clear > by users preferring to use it. I fail to see how our current approach > is an obstacle on this path. > > Can you point out what part of the charter needs to be changed, or > better make a proposal for that change so we have something concrete > to work from? > > I strongly feel we need to build some consensus in this group, and to > do so we need to be crystal clear about our aims. We should start > front be very top. You had a first attempt at restructuring the intro > document, but we need to address the charter first. My view is that it > is not yet needed to change that, and if you feel different this is > the time to say so. > > -- Vaughn > > On 3/27/11, Morgaine wrote: > > Indeed, server-side inventories are one of the worst design decisions o= f > the > > existing implementations. > > > > They give us no end of problems, such as the impossibility of high-spee= d > > client-side searching and regular lag issues, not to mention being > > non-portable because each world provider would implement them > differently. > > They're also non-scalable because they're centralized, and non supporti= ve > of > > VW tourism because a given world provider would control what can be put > into > > them, instead of the traveling user being in control. > > > > Inventories need to be client-side (I refer to the trees of asset > metadata, > > not the asset data, in case that's not clear), with an auto sync of > deltas > > to a configured asset service for resilience/backup. That way only tho= se > > people who do not look after their local inventory resources will suffe= r > > client-server transport lag to recreate them, and the full power of > > client-side CPUs and client-side databases and scripting can be deploye= d > to > > make inventories a real powerhouse. > > > > All we really need are shared asset services that are independent of th= e > > world providers. That alone is enough to virtually ensure portability, > > interoperability, and scalability, as long as a lightweight protocol ca= n > be > > found that is also extensible to support tomorrow's worlds. Making a > > standard to support only what we're doing today isn't particularly > > interesting. > > > > > > Morgaine. > > > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol > wrote: > > > >> If there was focus only on the login (agent domain) and inventory > >> services, > >> then I think we will get some where. > >> > >> Yes, we know there are issues with inventory that are already in the > >> simulator side, so this is the suggestion to build apart from those > >> issues. > >> Start from there. > >> > >> > >> > >> Izzy Alanis wrote: > >> > >>> Are you suggesting a re-charter around shared services only? > >>> Or that we shift the deliverables to push that to the forefront? (In > >>> which case, we still really do need an intro doc and to address the > >>> messaging semantics) > >>> > >>> I'm not quite convinced that the charter is unsalvageable. I think th= e > >>> last rev of the intro has a lot of good things in it too -- lots I > >>> would like to see changed, but good stuff too. > >>> > >>> > >>> > >>> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine > >>> wrote: > >>> > >>> > >>>> I'm glad to see some renewed participation here!=EF=BF=BD Perhaps th= e threat > of > >>>> death sharpens the mind. ;-) > >>>> > >>>> Since there seems to be some fresh thinking in the air, I am going t= o > >>>> add > >>>> two short points to the discussion.=EF=BF=BD The first is a matter o= f > procedure, > >>>> and > >>>> the second is related to our technical direction: > >>>> > >>>> Notwithstanding that the IETF places certain duties on Barry and > others > >>>> to > >>>> ensure that there is visible progress in the form of documents, I mu= st > >>>> say > >>>> that "documents at all costs" is not a particularly good way of > >>>> achieving > >>>> technical progress.=EF=BF=BD It's the "documents at all costs" push = that gave > us > >>>> several documents previously, only one of which turned out to be > usable > >>>> for > >>>> interoperation between VWs.=EF=BF=BD Documents churned out before th= ere is > >>>> agreement > >>>> on goals and direction are a hindrance to the process, not an > indicator > >>>> of > >>>> progress, and they waste everyone's time.=EF=BF=BD Progress is certa= inly not a > >>>> matter of just putting pen to paper, as has been suggested.=EF=BF=BD= Far from > >>>> it. > >>>> First we must agree as a group on how a given protocol is going to > meet > >>>> our > >>>> goals, and drafts then present that formally with hard technical > details > >>>> added.=EF=BF=BD Done the other way around just results in much angst= and > wasted > >>>> effort, as happened here. > >>>> > >>>> Given the almost unanimous agreement that crystallized around Crista= 's > >>>> thread of a few months ago which could be paraphrased as "The VWRAP > >>>> documents do nothing for interop between virtual worlds", I would li= ke > >>>> to > >>>> suggest that instead of continuing to beat the dead horse of OGP tha= t > we > >>>> still have on our hands, why don't we focus on delivering something > that > >>>> is > >>>> actually usable by compatible groups like Opensim and realXtend and > iED? > >>>> There is a nugget of gold at the heart of the VWRAP concept which ca= n > >>>> provide exactly that:=EF=BF=BD the idea of shared asset services, an= d a > protocol > >>>> for > >>>> accessing them. > >>>> > >>>> There is a huge amount of activity in our sector of the virtual worl= ds > >>>> community.=EF=BF=BD There is also no end of interest in interoperati= on, but > the > >>>> trouble seems to be that each group is rather narrowly focused on > their > >>>> own > >>>> particular code base.=EF=BF=BD Where I think a group such as ours ca= n > contribute > >>>> is > >>>> by providing a lightweight protocol which is easily used by all, > without > >>>> the > >>>> previous baggage.=EF=BF=BD Simple problems demand simple solutions, = and while > a > >>>> massively scalable shared asset service is not exactly simple, it is > >>>> nevertheless a lot simpler than the much larger task that we had set > >>>> ourselves previously. > >>>> > >>>> Perhaps that would be a good place to start, afresh. > >>>> > >>>> > >>>> Morgaine. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>>> > >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba > > >>>> wrote: > >>>> > >>>> > >>>>> Reminder: If anyone's done anything related to what's below, please > >>>>> post here and get some discussion going. =EF=BF=BDThere's still abo= ut two and > >>>>> a half weeks to get something ready. > >>>>> > >>>>> Barry, as chair > >>>>> > >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba < > barryleiba@computer.org> > >>>>> wrote: > >>>>> > >>>>> > >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba < > barryleiba@computer.org> > >>>>>> wrote: > >>>>>> > >>>>>> > >>>>>>> As for timescales, we already started work on a new Intro in > October > >>>>>>>> and > >>>>>>>> November, as I described in my first email in this thread.=EF=BF= =BD It was > >>>>>>>> being > >>>>>>>> done informally, not as an official draft but as input to a > totally > >>>>>>>> new > >>>>>>>> draft.=EF=BF=BD It was not being done as a revision because the = previous > >>>>>>>> Intro > >>>>>>>> simply did not meet key requirements for many contributors, as w= as > >>>>>>>> clear > >>>>>>>> from the group's very intense discussions of September. > >>>>>>>> > >>>>>>>> > >>>>>>> Can you see if you can get it into reasonable shape to introduce > >>>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? > =EF=BF=BDThat > >>>>>>> would give people something concrete to work from. > >>>>>>> > >>>>>>> > >>>>>> I haven't seen any activity on this, so let me repeat this with a > >>>>>> deadline: > >>>>>> > >>>>>> The chairs ask the proponents to please get a new intro document > into > >>>>>> reasonable (not final) shape to introduce publicly, and to submit = it > >>>>>> as an Internet Draft with a name like "draft-SOMEONE-vwrap-intro-0= 0" > >>>>>> by 10 April (the significance of which will be left for the reader > to > >>>>>> research, should s/he care to). =EF=BF=BDThere may, of course, be = any > >>>>>> (reasonable) number of authors listed on the draft, and any one ma= y > be > >>>>>> the name chosen to live in the draft name. > >>>>>> > >>>>>> If we're not able to do that, I think we need to seriously questio= n > >>>>>> whether there's enough real energy to continue. > >>>>>> > >>>>>> Barry, as chair > >>>>>> > >>>>>> > >>>>>> > >>>>> _______________________________________________ > >>>>> 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 mailing list > >>> vwrap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/vwrap > >>> > >>> > >>> > >> > >> > >> -- > >> --- https://twitter.com/Dzonatas_Sol --- > >> Web Development, Software Engineering, Virtual Reality, Consultant > >> > >> > > > --000e0cd25caeb9e698049f7fde8b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think I may have unconconsciously been evading the question of recharteri= ng up to now, possibly because it was and is such a pain point.=C2=A0 No mo= re evading though, if we want to get something done.

Re-chartering s= eems inevitable to me, because the existing charter failed so very dramatic= ally to guide us towards the requirement that we recently made explicit, na= mely interoperation between virtual worlds.

I'm not too surprised at that failure, since it has been very clear= from the start that everybody except the main sponsoring companies expecte= d interop between virtual worlds to materialize from our work.=C2=A0 Conseq= uently, I could see the problem coming our way once the realization that it= wasn't on the agenda finally hit home more widely.=C2=A0 Crista did us= a great service by triggering that understanding within the group.

Armed with that understanding now, it is easy to see how the charter so= ld us a bridge.=C2=A0 After all, nowhere does it state that the goal is int= eroperation between virtual worlds, so it has been wishful thinking alone t= hat made so many people expect otherwise.=C2=A0 While it mentions asset ser= vices being run by more than one organization, it never stated that these a= sset services could serve multiple virtual worlds and hence act as the esse= ntial bridge for interop of assets between them.=C2=A0 Again, it was just w= ishful thinking that made some people interpret it that way, but as we now = know, it was not the design goal.

There are many such occurrences in the charter.=C2=A0 It seems to vague= ly use the language of interop, but only in respect of growing virtual worl= ds by adding regions to them (ie. it's an intra-world protocol, = not inter-world).=C2=A0 It does not offer anything to allow such vir= tual worlds to interoperate in the way most people expect, for example supp= orting virtual tourism between them.

Since the charter does not expressly state what we want, it is incorrec= t, or worse, misdirecting.

I see no alternative to rechartering if w= e expect the outcome to be interop between virtual worlds.=C2=A0 If we do n= ot recharter, it will not describe our goals, and it will not be meaningful= to other readers.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= div class=3D"gmail_quote">On Sun, Mar 27, 2011 at 3:37 PM, Vaughn Deluca <vaughn.deluc= a@gmail.com> wrote:
Morgaine,

All very well, but you did not answer Izzy's question about recharterin= g.
I agree with Izzy that it is by no means clear that the current
charter is unsalvageable.

For instance, your post below you write:
>All we really need are shared asset services that are independent of th= e world providers.

I my view this is square within the current charter were it says:

"Within a VWRAP virtual environment, services may be deployed by
multiple organizations having varying policies and trust domains."

I have always read that as meaning that an inventory could be
*anywhere* and owned by *anybody*, and that surely covers my own
client side inventory as well (possibly implemented as a personal
asset service running on my own machine?)

The decision to have server side inventory is clearly the choice of
that servers operator, and it is my chose use that inventory if that
suits me. =C2=A0If client side inventory is superior that will become clear=
by users preferring to use it. I fail to see =C2=A0how our current approach=
is an obstacle on this path.

Can you point out what part of the charter needs to be changed, or
better make a proposal for that change so we have something concrete
to work from?

I strongly feel we need to build some consensus in this group, and to
do so we need to be crystal clear about our aims. We should start
front be very top. You had a first attempt at restructuring the intro
document, but we need to address the charter first. My view is that it
is not yet needed to change that, and if you feel different this is
the time to say so.

-- Vaughn

On 3/27/11, Morgaine <= morgaine.dinova@googlemail.com> wrote:
> Indeed, server-side inventories are one of the worst design decisions = of the
> existing implementations.
>
> They give us no end of problems, such as the impossibility of high-spe= ed
> client-side searching and regular lag issues, not to mention being
> non-portable because each world provider would implement them differen= tly.
> They're also non-scalable because they're centralized, and non= supportive of
> VW tourism because a given world provider would control what can be pu= t into
> them, instead of the traveling user being in control.
>
> Inventories need to be client-side (I refer to the trees of asset meta= data,
> not the asset data, in case that's not clear), with an auto sync o= f deltas
> to a configured asset service for resilience/backup. =C2=A0That way on= ly those
> people who do not look after their local inventory resources will suff= er
> client-server transport lag to recreate them, and the full power of > client-side CPUs and client-side databases and scripting can be deploy= ed to
> make inventories a real powerhouse.
>
> All we really need are shared asset services that are independent of t= he
> world providers. =C2=A0That alone is enough to virtually ensure portab= ility,
> interoperability, and scalability, as long as a lightweight protocol c= an be
> found that is also extensible to support tomorrow's worlds. =C2=A0= Making a
> standard to support only what we're doing today isn't particul= arly
> interesting.
>
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
>
>> If there was focus only on the login (agent domain) and inventory<= br> >> services,
>> then I think we will get some where.
>>
>> Yes, we know there are issues with inventory that are already in t= he
>> simulator side, so this is the suggestion to build apart from thos= e
>> issues.
>> Start from there.
>>
>>
>>
>> Izzy Alanis wrote:
>>
>>> Are you suggesting a re-charter around shared services only? >>> Or that we shift the deliverables to push that to the forefron= t? (In
>>> which case, we still really do need an intro doc and to addres= s the
>>> messaging semantics)
>>>
>>> I'm not quite convinced that the charter is unsalvageable.= I think the
>>> last rev of the intro has a lot of good things in it too -- lo= ts I
>>> would like to see changed, but good stuff too.
>>>
>>>
>>>
>>> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine
>>> <morgaine= .dinova@googlemail.com> wrote:
>>>
>>>
>>>> I'm glad to see some renewed participation here!=EF=BF= =BD Perhaps the threat of
>>>> death sharpens the mind. ;-)
>>>>
>>>> Since there seems to be some fresh thinking in the air, I = am going to
>>>> add
>>>> two short points to the discussion.=EF=BF=BD The first is = a matter of procedure,
>>>> and
>>>> the second is related to our technical direction:
>>>>
>>>> Notwithstanding that the IETF places certain duties on Bar= ry and others
>>>> to
>>>> ensure that there is visible progress in the form of docum= ents, I must
>>>> say
>>>> that "documents at all costs" is not a particula= rly good way of
>>>> achieving
>>>> technical progress.=EF=BF=BD It's the "documents = at all costs" push that gave us
>>>> several documents previously, only one of which turned out= to be usable
>>>> for
>>>> interoperation between VWs.=EF=BF=BD Documents churned out= before there is
>>>> agreement
>>>> on goals and direction are a hindrance to the process, not= an indicator
>>>> of
>>>> progress, and they waste everyone's time.=EF=BF=BD Pro= gress is certainly not a
>>>> matter of just putting pen to paper, as has been suggested= .=EF=BF=BD Far from
>>>> it.
>>>> First we must agree as a group on how a given protocol is = going to meet
>>>> our
>>>> goals, and drafts then present that formally with hard tec= hnical details
>>>> added.=EF=BF=BD Done the other way around just results in = much angst and wasted
>>>> effort, as happened here.
>>>>
>>>> Given the almost unanimous agreement that crystallized aro= und Crista's
>>>> thread of a few months ago which could be paraphrased as &= quot;The VWRAP
>>>> documents do nothing for interop between virtual worlds&qu= ot;, I would like
>>>> to
>>>> suggest that instead of continuing to beat the dead horse = of OGP that we
>>>> still have on our hands, why don't we focus on deliver= ing something that
>>>> is
>>>> actually usable by compatible groups like Opensim and real= Xtend and iED?
>>>> There is a nugget of gold at the heart of the VWRAP concep= t which can
>>>> provide exactly that:=EF=BF=BD the idea of shared asset se= rvices, and a protocol
>>>> for
>>>> accessing them.
>>>>
>>>> There is a huge amount of activity in our sector of the vi= rtual worlds
>>>> community.=EF=BF=BD There is also no end of interest in in= teroperation, but the
>>>> trouble seems to be that each group is rather narrowly foc= used on their
>>>> own
>>>> particular code base.=EF=BF=BD Where I think a group such = as ours can contribute
>>>> is
>>>> by providing a lightweight protocol which is easily used b= y all, without
>>>> the
>>>> previous baggage.=EF=BF=BD Simple problems demand simple s= olutions, and while a
>>>> massively scalable shared asset service is not exactly sim= ple, it is
>>>> nevertheless a lot simpler than the much larger task that = we had set
>>>> ourselves previously.
>>>>
>>>> Perhaps that would be a good place to start, afresh.
>>>>
>>>>
>>>> Morgaine.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba <barryleiba@computer.org>
>>>> wrote:
>>>>
>>>>
>>>>> Reminder: If anyone's done anything related to wha= t's below, please
>>>>> post here and get some discussion going. =EF=BF=BDTher= e's still about two and
>>>>> a half weeks to get something ready.
>>>>>
>>>>> Barry, as chair
>>>>>
>>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba <barryleiba@computer.org>
>>>>> wrote:
>>>>>
>>>>>
>>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba <<= a href=3D"mailto:barryleiba@computer.org">barryleiba@computer.org> >>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>> As for timescales, we already started work on = a new Intro in October
>>>>>>>> and
>>>>>>>> November, as I described in my first email= in this thread.=EF=BF=BD It was
>>>>>>>> being
>>>>>>>> done informally, not as an official draft = but as input to a totally
>>>>>>>> new
>>>>>>>> draft.=EF=BF=BD It was not being done as a= revision because the previous
>>>>>>>> Intro
>>>>>>>> simply did not meet key requirements for m= any contributors, as was
>>>>>>>> clear
>>>>>>>> from the group's very intense discussi= ons of September.
>>>>>>>>
>>>>>>>>
>>>>>>> Can you see if you can get it into reasonable = shape to introduce
>>>>>>> publicly, and then submit it as draft-morgaine= -vwrap-intro-00 ? =EF=BF=BDThat
>>>>>>> would give people something concrete to work f= rom.
>>>>>>>
>>>>>>>
>>>>>> I haven't seen any activity on this, so let me= repeat this with a
>>>>>> deadline:
>>>>>>
>>>>>> The chairs ask the proponents to please get a new = intro document into
>>>>>> reasonable (not final) shape to introduce publicly= , and to submit it
>>>>>> as an Internet Draft with a name like "draft-= SOMEONE-vwrap-intro-00"
>>>>>> by 10 April (the significance of which will be lef= t for the reader to
>>>>>> research, should s/he care to). =EF=BF=BDThere may= , of course, be any
>>>>>> (reasonable) number of authors listed on the draft= , and any one may be
>>>>>> the name chosen to live in the draft name.
>>>>>>
>>>>>> If we're not able to do that, I think we need = to seriously question
>>>>>> whether there's enough real energy to continue= .
>>>>>>
>>>>>> Barry, as chair
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> 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 mailing list
>>> vwrap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>
>>>
>>>
>>
>>
>> --
>> --- https://twitter.com/Dzonatas_Sol ---
>> Web Development, Software Engineering, Virtual Reality, Consultant=
>>
>>
>

--000e0cd25caeb9e698049f7fde8b-- From izzyalanis@gmail.com Sun Mar 27 21:19:42 2011 Return-Path: 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 7FD023A6808 for ; Sun, 27 Mar 2011 21:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 oVkzBgeN1uF9 for ; Sun, 27 Mar 2011 21:19:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 034833A67D4 for ; Sun, 27 Mar 2011 21:19:39 -0700 (PDT) Received: by fxm15 with SMTP id 15so2579999fxm.31 for ; Sun, 27 Mar 2011 21:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=mvjogMbQKg/2AB+qoZ3UaU4c4qEXn7bL6pKOoFoaGNg=; b=ZK102uhPnlVeVuGGebJ492Exl50JK4zezzliBaIfDD5NQEDZnoTn/ivhBpBG0nDbhV H/fqui1wGdp3d/1CS4JctMaIxl+pOYL/fQGELeRKwqQzlxWg7kYYSGfW4HwwLDbN+cdi ymrNGLhIbwU0PAaUOcqYnTqPtzPqKDLek5PsQ= 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 :cc:content-type:content-transfer-encoding; b=c9v6mbuV6gS6xDY3o9mKsAraa81oYknfVRsJNlM8+yQ7d2xGgFS/yqLIHNRLVAVdOt 6kXy5RT/bb45SPvD86qHg8ZgFmAHm166+TtQqLZdXdkz2HlR+v3KX4eC0/EwvfCYlJ+I UwZBQ6tKk1pXmj/mWPcmd7YZfxXXThKEYV/qw= MIME-Version: 1.0 Received: by 10.223.161.194 with SMTP id s2mr1230368fax.143.1301286075970; Sun, 27 Mar 2011 21:21:15 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sun, 27 Mar 2011 21:21:15 -0700 (PDT) In-Reply-To: References: <4D8E95D6.3080102@gmail.com> Date: Mon, 28 Mar 2011 00:21:15 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 04:19:42 -0000 I definitely agree that the charter reflect (define!) our goals... but what are those goals? I prefer to read the existing charter as very ambitious. Trying ... not to bridge existing worlds, but allow for the creation of new worlds in which new things are possible. But the rest of the documentation is littered with implementation details about the existing virtual worlds. It's the pull and tug between breaking free with new ideas (and, Morgaine, you have a lot of cool new ideas) and being tied to the existing infrastructure that's at conflict here. When I say that the existing charter was salvageable, I mean this: If we're going to follow that ambitious goal and forge ahead (possibly leaving the existing virtual worlds behind)... then yeah, I think we can work under this charter. If we need to step back and rein in our ambition (focus on interoperability and asset sharing between existing virtual worlds?), then the charter should reflect that to give the group focus. On Sun, Mar 27, 2011 at 8:17 PM, Morgaine wrote: > I think I may have unconconsciously been evading the question of > rechartering up to now, possibly because it was and is such a pain point. > No more evading though, if we want to get something done. > > Re-chartering seems inevitable to me, because the existing charter failed= so > very dramatically to guide us towards the requirement that we recently ma= de > explicit, namely interoperation between virtual worlds. > > I'm not too surprised at that failure, since it has been very clear from = the > start that everybody except the main sponsoring companies expected intero= p > between virtual worlds to materialize from our work.=C2=A0 Consequently, = I could > see the problem coming our way once the realization that it wasn't on the > agenda finally hit home more widely.=C2=A0 Crista did us a great service = by > triggering that understanding within the group. > > Armed with that understanding now, it is easy to see how the charter sold= us > a bridge.=C2=A0 After all, nowhere does it state that the goal is interop= eration > between virtual worlds, so it has been wishful thinking alone that made s= o > many people expect otherwise.=C2=A0 While it mentions asset services bein= g run by > more than one organization, it never stated that these asset services cou= ld > serve multiple virtual worlds and hence act as the essential bridge for > interop of assets between them.=C2=A0 Again, it was just wishful thinking= that > made some people interpret it that way, but as we now know, it was not th= e > design goal. > > There are many such occurrences in the charter.=C2=A0 It seems to vaguely= use the > language of interop, but only in respect of growing virtual worlds by add= ing > regions to them (ie. it's an intra-world protocol, not inter-world).=C2= =A0 It > does not offer anything to allow such virtual worlds to interoperate in t= he > way most people expect, for example supporting virtual tourism between th= em. > > Since the charter does not expressly state what we want, it is incorrect,= or > worse, misdirecting. > > I see no alternative to rechartering if we expect the outcome to be inter= op > between virtual worlds.=C2=A0 If we do not recharter, it will not describ= e our > goals, and it will not be meaningful to other readers. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Sun, Mar 27, 2011 at 3:37 PM, Vaughn Deluca > wrote: >> >> Morgaine, >> >> All very well, but you did not answer Izzy's question about rechartering= . >> I agree with Izzy that it is by no means clear that the current >> charter is unsalvageable. >> >> For instance, your post below you write: >> >All we really need are shared asset services that are independent of th= e >> > world providers. >> >> I my view this is square within the current charter were it says: >> >> "Within a VWRAP virtual environment, services may be deployed by >> multiple organizations having varying policies and trust domains." >> >> I have always read that as meaning that an inventory could be >> *anywhere* and owned by *anybody*, and that surely covers my own >> client side inventory as well (possibly implemented as a personal >> asset service running on my own machine?) >> >> The decision to have server side inventory is clearly the choice of >> that servers operator, and it is my chose use that inventory if that >> suits me. =C2=A0If client side inventory is superior that will become cl= ear >> by users preferring to use it. I fail to see =C2=A0how our current appro= ach >> is an obstacle on this path. >> >> Can you point out what part of the charter needs to be changed, or >> better make a proposal for that change so we have something concrete >> to work from? >> >> I strongly feel we need to build some consensus in this group, and to >> do so we need to be crystal clear about our aims. We should start >> front be very top. You had a first attempt at restructuring the intro >> document, but we need to address the charter first. My view is that it >> is not yet needed to change that, and if you feel different this is >> the time to say so. >> >> -- Vaughn >> >> On 3/27/11, Morgaine wrote: >> > Indeed, server-side inventories are one of the worst design decisions = of >> > the >> > existing implementations. >> > >> > They give us no end of problems, such as the impossibility of high-spe= ed >> > client-side searching and regular lag issues, not to mention being >> > non-portable because each world provider would implement them >> > differently. >> > They're also non-scalable because they're centralized, and non >> > supportive of >> > VW tourism because a given world provider would control what can be pu= t >> > into >> > them, instead of the traveling user being in control. >> > >> > Inventories need to be client-side (I refer to the trees of asset >> > metadata, >> > not the asset data, in case that's not clear), with an auto sync of >> > deltas >> > to a configured asset service for resilience/backup. =C2=A0That way on= ly >> > those >> > people who do not look after their local inventory resources will suff= er >> > client-server transport lag to recreate them, and the full power of >> > client-side CPUs and client-side databases and scripting can be deploy= ed >> > to >> > make inventories a real powerhouse. >> > >> > All we really need are shared asset services that are independent of t= he >> > world providers. =C2=A0That alone is enough to virtually ensure portab= ility, >> > interoperability, and scalability, as long as a lightweight protocol c= an >> > be >> > found that is also extensible to support tomorrow's worlds. =C2=A0Maki= ng a >> > standard to support only what we're doing today isn't particularly >> > interesting. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > >> > On Sun, Mar 27, 2011 at 2:41 AM, Dzonatas Sol >> > wrote: >> > >> >> If there was focus only on the login (agent domain) and inventory >> >> services, >> >> then I think we will get some where. >> >> >> >> Yes, we know there are issues with inventory that are already in the >> >> simulator side, so this is the suggestion to build apart from those >> >> issues. >> >> Start from there. >> >> >> >> >> >> >> >> Izzy Alanis wrote: >> >> >> >>> Are you suggesting a re-charter around shared services only? >> >>> Or that we shift the deliverables to push that to the forefront? (In >> >>> which case, we still really do need an intro doc and to address the >> >>> messaging semantics) >> >>> >> >>> I'm not quite convinced that the charter is unsalvageable. I think t= he >> >>> last rev of the intro has a lot of good things in it too -- lots I >> >>> would like to see changed, but good stuff too. >> >>> >> >>> >> >>> >> >>> On Sat, Mar 26, 2011 at 8:09 PM, Morgaine >> >>> wrote: >> >>> >> >>> >> >>>> I'm glad to see some renewed participation here!=EF=BF=BD Perhaps t= he threat >> >>>> of >> >>>> death sharpens the mind. ;-) >> >>>> >> >>>> Since there seems to be some fresh thinking in the air, I am going = to >> >>>> add >> >>>> two short points to the discussion.=EF=BF=BD The first is a matter = of >> >>>> procedure, >> >>>> and >> >>>> the second is related to our technical direction: >> >>>> >> >>>> Notwithstanding that the IETF places certain duties on Barry and >> >>>> others >> >>>> to >> >>>> ensure that there is visible progress in the form of documents, I >> >>>> must >> >>>> say >> >>>> that "documents at all costs" is not a particularly good way of >> >>>> achieving >> >>>> technical progress.=EF=BF=BD It's the "documents at all costs" push= that gave >> >>>> us >> >>>> several documents previously, only one of which turned out to be >> >>>> usable >> >>>> for >> >>>> interoperation between VWs.=EF=BF=BD Documents churned out before t= here is >> >>>> agreement >> >>>> on goals and direction are a hindrance to the process, not an >> >>>> indicator >> >>>> of >> >>>> progress, and they waste everyone's time.=EF=BF=BD Progress is cert= ainly not >> >>>> a >> >>>> matter of just putting pen to paper, as has been suggested.=EF=BF= =BD Far from >> >>>> it. >> >>>> First we must agree as a group on how a given protocol is going to >> >>>> meet >> >>>> our >> >>>> goals, and drafts then present that formally with hard technical >> >>>> details >> >>>> added.=EF=BF=BD Done the other way around just results in much angs= t and >> >>>> wasted >> >>>> effort, as happened here. >> >>>> >> >>>> Given the almost unanimous agreement that crystallized around >> >>>> Crista's >> >>>> thread of a few months ago which could be paraphrased as "The VWRAP >> >>>> documents do nothing for interop between virtual worlds", I would >> >>>> like >> >>>> to >> >>>> suggest that instead of continuing to beat the dead horse of OGP th= at >> >>>> we >> >>>> still have on our hands, why don't we focus on delivering something >> >>>> that >> >>>> is >> >>>> actually usable by compatible groups like Opensim and realXtend and >> >>>> iED? >> >>>> There is a nugget of gold at the heart of the VWRAP concept which c= an >> >>>> provide exactly that:=EF=BF=BD the idea of shared asset services, a= nd a >> >>>> protocol >> >>>> for >> >>>> accessing them. >> >>>> >> >>>> There is a huge amount of activity in our sector of the virtual >> >>>> worlds >> >>>> community.=EF=BF=BD There is also no end of interest in interoperat= ion, but >> >>>> the >> >>>> trouble seems to be that each group is rather narrowly focused on >> >>>> their >> >>>> own >> >>>> particular code base.=EF=BF=BD Where I think a group such as ours c= an >> >>>> contribute >> >>>> is >> >>>> by providing a lightweight protocol which is easily used by all, >> >>>> without >> >>>> the >> >>>> previous baggage.=EF=BF=BD Simple problems demand simple solutions,= and while >> >>>> a >> >>>> massively scalable shared asset service is not exactly simple, it i= s >> >>>> nevertheless a lot simpler than the much larger task that we had se= t >> >>>> ourselves previously. >> >>>> >> >>>> Perhaps that would be a good place to start, afresh. >> >>>> >> >>>> >> >>>> Morgaine. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>>> >> >>>> On Wed, Mar 23, 2011 at 8:10 PM, Barry Leiba >> >>>> >> >>>> wrote: >> >>>> >> >>>> >> >>>>> Reminder: If anyone's done anything related to what's below, pleas= e >> >>>>> post here and get some discussion going. =EF=BF=BDThere's still ab= out two >> >>>>> and >> >>>>> a half weeks to get something ready. >> >>>>> >> >>>>> Barry, as chair >> >>>>> >> >>>>> On Sun, Feb 27, 2011 at 1:52 PM, Barry Leiba >> >>>>> >> >>>>> wrote: >> >>>>> >> >>>>> >> >>>>>> On Wed, Jan 19, 2011 at 3:15 PM, Barry Leiba >> >>>>>> >> >>>>>> wrote: >> >>>>>> >> >>>>>> >> >>>>>>> As for timescales, we already started work on a new Intro in >> >>>>>>> October >> >>>>>>>> and >> >>>>>>>> November, as I described in my first email in this thread.=EF= =BF=BD It >> >>>>>>>> was >> >>>>>>>> being >> >>>>>>>> done informally, not as an official draft but as input to a >> >>>>>>>> totally >> >>>>>>>> new >> >>>>>>>> draft.=EF=BF=BD It was not being done as a revision because the= previous >> >>>>>>>> Intro >> >>>>>>>> simply did not meet key requirements for many contributors, as >> >>>>>>>> was >> >>>>>>>> clear >> >>>>>>>> from the group's very intense discussions of September. >> >>>>>>>> >> >>>>>>>> >> >>>>>>> Can you see if you can get it into reasonable shape to introduce >> >>>>>>> publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? >> >>>>>>> =EF=BF=BDThat >> >>>>>>> would give people something concrete to work from. >> >>>>>>> >> >>>>>>> >> >>>>>> I haven't seen any activity on this, so let me repeat this with a >> >>>>>> deadline: >> >>>>>> >> >>>>>> The chairs ask the proponents to please get a new intro document >> >>>>>> into >> >>>>>> reasonable (not final) shape to introduce publicly, and to submit >> >>>>>> it >> >>>>>> as an Internet Draft with a name like >> >>>>>> "draft-SOMEONE-vwrap-intro-00" >> >>>>>> by 10 April (the significance of which will be left for the reade= r >> >>>>>> to >> >>>>>> research, should s/he care to). =EF=BF=BDThere may, of course, be= any >> >>>>>> (reasonable) number of authors listed on the draft, and any one m= ay >> >>>>>> be >> >>>>>> the name chosen to live in the draft name. >> >>>>>> >> >>>>>> If we're not able to do that, I think we need to seriously questi= on >> >>>>>> whether there's enough real energy to continue. >> >>>>>> >> >>>>>> Barry, as chair >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>> _______________________________________________ >> >>>>> 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 mailing list >> >>> vwrap@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/vwrap >> >>> >> >>> >> >>> >> >> >> >> >> >> -- >> >> --- https://twitter.com/Dzonatas_Sol --- >> >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> >> >> >> > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From izzyalanis@gmail.com Sun Mar 27 21:28:18 2011 Return-Path: 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 1E1A83A67D7 for ; Sun, 27 Mar 2011 21:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 JM0+XlmHj5se for ; Sun, 27 Mar 2011 21:28:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 54D723A67C3 for ; Sun, 27 Mar 2011 21:28:16 -0700 (PDT) Received: by fxm15 with SMTP id 15so2582964fxm.31 for ; Sun, 27 Mar 2011 21:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3FRBxPHA+H3fNu/t5v2C6evMgT97C1eh7IlvKRgSC+g=; b=Okcn1HXYn8fLUhuhJi4ncfvCOEmDzInqZb8gUspAaO7CXhJbVJ7WcZc6LpRCnxmQfs CpWrbfCbPpwKGQgQEuBjweBE+2BwfgXpyjbEU1pG5cdSz2FJl3qqJAZ0XOt3lCKY5R5b NPSjtlcMgbDeVEA67JcfguAHqiR3NVomdc8vU= 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 :cc:content-type:content-transfer-encoding; b=oBarLzPSwyOmwUJ0gYruzxLnzl1w0I4vcDOA0TsMT1IHYgbEiHlRICJwENMwQcTKjU W1TOBjVZIws4QUvzyFQ/+WNZDErjzwJvzZDOjosbTj/GVuna7Tcz2ZTAu/YRgrapJxGq SPOWIp6Vjx3cwQvxzUet+6sX/RsJZWHmo3s7U= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr3871755fan.105.1301286593002; Sun, 27 Mar 2011 21:29:53 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Sun, 27 Mar 2011 21:29:52 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Mon, 28 Mar 2011 00:29:52 -0400 Message-ID: From: Izzy Alanis To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 04:28:18 -0000 Forging ahead... Are we commenting on the definitions on the wiki, or in the list? I'm confused about the process now. On Sun, Mar 27, 2011 at 6:49 PM, Vaughn Deluca wr= ote: >> I'd prefer to see this happen at the official working group wiki: >> http://trac.tools.ietf.org/wg/vwrap/trac/wiki > > And that is were it is now. =A0:) > > --Vaughn > > On 3/28/11, Fleep Tuque wrote: >> We've discussed the wiki concept several times and several of us started= a >> wiki some months ago, but Peter reminded us that there is an official wi= ki >> that should be used for these efforts. =A0See his message below. >> >> - 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 >> >> >> ---------- Forwarded message ---------- >> From: Peter Saint-Andre >> Date: Thu, Jan 20, 2011 at 10:04 PM >> Subject: Re: [vwrap] Status and future of the VWRAP working group >> To: vwrap@ietf.org >> >> >> With my area director hat on: >> >> a.) I like the idea of collaborative effort at a wiki. This lowers the >> barriers to entry. A big +1. >> >> b.) I'd prefer to see this happen at the official working group wiki: >> >> =A0 =A0http://trac.tools.ietf.org/wg/vwrap/trac/wiki >> >> The main factor here is the IETF's policy on contributions, a.k.a. "Note >> Well"... >> >> =A0 =A0http://www.ietf.org/about/note-well.html >> >> I am not a lawyer, but I doubt that work happening at a wiki site >> somewhere else is covered under "Note Well". The last thing we want is >> ambiguity about copyrights and patents, so I strongly encourage folks to >> do this work at the Trac URL I posted above. >> >> To request login credentials, go here: >> >> =A0 =A0http://trac.tools.ietf.org/tools/loginmgr/newlogin >> >> Thanks! >> >> Peter >> >> UC Second Life: =A0 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 > From morgaine.dinova@googlemail.com Mon Mar 28 08:27:30 2011 Return-Path: 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 4DD163A6A21 for ; Mon, 28 Mar 2011 08:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 aXd3+N9X6hPd for ; Mon, 28 Mar 2011 08:27:28 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 95A8E3A6943 for ; Mon, 28 Mar 2011 08:27:28 -0700 (PDT) Received: by qwg5 with SMTP id 5so2330180qwg.31 for ; Mon, 28 Mar 2011 08:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=oXxTclrmIKkjZVZfSlvaYEcf+tY0HgZCbFHrbdSdDmI=; b=prN8w4Fh/NM4h5ls+iYjlEnSlR9lzngtVKat8/eyeTRLjKJ2OJvyOz/KD0TsH5bNiO ZydUZ3+MG8iKpKFnkwDWM7wC/T/4kGS7yLL8+08ai9C8qeipIfZShf0cWKeI1fRDg0rw MEE3YoIwroT6XQXG+kxSXGMybFCrEZW1KUTcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SsBoRUbq6UGDDTFfnzZZKMnZKdOcTXlIegQRm7Uwq6F+F0lEIvz5NWHHVWnDQzSliK wDtTMQwekTQm3QbxTyXPHN09J7pxBEIhltuBV/C3Y7fWgBCgXNudOHIEwptupmjnw3gc EhGHZQhxlqjaNpsk9sAm7JHawYeaE/GP+I+Q8= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr1323570qcd.147.1301326144508; Mon, 28 Mar 2011 08:29:04 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Mon, 28 Mar 2011 08:29:03 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Mon, 28 Mar 2011 16:29:03 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0949238049f8c9a04 Cc: Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 15:27:30 -0000 --0016368340c0949238049f8c9a04 Content-Type: text/plain; charset=ISO-8859-1 Barry, is there IETF precedent for a WG that has undergone this particular train of events, namely a major disconnect between its originators' intentions and the WG's expectations of direction? If so, our situation may be slightly easier to handle, since the originators have withdrawn from pressing their case and there appears to be almost no actual dispute remaining in the group. Procedurally though, I really don't know where we stand from the IETF's perspective. We seem to have a common goal now, but if the IETF demands paperwork, we're not there yet because the designs and plans have not been worked out. I'm hoping for flexibility, but acknowledge that flexibility has a limit. That said, reading the IETF Mission Statement leaves no doubt that VW interoperability is right in the middle of the road for the IETF. Can the group be left to work out what needs to be worked out? Morgaine. ================================= On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba wrote: > Hi, Carlo, Vaughn, Izzy, Dzonatas, and everyone else. > I'm glad to see some discussion going. Izzy is right when he says this: > > Of course this all may not matter unless somebody actually addresses > > the underlying issue: That the group needs to start producing documents. > > Indeed. We, the chairs, need to see real progress on the documents... > particularly the introduction document. > > This discussion is a start, and, as I say, I'm pleased to see it, but > it has to turn into real document editing very soon. > > I want to say one other thing: > > > Oops, no I said 'we'... but count me out. I still see the same people > > around here and it's still going to fail just as bad as last time (or, > > as I expected the first time around... some "standard" is going to > > be produced that sucks; and that is either going to be ignored, or > > adopted by a few large "players" who then all get major head aches > > and problems that they can't fix; and in the end it will be the users > > who suffer most from having a bad protocol of course :/. > > Carlo, Meadhbh is still around, thought she (note gender) has given up > the editorship of the documents. Your input is welcome -- encouraged > -- though, of course, if you choose not to participate for whatever > reason, that's your choice. I think choosing not to participate > because some particular person is also participating is a poor choice, > but it's your choice to make. I would like to see you reconsider > that, if you're willing to do the work. > > What I do *not* want to see, and what we won't tolerate, are personal > attacks on any participant here. Do not engage in name-calling, do > not question people's integrity, do not malign the companies they work > for, and do not accuse people of malfeasance because they disagree > with you. If you present your ideas and others agree with what you > say, those ideas will make it forward. That's how we aim to work, > here, and if this working group can continue and make progress, that's > indeed how we'll work. > > So... will we make some progress on the intro document? Can we get > some real discussion on it, and a draft that shows some level of > consensus within the nest few weeks? > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016368340c0949238049f8c9a04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry, is there IETF precedent for a WG that has undergone this particular = train of events, namely a major disconnect between its originators' int= entions and the WG's expectations of direction?

If so, our situa= tion may be slightly easier to handle, since the originators have withdrawn= from pressing their case and there appears to be almost no actual dispute = remaining in the group.=A0 Procedurally though, I really don't know whe= re we stand from the IETF's perspective.=A0 We seem to have a common go= al now, but if the IETF demands paperwork, we're not there yet because = the designs and plans have not been worked out.=A0 I'm hoping for flexi= bility, but acknowledge that flexibility has a limit.

That said, reading the IETF Mission Statement leaves no doubt that VW i= nteroperability is right in the middle of the road for the IETF.=A0 Can the= group be left to work out what needs to be worked out?


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba <barrylei= ba@computer.org> wrote:
Hi, Carlo, Vaughn= , Izzy, Dzonatas, and everyone else.
I'm glad to see some discussion going. =A0Izzy is right when he says th= is:
> Of course this all may not matter unless somebody actually addres= ses
> the underlying issue: That the group needs to start producing document= s.

Indeed. =A0We, the chairs, need to see real progress on the documents= ...
particularly the introduction document.

This discussion is a start, and, as I say, I'm pleased to see it, but it has to turn into real document editing very soon.

I want to say one other thing:

> Oops, no I said 'we'... but count me out. I still see the same= people
> around here and it's still going to fail just as bad as last time = (or,
> as I expected the first time around... some "standard" is go= ing to
> be produced that sucks; and that is either going to be ignored, or
> adopted by a few large "players" who then all get major head= aches
> and problems that they can't fix; and in the end it will be the us= ers
> who suffer most from having a bad protocol of course :/.

Carlo, Meadhbh is still around, thought she (note gender) has given u= p
the editorship of the documents. =A0Your input is welcome -- encouraged
-- though, of course, if you choose not to participate for whatever
reason, that's your choice. =A0I think choosing not to participate
because some particular person is also participating is a poor choice,
but it's your choice to make. =A0I would like to see you reconsider
that, if you're willing to do the work.

What I do *not* want to see, and what we won't tolerate, are personal attacks on any participant here. =A0Do not engage in name-calling, do
not question people's integrity, do not malign the companies they work<= br> for, and do not accuse people of malfeasance because they disagree
with you. =A0If you present your ideas and others agree with what you
say, those ideas will make it forward. =A0That's how we aim to work, here, and if this working group can continue and make progress, that's<= br> indeed how we'll work.

So... will we make some progress on the intro document? =A0Can we get
some real discussion on it, and a draft that shows some level of
consensus within the nest few weeks?

Barry, as chair
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016368340c0949238049f8c9a04-- From vaughn.deluca@gmail.com Mon Mar 28 09:29:41 2011 Return-Path: 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 DBA8328C0F9 for ; Mon, 28 Mar 2011 09:29:41 -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 5yFVKNEDCafi for ; Mon, 28 Mar 2011 09:29:40 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 4D0CB3A6A69 for ; Mon, 28 Mar 2011 09:29:40 -0700 (PDT) Received: by ewy19 with SMTP id 19so1407565ewy.31 for ; Mon, 28 Mar 2011 09:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/pAzsV3mYBfRJrTgBkc0NcbABMT9JdIe9zHoFC/hNtI=; b=OwCAb4JchSFvRZ7gWnocgmPH1JK6jBAlBcACqYRGkTC02i+pTwxJsBoFdGmWaVnLqi AlR87RFmHvXDsMadbnweN4ImUTj8NDKFZVVYSr3Qc85LVLFCWn74oJEC/S8v55U+oITU Qg1qPOaroJrZW2aJne6m/VLWOTPg8zSx6Qf+s= 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 :cc:content-type; b=YPxBOhrN8W/VG3ihna+w1UnTmZH4sk/PNUYtckKP29ogmhYBzkynJTYLlCXvSMSQEO b/Y7uaNp4wZrE5ge5Ui5U1r4bhjV7fgRX7DICufCAmmLOxaGSOFiE3j88i3Uv8kN3Bt3 fFSiiUlmyle0RQbId2WVTz4Q5e0vdGcoUgqDg= MIME-Version: 1.0 Received: by 10.213.15.76 with SMTP id j12mr1864537eba.119.1301329877216; Mon, 28 Mar 2011 09:31:17 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Mon, 28 Mar 2011 09:31:16 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> Date: Mon, 28 Mar 2011 18:31:16 +0200 Message-ID: From: Vaughn Deluca To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 16:29:42 -0000 A wiki is great for documentation, useful for collaborative work, and not so good for discussion. My suggestion would be to put text snippets and proposals on the wiki, post comments and rationale to the list, and update the wiki to reflect the results of the discussion (and possibly some motivation). In principle somebody adding terms and/or text to the wiki should update those terms and text during/after discussion as well, however, i am planning to keep an eye on the synchronisation of wiki and list. --Vaughn On 3/28/11, Izzy Alanis wrote: > Forging ahead... > > Are we commenting on the definitions on the wiki, or in the list? I'm > confused about the process now. > > > On Sun, Mar 27, 2011 at 6:49 PM, Vaughn Deluca > wrote: >>> I'd prefer to see this happen at the official working group wiki: >>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >> >> And that is were it is now. :) >> >> --Vaughn >> >> On 3/28/11, Fleep Tuque wrote: >>> We've discussed the wiki concept several times and several of us started >>> a >>> wiki some months ago, but Peter reminded us that there is an official >>> wiki >>> that should be used for these efforts. See his message below. >>> >>> - 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 >>> >>> >>> ---------- Forwarded message ---------- >>> From: Peter Saint-Andre >>> Date: Thu, Jan 20, 2011 at 10:04 PM >>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>> To: vwrap@ietf.org >>> >>> >>> With my area director hat on: >>> >>> a.) I like the idea of collaborative effort at a wiki. This lowers the >>> barriers to entry. A big +1. >>> >>> b.) I'd prefer to see this happen at the official working group wiki: >>> >>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >>> >>> The main factor here is the IETF's policy on contributions, a.k.a. "Note >>> Well"... >>> >>> http://www.ietf.org/about/note-well.html >>> >>> I am not a lawyer, but I doubt that work happening at a wiki site >>> somewhere else is covered under "Note Well". The last thing we want is >>> ambiguity about copyrights and patents, so I strongly encourage folks to >>> do this work at the Trac URL I posted above. >>> >>> To request login credentials, go here: >>> >>> http://trac.tools.ietf.org/tools/loginmgr/newlogin >>> >>> Thanks! >>> >>> Peter >>> >>> 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 >> > From dzonatas@gmail.com Mon Mar 28 10:31:19 2011 Return-Path: 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 69C7E28C0F7 for ; Mon, 28 Mar 2011 10:31:19 -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 y0w7-OchObqk for ; Mon, 28 Mar 2011 10:31:18 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CA8CA28C0F1 for ; Mon, 28 Mar 2011 10:31:17 -0700 (PDT) Received: by gwb20 with SMTP id 20so1452584gwb.31 for ; Mon, 28 Mar 2011 10:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DvpZKaXdPspS6V06GC0tbJdGCX2rqS61zUvARAxxSHk=; b=cCKGsVcQTd3Dbl2mkohNT59sqGqsD6qUDM3MVgOwUN10b4JBB08g3tFnCgiJ/PJ8/y jedNmcc/NysEyG1llTzm2dodyh/zWnqaEzRsemuwIWwQHsofJaCPzEIBQqviu6Z7/nmI LqiHhiWkziSGyR3YLEvDT5r4E3kQhTPlofwmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=fvB+4JZpPVtgfSaDtyknYDFNZLJEuY9K2bdbLJ3gp/L6Cz1yPP7Uae8M41Ww63fs3m um6DsH7l2hlO0yYYBgK0ccyE8ALL1a87WSuVrhpOKWaiiX/1pjTWsXR4oGXwtRrXKc5F gNlvEszM4t7MB3c5yrJjBDMNLYLLjf4kfFSYE= Received: by 10.43.58.135 with SMTP id wk7mr6893554icb.433.1301333574853; Mon, 28 Mar 2011 10:32:54 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id s1sm3068631iba.24.2011.03.28.10.32.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 10:32:53 -0700 (PDT) Message-ID: <4D90C648.2090406@gmail.com> Date: Mon, 28 Mar 2011 10:32:56 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:31:19 -0000 I'm pretty sure the AWG has left the glossary/defs up on wiki.secondlife.com somewhere. Vaughn Deluca wrote: > A wiki is great for documentation, useful for collaborative work, and > not so good for discussion. > My suggestion would be to put text snippets and proposals on the wiki, > post comments and rationale to the list, and update the wiki to > reflect the results of the discussion (and possibly some motivation). > > In principle somebody adding terms and/or text to the wiki should > update those terms and text during/after discussion as well, however, > i am planning to keep an eye on the synchronisation of wiki and list. > > --Vaughn > > > On 3/28/11, Izzy Alanis wrote: > >> Forging ahead... >> >> Are we commenting on the definitions on the wiki, or in the list? I'm >> confused about the process now. >> >> >> On Sun, Mar 27, 2011 at 6:49 PM, Vaughn Deluca >> wrote: >> >>>> I'd prefer to see this happen at the official working group wiki: >>>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >>>> >>> And that is were it is now. :) >>> >>> --Vaughn >>> >>> On 3/28/11, Fleep Tuque wrote: >>> >>>> We've discussed the wiki concept several times and several of us started >>>> a >>>> wiki some months ago, but Peter reminded us that there is an official >>>> wiki >>>> that should be used for these efforts. See his message below. >>>> >>>> - 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 >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Peter Saint-Andre >>>> Date: Thu, Jan 20, 2011 at 10:04 PM >>>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>> To: vwrap@ietf.org >>>> >>>> >>>> With my area director hat on: >>>> >>>> a.) I like the idea of collaborative effort at a wiki. This lowers the >>>> barriers to entry. A big +1. >>>> >>>> b.) I'd prefer to see this happen at the official working group wiki: >>>> >>>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >>>> >>>> The main factor here is the IETF's policy on contributions, a.k.a. "Note >>>> Well"... >>>> >>>> http://www.ietf.org/about/note-well.html >>>> >>>> I am not a lawyer, but I doubt that work happening at a wiki site >>>> somewhere else is covered under "Note Well". The last thing we want is >>>> ambiguity about copyrights and patents, so I strongly encourage folks to >>>> do this work at the Trac URL I posted above. >>>> >>>> To request login credentials, go here: >>>> >>>> http://trac.tools.ietf.org/tools/loginmgr/newlogin >>>> >>>> Thanks! >>>> >>>> Peter >>>> >>>> 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 > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Mon Mar 28 12:17:05 2011 Return-Path: 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 CF1403A68CF for ; Mon, 28 Mar 2011 12:17:05 -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 XAQeEa9Gbz3f for ; Mon, 28 Mar 2011 12:17:04 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id BAEAD3A67FD for ; Mon, 28 Mar 2011 12:17:03 -0700 (PDT) Received: by eye13 with SMTP id 13so1439020eye.31 for ; Mon, 28 Mar 2011 12:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xn80RAJOJucLycM6dhJFj9jIbMj2T6fqjsRrHadoGpg=; b=AFyFc2APGpiwNJy6gnNQqd+wcBYnaeWczCK8Wy1asA5/lerKZkIPySGAwmbxRRXfBM FlATwrpLfyt3j6pu6AMYW3kqopzBjYeJn9N8LWB7zAH1/N9gBPgXnXlajELO72eZjs8e U5FAvi7qDlme407llzBo45ZQ0Ilrgi5YX6w4g= 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 :cc:content-type; b=tvof9UWTn48fyEQDrLMHsb5kkTRYV4QkmvHlgFJrtcH2WeMfn3GXaybpLINRHV439l dcFBCbmuDKCpqI6bzslzAUp5raXNkasj2ham6azNwtatgRjulJVjDDW/zibRNiD7YS9o ExMVMyQdwtWDvtrPC7M8q3j/oFq6z7Rf8QVUU= MIME-Version: 1.0 Received: by 10.213.8.143 with SMTP id h15mr774770ebh.138.1301339919879; Mon, 28 Mar 2011 12:18:39 -0700 (PDT) Received: by 10.213.110.196 with HTTP; Mon, 28 Mar 2011 12:18:39 -0700 (PDT) In-Reply-To: <4D90C648.2090406@gmail.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <20110327131843.GA15165@alinoe.com> <4D90C648.2090406@gmail.com> Date: Mon, 28 Mar 2011 21:18:39 +0200 Message-ID: From: Vaughn Deluca To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:17:05 -0000 Thanks!, found it here: http://wiki.secondlife.com/wiki/Second_Life_Grid_Glossary I will copy it over. -- Vaughn On 3/28/11, Dzonatas Sol wrote: > I'm pretty sure the AWG has left the glossary/defs up on > wiki.secondlife.com somewhere. > > Vaughn Deluca wrote: >> A wiki is great for documentation, useful for collaborative work, and >> not so good for discussion. >> My suggestion would be to put text snippets and proposals on the wiki, >> post comments and rationale to the list, and update the wiki to >> reflect the results of the discussion (and possibly some motivation). >> >> In principle somebody adding terms and/or text to the wiki should >> update those terms and text during/after discussion as well, however, >> i am planning to keep an eye on the synchronisation of wiki and list. >> >> --Vaughn >> >> >> On 3/28/11, Izzy Alanis wrote: >> >>> Forging ahead... >>> >>> Are we commenting on the definitions on the wiki, or in the list? I'm >>> confused about the process now. >>> >>> >>> On Sun, Mar 27, 2011 at 6:49 PM, Vaughn Deluca >>> wrote: >>> >>>>> I'd prefer to see this happen at the official working group wiki: >>>>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >>>>> >>>> And that is were it is now. :) >>>> >>>> --Vaughn >>>> >>>> On 3/28/11, Fleep Tuque wrote: >>>> >>>>> We've discussed the wiki concept several times and several of us >>>>> started >>>>> a >>>>> wiki some months ago, but Peter reminded us that there is an official >>>>> wiki >>>>> that should be used for these efforts. See his message below. >>>>> >>>>> - 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 >>>>> >>>>> >>>>> ---------- Forwarded message ---------- >>>>> From: Peter Saint-Andre >>>>> Date: Thu, Jan 20, 2011 at 10:04 PM >>>>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>>> To: vwrap@ietf.org >>>>> >>>>> >>>>> With my area director hat on: >>>>> >>>>> a.) I like the idea of collaborative effort at a wiki. This lowers the >>>>> barriers to entry. A big +1. >>>>> >>>>> b.) I'd prefer to see this happen at the official working group wiki: >>>>> >>>>> http://trac.tools.ietf.org/wg/vwrap/trac/wiki >>>>> >>>>> The main factor here is the IETF's policy on contributions, a.k.a. >>>>> "Note >>>>> Well"... >>>>> >>>>> http://www.ietf.org/about/note-well.html >>>>> >>>>> I am not a lawyer, but I doubt that work happening at a wiki site >>>>> somewhere else is covered under "Note Well". The last thing we want is >>>>> ambiguity about copyrights and patents, so I strongly encourage folks >>>>> to >>>>> do this work at the Trac URL I posted above. >>>>> >>>>> To request login credentials, go here: >>>>> >>>>> http://trac.tools.ietf.org/tools/loginmgr/newlogin >>>>> >>>>> Thanks! >>>>> >>>>> Peter >>>>> >>>>> 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 >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > From ohmeadhbh@gmail.com Mon Mar 28 12:51:27 2011 Return-Path: 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 7911E3A68FA for ; Mon, 28 Mar 2011 12:51:27 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 WunWKPG4AMaV for ; Mon, 28 Mar 2011 12:51:26 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3B2CE3A68F2 for ; Mon, 28 Mar 2011 12:51:26 -0700 (PDT) Received: by iwn39 with SMTP id 39so3967980iwn.31 for ; Mon, 28 Mar 2011 12:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YPWYtQqltBxnt11aoYBeEDU6AQdH9l2b1URdn8+FqHE=; b=qAlW5NsfGTwKnXs7LBu8Gg6OSXfEXWf8pf8d2youUCe3KAqP7e30dF9jlODauFd+90 1upu9J+6ctsjRNQqioWcVg+oU793ZkEZJ8zbgcwfpIKSU6UTmBQy5zvc4u9KgUGK7elq ZfbX/2NYEfA1evaOY1L0ZiBOBeH2xog0jLo/c= 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 :cc:content-type; b=j1dG547iQZ0gUcY92cErbY6bgOLHhz++c1hKLtOarb6VldO3Xf4I//k3okePlEoZ40 X/Xd12tP/WJDFUEJi+Z+EWWSanWOga7dnPK8ORU2Degzf9bcNlG8yNG4ClZBdaoCQ+CF hm9snUGdgdPv+ENMOUQLis76Giq3vAS/mjhmM= MIME-Version: 1.0 Received: by 10.42.175.68 with SMTP id az4mr7548390icb.205.1301341983758; Mon, 28 Mar 2011 12:53:03 -0700 (PDT) Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 12:53:03 -0700 (PDT) Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 12:53:03 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Mon, 28 Mar 2011 12:53:03 -0700 Message-ID: From: Meadhbh Hamrick To: Morgaine Content-Type: multipart/alternative; boundary=90e6ba6e8f9aac596e049f904a94 Cc: vwrap@ietf.org, Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 19:51:27 -0000 --90e6ba6e8f9aac596e049f904a94 Content-Type: text/plain; charset=ISO-8859-1 Um. Morgaine. You don't get to define the wg's expectation or direction. As a member of this wg (and someone who's actually written code related to it's problem domain) I would like to be included in the development of this group's consensus. On Mar 28, 2011 8:29 AM, "Morgaine" wrote: Barry, is there IETF precedent for a WG that has undergone this particular train of events, namely a major disconnect between its originators' intentions and the WG's expectations of direction? If so, our situation may be slightly easier to handle, since the originators have withdrawn from pressing their case and there appears to be almost no actual dispute remaining in the group. Procedurally though, I really don't know where we stand from the IETF's perspective. We seem to have a common goal now, but if the IETF demands paperwork, we're not there yet because the designs and plans have not been worked out. I'm hoping for flexibility, but acknowledge that flexibility has a limit. That said, reading the IETF Mission Statement leaves no doubt that VW interoperability is right in the middle of the road for the IETF. Can the group be left to work out what needs to be worked out? Morgaine. ================================= On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba wrote: > > Hi, Carlo, Vaugh... _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap --90e6ba6e8f9aac596e049f904a94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Um. Morgaine. You don't get to define the wg's expectation or di= rection. As a member of this wg (and someone who's actually written cod= e related to it's problem domain) I would like to be included in the de= velopment of this group's consensus.

On Mar 28, 2011 8:29 AM, "Morgaine" = <morgaine.dinova@googl= email.com> wrote:

Barry, is there IETF precedent for a WG tha= t has undergone this particular train of events, namely a major disconnect = between its originators' intentions and the WG's expectations of di= rection?

If so, our situation may be slightly easier to handle, since the origin= ators have withdrawn from pressing their case and there appears to be almos= t no actual dispute remaining in the group.=A0 Procedurally though, I reall= y don't know where we stand from the IETF's perspective.=A0 We seem= to have a common goal now, but if the IETF demands paperwork, we're no= t there yet because the designs and plans have not been worked out.=A0 I= 9;m hoping for flexibility, but acknowledge that flexibility has a limit.
That said, reading the IETF Mission Statement leaves no doubt that VW i= nteroperability is right in the middle of the road for the IETF.=A0 Can the= group be left to work out what needs to be worked out?


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba <barryleiba@computer.org> wrote= :
>
> Hi, Carlo, Vaugh...


____________________________= ___________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--90e6ba6e8f9aac596e049f904a94-- From morgaine.dinova@googlemail.com Mon Mar 28 14:14:16 2011 Return-Path: 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 3D4A628C104 for ; Mon, 28 Mar 2011 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 0Z2FeiCEIVaY for ; Mon, 28 Mar 2011 14:14:14 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5B69128C0F0 for ; Mon, 28 Mar 2011 14:14:14 -0700 (PDT) Received: by qwg5 with SMTP id 5so2587341qwg.31 for ; Mon, 28 Mar 2011 14:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=yiBDVrZPvEC+kQitjytJKRhppIwIr/vCseCEFCKuRfE=; b=iMoUVekO7rpRR6xsgQDMhuxAgcgSuMCJyWSUQ6t68Z224FwOCvuDaoRd4TN6YiVz7H ItkpP7bHsMA2hVvaAQKV3F4uCFTE5/071c/OVExUeNGTGnsZ09apn+5DZUbV2XIxWV2P 7nweLi/bSbaU4p4OGnEYJcqnPGOPYcfWmcUCI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=YR8w2/ifFrRD/yEhYOpSHVb88R35v58YlXGopaQ39urECNmS/mUy68m6X3kr7IwSGs O3B550H4z2Tu+Xz6er+7ADZwZo4zS61wMEfyxkGEcrfCUottpyPJds4GcM7Y9e7E5kQw N0Xn3abgxlzYx8RGe3SL2O8auhGNam/Vw7Rbk= MIME-Version: 1.0 Received: by 10.224.8.208 with SMTP id i16mr3888943qai.222.1301346951562; Mon, 28 Mar 2011 14:15:51 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Mon, 28 Mar 2011 14:15:51 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> Date: Mon, 28 Mar 2011 22:15:51 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=bcaec51b15f5c706c5049f917274 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:14:16 -0000 --bcaec51b15f5c706c5049f917274 Content-Type: text/plain; charset=ISO-8859-1 The group's expectation of direction was already manifest at the time of Crista's intervention a few months ago, at which time it was unanimous that everybody except one person was seeking interoperation between virtual worlds as a primary requirement and as a key motivation for the group's work. The dissenting opinion was clearly, if unofficially, outvoted by to 1. If that direction is *STILL* not accepted by everyone in the WG, I shall ask Barry to formally call a count of votes and establish the rough consensus officially. Without this we will be perpetually disrupted by a non-representative minority pulling in the opposite direction to the rest of the group. Morgaine. ======================== On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick wrote: > Um. Morgaine. You don't get to define the wg's expectation or direction. As > a member of this wg (and someone who's actually written code related to it's > problem domain) I would like to be included in the development of this > group's consensus. > > On Mar 28, 2011 8:29 AM, "Morgaine" > wrote: > > Barry, is there IETF precedent for a WG that has undergone this particular > train of events, namely a major disconnect between its originators' > intentions and the WG's expectations of direction? > > If so, our situation may be slightly easier to handle, since the > originators have withdrawn from pressing their case and there appears to be > almost no actual dispute remaining in the group. Procedurally though, I > really don't know where we stand from the IETF's perspective. We seem to > have a common goal now, but if the IETF demands paperwork, we're not there > yet because the designs and plans have not been worked out. I'm hoping for > flexibility, but acknowledge that flexibility has a limit. > > That said, reading the IETF Mission Statement leaves no doubt that VW > interoperability is right in the middle of the road for the IETF. Can the > group be left to work out what needs to be worked out? > > > Morgaine. > > > > > ================================= > > > > On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba > wrote: > > > > Hi, Carlo, Vaugh... > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --bcaec51b15f5c706c5049f917274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The group's expectation of direction was already manifest at the time o= f Crista's intervention a few months ago, at which time it was unanimou= s that everybody except one person was seeking interoperation between virtu= al worlds as a primary requirement and as a key motivation for the group= 9;s work.

The dissenting opinion was clearly, if unofficially, outvoted by <co= unt of group members> to 1.=A0 If that direction is STILL = not accepted by everyone in the WG, I shall ask Barry to formally call a co= unt of votes and establish the rough consensus officially.=A0 Without this = we will be perpetually disrupted by a non-representative minority pulling i= n the opposite direction to the rest of the group.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On M= on, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:

Um. Morgaine. = You don't get to define the wg's expectation or direction. As a mem= ber of this wg (and someone who's actually written code related to it&#= 39;s problem domain) I would like to be included in the development of this= group's consensus.

On Mar 28, 2011 8:29 AM,= "Morgaine" <morgaine.dinova@googlemail.com> wrote:

Bar= ry, is there IETF precedent for a WG that has undergone this particular tra= in of events, namely a major disconnect between its originators' intent= ions and the WG's expectations of direction?

If so, our situation may be slightly easier to handle, since the origin= ators have withdrawn from pressing their case and there appears to be almos= t no actual dispute remaining in the group.=A0 Procedurally though, I reall= y don't know where we stand from the IETF's perspective.=A0 We seem= to have a common goal now, but if the IETF demands paperwork, we're no= t there yet because the designs and plans have not been worked out.=A0 I= 9;m hoping for flexibility, but acknowledge that flexibility has a limit.
That said, reading the IETF Mission Statement leaves no doubt that VW i= nteroperability is right in the middle of the road for the IETF.=A0 Can the= group be left to work out what needs to be worked out?


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



On Sat, Mar 26, 2011 at 2:40 P= M, Barry Leiba <barryleiba@computer.org> wrote:
>
> Hi, Carlo, Vaugh...


____= ___________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--bcaec51b15f5c706c5049f917274-- From billwindwalker@gmail.com Mon Mar 28 14:43:35 2011 Return-Path: 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 96E8B28C12C for ; Mon, 28 Mar 2011 14:43:35 -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 WyedynoTfDxl for ; Mon, 28 Mar 2011 14:43:34 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id ADB5E28C122 for ; Mon, 28 Mar 2011 14:43:34 -0700 (PDT) Received: by yxk30 with SMTP id 30so1552893yxk.31 for ; Mon, 28 Mar 2011 14:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:x-rim-org-msg-ref-id:message-id:reply-to :x-priority:sensitivity:importance:to:subject:from:date:content-type :mime-version; bh=4qoA5kfjwEm0NwUQEC/gr79DIGKy56Rdx1Kdh2coaMM=; b=PXYBNvevtitROs8zgl1EAa1pKE6NUrucbuUXrsyQjMZWK8pqAdqfiUhKxq+kwRuc2D O7tOExCBmabPC8pDLVj33EwLdZXSocaXjeKpu9dl4L8dW833Kwj1DlxoxJiGnLO7+h1C YNn4Jma7E3CJppEygJUd2E9kAGlzAbbpWxzZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-rim-org-msg-ref-id:message-id:reply-to:x-priority:sensitivity :importance:to:subject:from:date:content-type:mime-version; b=YTOkIXeIRLWMvPWF0na3Qx0hq9fmJVYAa7TB3Js2MFLEfvAl4JBZTqss4Wpx3aD+Fw 4OFXruApDx/lnbtOqdH7Vxs7dypMPbqnexlvhn/9kupAh5qZ7ysDZMegMZTtsQXIqgg3 7mnkitmnZczR88BoUwfy8whmU3vMeGCJBCR+w= Received: by 10.236.102.131 with SMTP id d3mr1978567yhg.174.1301348712244; Mon, 28 Mar 2011 14:45:12 -0700 (PDT) Received: from bda231.bisx.prod.on.blackberry (bda-67-223-67-141.bise.na.blackberry.com [67.223.67.141]) by mx.google.com with ESMTPS id 23sm2143788yhl.101.2011.03.28.14.45.10 (version=SSLv3 cipher=OTHER); Mon, 28 Mar 2011 14:45:11 -0700 (PDT) X-rim-org-msg-ref-id: 1168935690 Message-ID: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> X-Priority: Normal Sensitivity: Normal Importance: Normal To: vwrap@ietf.org From: billwindwalker@gmail.com Date: Mon, 28 Mar 2011 21:45:08 +0000 Content-Type: text/plain MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 28 Mar 2011 15:32:57 -0700 Subject: [vwrap] Open sim X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: billwindwalker@gmail.com List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 21:45:09 -0000 Is it not time to think of v worlds like opensim and work with for it has more to offer then a game like sl now has. Even how the robus assets works can be used in better ways then it is. Opensim has greater power to be used as a archive meta data base then sl has. Its time to look at other platforms as what they have to offer. Sent from my Verizon Wireless BlackBerry From dzonatas@gmail.com Mon Mar 28 15:44:24 2011 Return-Path: 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 466883A6A83 for ; Mon, 28 Mar 2011 15:44:24 -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 JyYAjV+vMrvq for ; Mon, 28 Mar 2011 15:44:23 -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 2DBC23A6948 for ; Mon, 28 Mar 2011 15:44:23 -0700 (PDT) Received: by iye19 with SMTP id 19so4092146iye.31 for ; Mon, 28 Mar 2011 15:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=J+1euNx17+CR+sBb53YPbhMxQl+jP603XhG3PYZot4c=; b=Bxh+IrYQca87ruzKN3Bv31LrE1rWJR75dFAmYq8Wvz44fH4aIuEx+fOG1a4suZRiZ7 P3MDtPpfK/73mJptQ2dhqpimUc7fctwVdxUjhtTlkZl4e1ZFdkmFtC58FP63PERo3UgS urNTRSlL15ERD678us5quEMWi1BpMfwU7XXeg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ASSVV2t3l4p17SGx8KaK2C2tJtiagzr1blFxSCtPUmlV2L9JVQptKXodGvCcBcr4Qj hN9iNxdwseo0blkPyJAojRmPvKQnoaFpIpJBtC7kB5LGkhclYmx4pPK2s1ZoM4i+fTMW Yu5a2Yslr0pLQGqyE7dcwpdeCAEyRKrKf2biU= Received: by 10.231.26.87 with SMTP id d23mr4891625ibc.18.1301352360850; Mon, 28 Mar 2011 15:46:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id hc41sm1658555ibb.47.2011.03.28.15.45.59 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 15:45:59 -0700 (PDT) Message-ID: <4D910FAB.9070402@gmail.com> Date: Mon, 28 Mar 2011 15:46:03 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: billwindwalker@gmail.com References: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> In-Reply-To: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Open sim X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:44:24 -0000 Can we stay on the subject of assets and assets services, asset sharing, object manufacturers, assets hosts, local inventory, and etc before the topic is taken back another 2 years. Thanks. As for simulator side, there are many besides open sim, from simple and to far advanced, so that is not immediate discussion.Documentation is on call... billwindwalker@gmail.com wrote: > Is it not time to think of v worlds like opensim and work with for it has more to offer then a game like sl now has. > Even how the robus assets works can be used in better ways then it is. > Opensim has greater power to be used as a archive meta data base then sl has. > Its time to look at other platforms as what they have to offer. > > Sent from my Verizon Wireless BlackBerry > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From ohmeadhbh@gmail.com Mon Mar 28 15:45:16 2011 Return-Path: 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 1426D28C13E for ; Mon, 28 Mar 2011 15:45:16 -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=[AWL=0.000, 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 QkxNT8f+IL3K for ; Mon, 28 Mar 2011 15:45:14 -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 8759228C138 for ; Mon, 28 Mar 2011 15:45:12 -0700 (PDT) Received: by iye19 with SMTP id 19so4092782iye.31 for ; Mon, 28 Mar 2011 15:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IKcGpPkXHpB8nCRKGN4+tvoR81z9U+s8N8vvSd9Xv9U=; b=dJNB3iD4bcjyvAlFNJTMw5o/pW/GjrD8xtXsRUGGuFuKSVSNT9aNrEsmwSl6tLoElV XXUWC+oVdwPssZKmSrpdI8NvUrZezdxTutRzaehzJJwrb+yNXEoKR8B5kXFWC3h+LcpY mK9HAJCOWBVvgsqt/hoqEWNo/0AYAZUttReZg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=P+eV4U16hqTy6toUOo9AaM8mtp7SiKpsLUWfiPvLyh4e3XlLB3J+WMHrY9RbkJVEKg NOdaffkr4xcVUQNDP8ptJOZEZcdLbQmAFHLUNCi6z+wfUBboaeVCCZ1WTXAGwZXMgLO6 9Z0fOg/I82H79yji2l+H7oYksKAh5+94mcMoI= Received: by 10.42.175.68 with SMTP id az4mr7819856icb.205.1301352410095; Mon, 28 Mar 2011 15:46:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 15:46:30 -0700 (PDT) In-Reply-To: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> References: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> From: Meadhbh Hamrick Date: Mon, 28 Mar 2011 15:46:30 -0700 Message-ID: To: billwindwalker@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] Open sim X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:45:16 -0000 that's great, but someone has to: a. start writing a new charter and/or b. start writing a few new drafts there are better places to do pure research or to bless HyperGrid's current protocol. the existing charter of this group says we're going to produce documents for service level interoperability. it then goes on to list them. if, as a group, we want to continue this course of action, then someone needs to step up and take ownership of the documents in the repository and modify them so they reflect group consensus. if, as a group, we want to work on new documents. we need to say, as a group, "we want to work on new documents" and list what those documents will attempt to document and then maybe a list of documents. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Mar 28, 2011 at 2:45 PM, wrote: > Is it not time to think of v worlds like opensim and work with for it has more to offer then a game like sl now has. > Even how the robus assets works can be used in better ways then it is. > Opensim has greater power to be used as a archive meta data base then sl has. > Its time to look at other platforms as what they have to offer. > > Sent from my Verizon Wireless BlackBerry > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Mon Mar 28 15:48:24 2011 Return-Path: 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 9442728C138 for ; Mon, 28 Mar 2011 15:48:24 -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=[AWL=0.000, 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 quChLCUIAFZK for ; Mon, 28 Mar 2011 15:48:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6D52D3A6A90 for ; Mon, 28 Mar 2011 15:48:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so4132225iwn.31 for ; Mon, 28 Mar 2011 15:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aDQsI+YUrmjXiwSX2zl9keokEGDadTyPmlkX/sdtoeM=; b=fxrDhXX/tGFvf5QuTKAfZFUwsY5mLrkTlw8Kff6GoLuzYvbpxba8Ejr0fbSHhIG9zX W7BjVcuEPBYXGuf4fSEcvl6yubTnQgL5cDF2pZIESEL3XB5yJCIhlccbAiWC+kAVi498 MC4s212pdxcCswvnE/JpcaGQYSd/gwu4r9Dq4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=UeUo9P5aHorcTDP+wDRVvgDtcz0yj4aijTjur5u/hSGaYfeOVCvWZZu0nZl83wB/Ml kBUaGHNRlrH+LQHlsvwEpLinrx1GEhwcTPkDapZZOBQl1yHVtblwSwyFUCakqZmVQJRK y/GP3aQ1tt5VZo4bhMgAIO+SDi/ZKGRw2DIUg= Received: by 10.43.52.195 with SMTP id vn3mr8076182icb.272.1301352601098; Mon, 28 Mar 2011 15:50:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 15:49:41 -0700 (PDT) In-Reply-To: <4D910FAB.9070402@gmail.com> References: <1168935690-1301348708-cardhu_decombobulator_blackberry.rim.net-1179595096-@bda2715.bisx.prod.on.blackberry> <4D910FAB.9070402@gmail.com> From: Meadhbh Hamrick Date: Mon, 28 Mar 2011 15:49:41 -0700 Message-ID: To: Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Cc: billwindwalker@gmail.com, vwrap@ietf.org Subject: Re: [vwrap] Open sim X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:48:24 -0000 so.. Dzonatas is interested in service level interoperability. Morgaine is interested in "virtual world interoperability." is there consensus as to what this group wants to do? if so, we should state what that consensus is. while i appreciate the effort people are making to document things in the wiki, the clock is ticking and we really should pick an objective and start expending effort to move in that direction. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Mar 28, 2011 at 3:46 PM, Dzonatas Sol wrote: > Can we stay on the subject of assets and assets services, asset sharing, > object manufacturers, assets hosts, local inventory, and etc before the > topic is taken back another 2 years. Thanks. > > As for simulator side, there are many besides open sim, from simple and to > far advanced, so that is not immediate discussion.Documentation is on > call... > > billwindwalker@gmail.com wrote: >> >> Is it not time to think of v worlds like opensim and work with for it has >> more to offer then a game like sl now has. >> Even how the robus assets works can be used in better ways then it is. >> Opensim has greater power to be used as a archive meta data base then sl >> has. >> Its time to look at other platforms as what they have to offer. >> >> Sent from my Verizon Wireless BlackBerry >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From ohmeadhbh@gmail.com Mon Mar 28 15:50:34 2011 Return-Path: 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 D21483A6A96 for ; Mon, 28 Mar 2011 15:50:34 -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=[AWL=0.000, 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 F4eYI8ROna4U for ; Mon, 28 Mar 2011 15:50:33 -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 788A83A6A90 for ; Mon, 28 Mar 2011 15:50:33 -0700 (PDT) Received: by iye19 with SMTP id 19so4097151iye.31 for ; Mon, 28 Mar 2011 15:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=N8YBI3IA4P4cd/SM616VVLAzLKSin1L/MDJVSM0dmb8=; b=jOvO82XOUKJEAe4yQKotwmlflytZxc6SODilyHBFHOWBLVNDF/qrOeH/1PNH5RIgfm hEzwssj1hlJWm1T7cbLmhFw5vRpJ0TmUO/j9hqH39H9jsiOTdhqcL7HFQJHKdrvl4ihO Ygzl0y95eLKOxwFrrH3AMtAxEyrevAxib+eDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ffYZkuR1e+17ymUeJ0Ju4o9R1fDftdDFF7XJpV6wdLA5hJ+fMhVufsZb7/1OW+15Rs F6HzbBqtGc9jwpSl+n3blrqyeYBi7WDaH41xO12CQ0hiQdH89fwUYADv44TBHrwU+j3h NLd7UHZpV0wMXNOdyU7+v35Y9oL7fHaVHrKUw= Received: by 10.42.29.202 with SMTP id s10mr7280190icc.4.1301352731126; Mon, 28 Mar 2011 15:52:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 15:51:51 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> From: Meadhbh Hamrick Date: Mon, 28 Mar 2011 15:51:51 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:50:34 -0000 if there is consensus in our objectives. can we then recharter or form a ne= w WG? also. what was this consensus that you assert i agreed to? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Mar 28, 2011 at 2:15 PM, Morgaine wrote: > The group's expectation of direction was already manifest at the time of > Crista's intervention a few months ago, at which time it was unanimous th= at > everybody except one person was seeking interoperation between virtual > worlds as a primary requirement and as a key motivation for the group's > work. > > The dissenting opinion was clearly, if unofficially, outvoted by group members> to 1.=A0 If that direction is STILL not accepted by everyo= ne in > the WG, I shall ask Barry to formally call a count of votes and establish > the rough consensus officially.=A0 Without this we will be perpetually > disrupted by a non-representative minority pulling in the opposite direct= ion > to the rest of the group. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick > wrote: >> >> Um. Morgaine. You don't get to define the wg's expectation or direction. >> As a member of this wg (and someone who's actually written code related = to >> it's problem domain) I would like to be included in the development of t= his >> group's consensus. >> >> On Mar 28, 2011 8:29 AM, "Morgaine" >> wrote: >> >> Barry, is there IETF precedent for a WG that has undergone this particul= ar >> train of events, namely a major disconnect between its originators' >> intentions and the WG's expectations of direction? >> >> If so, our situation may be slightly easier to handle, since the >> originators have withdrawn from pressing their case and there appears to= be >> almost no actual dispute remaining in the group.=A0 Procedurally though,= I >> really don't know where we stand from the IETF's perspective.=A0 We seem= to >> have a common goal now, but if the IETF demands paperwork, we're not the= re >> yet because the designs and plans have not been worked out.=A0 I'm hopin= g for >> flexibility, but acknowledge that flexibility has a limit. >> >> That said, reading the IETF Mission Statement leaves no doubt that VW >> interoperability is right in the middle of the road for the IETF.=A0 Can= the >> group be left to work out what needs to be worked out? >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba >> wrote: >> > >> > Hi, Carlo, Vaugh... >> >> _______________________________________________ >> 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 > > From ohmeadhbh@gmail.com Mon Mar 28 15:57:01 2011 Return-Path: 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 7112F3A6A96 for ; Mon, 28 Mar 2011 15:57:01 -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=[AWL=0.000, 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 klCHMdbMKlq5 for ; Mon, 28 Mar 2011 15:56:59 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 87A843A68DF for ; Mon, 28 Mar 2011 15:56:59 -0700 (PDT) Received: by iwn39 with SMTP id 39so4139555iwn.31 for ; Mon, 28 Mar 2011 15:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=luvXAwCQxgmFy2wLjrXid7t4veqTUvQGR0YgNDNl7mY=; b=vZ44AOVfJ/53GIJ8uuMA3YRIqzkcMLlsZUU/y+VJV5LxB0RaTzh5f9ZrcP99u9GHCf DP3dj2bXbAMCVc1KUDmBi8WoLqGPBGJlpPsuAeTFso3VWe0AZJcmuutreACSRSpttd9Y 8N2jKpoe6qDM4krV021pl5J0BwYClIWh0tDAM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=dWJzIxheJvIbSmW/H1MFwmsRvlKPNcgTjSo9F2xpH6Jbbr/n6lZWt3wgwlc3V+ZdQK 2tx84qglG4A3jpiFrzwI5m/X+CMYWHY3pLQzbBoPSeCIC0kKQYHFVhlE8dFOyfHsSa4+ g+ufs9Ig7UQHOIoCYSJ9d+iCK4m1+ADU0RX4I= Received: by 10.43.66.5 with SMTP id xo5mr2186661icb.71.1301353117105; Mon, 28 Mar 2011 15:58:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 15:58:16 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> From: Meadhbh Hamrick Date: Mon, 28 Mar 2011 15:58:16 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 22:57:01 -0000 in other words, what does "interoperation between virtual worlds" mean? the "service level interoperability" was sufficiently defined such that i could (and did) go out and write code to demonstrably implement the specification. does the term "interoperation between virtual worlds" mean: a. interoperability between any two existing virtual world or MMO systems? (i.e. - between second life and world of warcraft?) b. interoperability between second life, second life / enterprise or OpenSIm instances? or c. interoperability between two OpenSim instances? if a or b, do we have any interest from any of the implementers of those systems to adhere to an IETF standard? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Mar 28, 2011 at 2:15 PM, Morgaine wrote: > The group's expectation of direction was already manifest at the time of > Crista's intervention a few months ago, at which time it was unanimous th= at > everybody except one person was seeking interoperation between virtual > worlds as a primary requirement and as a key motivation for the group's > work. > > The dissenting opinion was clearly, if unofficially, outvoted by group members> to 1.=A0 If that direction is STILL not accepted by everyo= ne in > the WG, I shall ask Barry to formally call a count of votes and establish > the rough consensus officially.=A0 Without this we will be perpetually > disrupted by a non-representative minority pulling in the opposite direct= ion > to the rest of the group. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick > wrote: >> >> Um. Morgaine. You don't get to define the wg's expectation or direction. >> As a member of this wg (and someone who's actually written code related = to >> it's problem domain) I would like to be included in the development of t= his >> group's consensus. >> >> On Mar 28, 2011 8:29 AM, "Morgaine" >> wrote: >> >> Barry, is there IETF precedent for a WG that has undergone this particul= ar >> train of events, namely a major disconnect between its originators' >> intentions and the WG's expectations of direction? >> >> If so, our situation may be slightly easier to handle, since the >> originators have withdrawn from pressing their case and there appears to= be >> almost no actual dispute remaining in the group.=A0 Procedurally though,= I >> really don't know where we stand from the IETF's perspective.=A0 We seem= to >> have a common goal now, but if the IETF demands paperwork, we're not the= re >> yet because the designs and plans have not been worked out.=A0 I'm hopin= g for >> flexibility, but acknowledge that flexibility has a limit. >> >> That said, reading the IETF Mission Statement leaves no doubt that VW >> interoperability is right in the middle of the road for the IETF.=A0 Can= the >> group be left to work out what needs to be worked out? >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba >> wrote: >> > >> > Hi, Carlo, Vaugh... >> >> _______________________________________________ >> 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 > > From dzonatas@gmail.com Mon Mar 28 16:11:52 2011 Return-Path: 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 08B4A28C0E7 for ; Mon, 28 Mar 2011 16:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_BACKHAIR_11=1, 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 rD8icTjGE9l9 for ; Mon, 28 Mar 2011 16:11:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 92FE33A6A96 for ; Mon, 28 Mar 2011 16:11:50 -0700 (PDT) Received: by iwn39 with SMTP id 39so4151438iwn.31 for ; Mon, 28 Mar 2011 16:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=49BZvU0t5rA50wD0KAUUMduZwxHgDZA69QY+777RpTs=; b=qgwu+lc0UNBXouM1DLIGZPxdZyE53BDyqitRFleZoTcNRfvKnBGDfmiOZFQkc+Hxqn k9LSv1An5pLcsQy3nrx1hm5AawQPa3bbZVKNeNhNhU743jW77unluNTDnmgbf5V2oNGd tXdx5Rrtt0hu3JDKeFUX0/ond9DR4Uz/rl1g8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZYmRvm9A6ge7KyJ81OfAwIEmUF+32lwu8SL50dbtSDP1rWyG0rUBiku6uR1RaV0upx oiqveKs/US8U56UkJlZp91kudHOiHQbvyd201INqBC7IICi+V/lYnRev6HiPtODS0u9E Hxnj+1pHTv2XXpcC4xeoij701Hy84GohUiCmE= Received: by 10.43.58.14 with SMTP id wi14mr7585008icb.396.1301354006446; Mon, 28 Mar 2011 16:13:26 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm3223298ibb.56.2011.03.28.16.13.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 16:13:25 -0700 (PDT) Message-ID: <4D911618.7060706@gmail.com> Date: Mon, 28 Mar 2011 16:13:28 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:11:52 -0000 If you want service only, I think there is code implemented already. We need the ability for people to own their assets on their own local site (and further simulate them with their own local simulator, for like opening inventory in looking at the puzzle pieces). There has been much debate about client/server and exactly what that means. Given that even X11 defines client/server backwords from the VWinterop concept now, it is a hard battle to people's mind to bend one way or another in terminology. I think the progress to define multi-point on either client or service side was finally a start to see the bigger picture easier. Being able to start up separate client side programs is at issue that breaks away from the monolithic design. There are some that want to stay with the monolithic design purely for revenue reasons. I need not mention whom. This causes the main bottleneck from the client-side developer. If we define server side in such way, and let server-side people "ban" client-side developers because it doesn't fit their motif, then there is no equality in vote in this working group. I hope we can remedy at least this in any "interoperation". I think it would be easiest to consider the DAE (collada) format as an example. Allow one client to start up (point A), and allow another client to start up (point B), and allows these to clients to contant an agent domain to transfer DAE files back and forth between inventory without any region simulators. This A<->B path needs to be in the "service level interoperability". This may seem like simple file transfer, so be it. Meadhbh Hamrick wrote: > in other words, what does "interoperation between virtual worlds" mean? > > the "service level interoperability" was sufficiently defined such > that i could (and did) go out and write code to demonstrably implement > the specification. does the term "interoperation between virtual > worlds" mean: > > a. interoperability between any two existing virtual world or MMO > systems? (i.e. - between second life and world of warcraft?) > > b. interoperability between second life, second life / enterprise or > OpenSIm instances? > > or > > c. interoperability between two OpenSim instances? > > if a or b, do we have any interest from any of the implementers of > those systems to adhere to an IETF standard? > > -cheers > -meadhbh > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Mon, Mar 28, 2011 at 2:15 PM, Morgaine > wrote: > >> The group's expectation of direction was already manifest at the time of >> Crista's intervention a few months ago, at which time it was unanimous that >> everybody except one person was seeking interoperation between virtual >> worlds as a primary requirement and as a key motivation for the group's >> work. >> >> The dissenting opinion was clearly, if unofficially, outvoted by > group members> to 1.� If that direction is STILL not accepted by everyone in >> the WG, I shall ask Barry to formally call a count of votes and establish >> the rough consensus officially.� Without this we will be perpetually >> disrupted by a non-representative minority pulling in the opposite direction >> to the rest of the group. >> >> >> Morgaine. >> >> >> >> >> ======================== >> >> On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick >> wrote: >> >>> Um. Morgaine. You don't get to define the wg's expectation or direction. >>> As a member of this wg (and someone who's actually written code related to >>> it's problem domain) I would like to be included in the development of this >>> group's consensus. >>> >>> On Mar 28, 2011 8:29 AM, "Morgaine" >>> wrote: >>> >>> Barry, is there IETF precedent for a WG that has undergone this particular >>> train of events, namely a major disconnect between its originators' >>> intentions and the WG's expectations of direction? >>> >>> If so, our situation may be slightly easier to handle, since the >>> originators have withdrawn from pressing their case and there appears to be >>> almost no actual dispute remaining in the group.� Procedurally though, I >>> really don't know where we stand from the IETF's perspective.� We seem to >>> have a common goal now, but if the IETF demands paperwork, we're not there >>> yet because the designs and plans have not been worked out.� I'm hoping for >>> flexibility, but acknowledge that flexibility has a limit. >>> >>> That said, reading the IETF Mission Statement leaves no doubt that VW >>> interoperability is right in the middle of the road for the IETF.� Can the >>> group be left to work out what needs to be worked out? >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ================================= >>> >>> On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba >>> wrote: >>> >>>> Hi, Carlo, Vaugh... >>>> >>> _______________________________________________ >>> 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sllists@boroon.dasgupta.ch Mon Mar 28 16:14:12 2011 Return-Path: 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 4FC373A6A97 for ; Mon, 28 Mar 2011 16:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 yZXyLuC0eAja for ; Mon, 28 Mar 2011 16:14:11 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id 77D663A6960 for ; Mon, 28 Mar 2011 16:14:11 -0700 (PDT) Received: from [192.168.1.101] (adsl-62-167-25-70.adslplus.ch [62.167.25.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 693942E047 for ; Tue, 29 Mar 2011 01:18:34 +0200 (CEST) Message-ID: <4D9116A4.8010602@boroon.dasgupta.ch> Date: Tue, 29 Mar 2011 01:15:48 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:14:12 -0000 On 03/29/2011 12:58 AM, Meadhbh Hamrick wrote: > in other words, what does "interoperation between virtual worlds" mean? > > the "service level interoperability" was sufficiently defined such > that i could (and did) go out and write code to demonstrably implement > the specification. does the term "interoperation between virtual > worlds" mean: > > a. interoperability between any two existing virtual world or MMO > systems? (i.e. - between second life and world of warcraft?) > > b. interoperability between second life, second life / enterprise or > OpenSIm instances? > > or > > c. interoperability between two OpenSim instances? > > if a or b, do we have any interest from any of the implementers of > those systems to adhere to an IETF standard? How about: d. interoperability between (instances of) any two virtual world systems conforming to the (to be defined) VWRAP standard. Whether implementers of an existing virtual world system want to change that system so that it becomes conformant to the new standard and thus potentially interoperable with other conforming ones should be their own choice, of course. Cheers, Boroondas From dzonatas@gmail.com Mon Mar 28 16:23:44 2011 Return-Path: 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 0DB5C3A6A74 for ; Mon, 28 Mar 2011 16:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_BACKHAIR_11=1, 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 Ps58yBRShusV for ; Mon, 28 Mar 2011 16:23:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id BBC623A679F for ; Mon, 28 Mar 2011 16:23:40 -0700 (PDT) Received: by iwn39 with SMTP id 39so4160997iwn.31 for ; Mon, 28 Mar 2011 16:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dEtsg6/hk+kS6ZR/hEuBOLIqleUUeNVWLncnqH2027g=; b=WzQrkxFmCw5/sgy2FtzWGIpcIqsgFVnn0VeblQ5CNA23I4n/z5yPBBJAKolkPAUevF EJGUmNKAzoDYxz7zE060WQEnVX/pXRa8ZH8Pf2+cYqJmvIESVgs6+aBmanntnYTUrkoD y2EvQPmo82tjhyJRdtYAzYLqlkwv9WcPqFue4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=EKw/JNPeola7/AF4dZiqRJvecOdvGBhVdCLKhwEyRb2+lVSyUOb3i93wDHjUSQkX9l xjCWCzxESjhnOnDXckg5CPmitBIHNP6uu/DuZ7ijprkIJJFFHuIs3jJt7HwqqHxlp1wM tJb1VUtkc6EX4wfB+4+1gnXU7Fjslq2ktY7BY= Received: by 10.42.117.3 with SMTP id r3mr7080072icq.429.1301354718080; Mon, 28 Mar 2011 16:25:18 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 8sm3230112iba.55.2011.03.28.16.25.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 16:25:17 -0700 (PDT) Message-ID: <4D9118E0.1010707@gmail.com> Date: Mon, 28 Mar 2011 16:25:20 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Dzonatas Sol References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> In-Reply-To: <4D911618.7060706@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:23:44 -0000 Dzonatas Sol wrote: > If you want service only, I think there is code implemented already. > We need the ability for people to own their assets on their own local > site (and further simulate them with their own local simulator, for > like opening inventory in looking at the puzzle pieces). > > There has been much debate about client/server and exactly what that > means. Given that even X11 defines client/server backwords from the > VWinterop concept now, it is a hard battle to people's mind to bend > one way or another in terminology. I think the progress to define > multi-point on either client or service side was finally a start to > see the bigger picture easier. Being able to start up separate client > side programs is at issue that breaks away from the monolithic design. > > There are some that want to stay with the monolithic design purely for > revenue reasons. I need not mention whom. This causes the main > bottleneck from the client-side developer. If we define server side in > such way, and let server-side people "ban" client-side developers > because it doesn't fit their motif, then there is no equality in vote > in this working group. I hope we can remedy at least this in any > "interoperation". > > I think it would be easiest to consider the DAE (collada) format as an > example. Allow one client to start up (point A), and allow another > client to start up (point B), and allows these to clients to contant > an agent domain to transfer DAE files back and forth between inventory > without any region simulators. This A<->B path needs to be in the > "service level interoperability". This may seem like simple file > transfer, so be it. > P.S. It's not about copybot... it's about being able to work together on designs at the local level where people can "manufacture" the colllada files. Simplification in the file transfer process, and update, and etc, is in mind. (i.e. "the chair") -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Mon Mar 28 16:58:57 2011 Return-Path: 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 C7E6128C0E7 for ; Mon, 28 Mar 2011 16:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_11=1, 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 0vwqo59aXQ3i for ; Mon, 28 Mar 2011 16:58:55 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 9E59D3A6A8B for ; Mon, 28 Mar 2011 16:58:55 -0700 (PDT) Received: by qyk7 with SMTP id 7so2479436qyk.10 for ; Mon, 28 Mar 2011 17:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=JdCpTly8s47qoQBWm5IIp5agPrb1Qsqqbz0v6rone2Y=; b=vRNHgKpNmRWr4gnXWcXa+VEWaidWZ5cMmW/z+9vfhUg7bT9TkEz7G6G4ZIC7BQ1ieI nogmlmHWD9A4HEHYuc3wJI9y6fgzdk3yHpQRPpGYBf2CxSQmpLJdxFLJpcsbDnAkD1W4 gxJ/uq6P0YBN9auxTdL2SR8iH3PN6x2F26J1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=bTxg3u4hKijq+nl4xfqbkeu/Oh1003ANKwD4fOTFFAhRGwyJWrDIzCOljobeOYNyLR 0Xj5j9oMGoVbIvYoRD2chGRNl1zgo3d0HmW89ozI/T5heFyX+QwsHqWi6vtdyuKA3odP 1NAtHBqYGjI0u6pDReHRtGH2iJoKS33WG44rA= MIME-Version: 1.0 Received: by 10.224.137.32 with SMTP id u32mr4148697qat.322.1301356832684; Mon, 28 Mar 2011 17:00:32 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Mon, 28 Mar 2011 17:00:32 -0700 (PDT) In-Reply-To: <4D911618.7060706@gmail.com> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> Date: Tue, 29 Mar 2011 01:00:32 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00151748db04bcfc8c049f93bf43 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 23:58:57 -0000 --00151748db04bcfc8c049f93bf43 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responding to two posts: On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol wrote: > If you want service only, I think there is code implemented already. Exactly as Dzonatas says. We don't need to work on protocols for internal use by separate, isolated world services. We have those already. The ingredient that is mostly missing from the Virtual World arena is interoperability *between* such services, and that is the goal that has sparked extremely wide interest. On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte < sllists@boroon.dasgupta.ch> wrote: > > d. interoperability between (instances of) any two virtual world systems > conforming to the (to be defined) VWRAP standard. Exactly as Boroondas says. Indeed, that is the interoperability goal sough= t by the majority of contributors here over the years, so this is nothing new= . It's the feature that virtual worlds don't yet have, and that's why it's worthwhile to work on it. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol wrote: > If you want service only, I think there is code implemented already. We > need the ability for people to own their assets on their own local site (= and > further simulate them with their own local simulator, for like opening > inventory in looking at the puzzle pieces). > > There has been much debate about client/server and exactly what that mean= s. > Given that even X11 defines client/server backwords from the VWinterop > concept now, it is a hard battle to people's mind to bend one way or anot= her > in terminology. I think the progress to define multi-point on either clie= nt > or service side was finally a start to see the bigger picture easier. Bei= ng > able to start up separate client side programs is at issue that breaks aw= ay > from the monolithic design. > > There are some that want to stay with the monolithic design purely for > revenue reasons. I need not mention whom. This causes the main bottleneck > from the client-side developer. If we define server side in such way, and > let server-side people "ban" client-side developers because it doesn't fi= t > their motif, then there is no equality in vote in this working group. I h= ope > we can remedy at least this in any "interoperation". > > I think it would be easiest to consider the DAE (collada) format as an > example. Allow one client to start up (point A), and allow another client= to > start up (point B), and allows these to clients to contant an agent domai= n > to transfer DAE files back and forth between inventory without any region > simulators. This A<->B path needs to be in the "service level > interoperability". This may seem like simple file transfer, so be it. > > > Meadhbh Hamrick wrote: > >> in other words, what does "interoperation between virtual worlds" mean? >> >> the "service level interoperability" was sufficiently defined such >> that i could (and did) go out and write code to demonstrably implement >> the specification. does the term "interoperation between virtual >> worlds" mean: >> >> a. interoperability between any two existing virtual world or MMO >> systems? (i.e. - between second life and world of warcraft?) >> >> b. interoperability between second life, second life / enterprise or >> OpenSIm instances? >> >> or >> >> c. interoperability between two OpenSim instances? >> >> if a or b, do we have any interest from any of the implementers of >> those systems to adhere to an IETF standard? >> >> -cheers >> -meadhbh >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Mon, Mar 28, 2011 at 2:15 PM, Morgaine >> wrote: >> >> >>> The group's expectation of direction was already manifest at the time o= f >>> Crista's intervention a few months ago, at which time it was unanimous >>> that >>> everybody except one person was seeking interoperation between virtual >>> worlds as a primary requirement and as a key motivation for the group's >>> work. >>> >>> The dissenting opinion was clearly, if unofficially, outvoted by >> of >>> group members> to 1.=EF=BF=BD If that direction is STILL not accepted b= y everyone >>> in >>> the WG, I shall ask Barry to formally call a count of votes and establi= sh >>> the rough consensus officially.=EF=BF=BD Without this we will be perpet= ually >>> disrupted by a non-representative minority pulling in the opposite >>> direction >>> to the rest of the group. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> >>> On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick >>> wrote: >>> >>> >>>> Um. Morgaine. You don't get to define the wg's expectation or directio= n. >>>> As a member of this wg (and someone who's actually written code relate= d >>>> to >>>> it's problem domain) I would like to be included in the development of >>>> this >>>> group's consensus. >>>> >>>> On Mar 28, 2011 8:29 AM, "Morgaine" >>>> wrote: >>>> >>>> Barry, is there IETF precedent for a WG that has undergone this >>>> particular >>>> train of events, namely a major disconnect between its originators' >>>> intentions and the WG's expectations of direction? >>>> >>>> If so, our situation may be slightly easier to handle, since the >>>> originators have withdrawn from pressing their case and there appears = to >>>> be >>>> almost no actual dispute remaining in the group.=EF=BF=BD Procedurally= though, I >>>> really don't know where we stand from the IETF's perspective.=EF=BF=BD= We seem >>>> to >>>> have a common goal now, but if the IETF demands paperwork, we're not >>>> there >>>> yet because the designs and plans have not been worked out.=EF=BF=BD I= 'm hoping >>>> for >>>> flexibility, but acknowledge that flexibility has a limit. >>>> >>>> That said, reading the IETF Mission Statement leaves no doubt that VW >>>> interoperability is right in the middle of the road for the IETF.=EF= =BF=BD Can >>>> the >>>> group be left to work out what needs to be worked out? >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba >>>> wrote: >>>> >>>> >>>>> Hi, Carlo, Vaugh... >>>>> >>>>> >>>> _______________________________________________ >>>> 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 mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00151748db04bcfc8c049f93bf43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responding to two posts:

On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas = Sol <dzonatas@gm= ail.com> wrote:
If you want service only, I think there is code implemented already.


Exactly as Dzonatas says.=C2=A0 We don't need to wor= k on protocols for internal use by separate, isolated world services.=C2=A0= We have those already.=C2=A0 The ingredient that is mostly missing from th= e Virtual World arena is interoperability between such servic= es, and that is the goal that has sparked extremely wide interest.


On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte <sllists@boroon.dasgupta.= ch> wrote:

d. interoperability between (instances of) any two virtual world systems conforming to the (to be defined) VWRAP standard.

Exactly as Boroondas says.=C2=A0 Indeed, that is the interoperability goal= sought by the majority of contributors here over the years, so this is not= hing new. It's the feature that virtual worlds don't yet have, and = that's why it's worthwhile to work on it.



Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol &= lt;dzonatas@gmail.com> = wrote:
If you want servi= ce only, I think there is code implemented already. We need the ability for= people to own their assets on their own local site (and further simulate t= hem with their own local simulator, for like opening inventory in looking a= t the puzzle pieces).

There has been much debate about client/server and exactly what that means.= Given that even X11 defines client/server backwords from the VWinterop con= cept now, it is a hard battle to people's mind to bend one way or anoth= er in terminology. I think the progress to define multi-point on either cli= ent or service side was finally a start to see the bigger picture easier. B= eing able to start up separate client side programs is at issue that breaks= away from the monolithic design.

There are some that want to stay with the monolithic design purely for reve= nue reasons. I need not mention whom. This causes the main bottleneck from = the client-side developer. If we define server side in such way, and let se= rver-side people "ban" client-side developers because it doesn= 9;t fit their motif, then there is no equality in vote in this working grou= p. I hope we can remedy at least this in any "interoperation".
I think it would be easiest to consider the DAE (collada) format as an exam= ple. Allow one client to start up (point A), and allow another client to st= art up (point B), and allows these to clients to contant an agent domain to= transfer DAE files back and forth between inventory without any region sim= ulators. This A<->B path needs to be in the "service level inter= operability". This may seem like simple file transfer, so be it.


Meadhbh Hamrick wrote:
in other words, what does "interoperation between virtual worlds"= mean?

the "service level interoperability" was sufficiently defined suc= h
that i could (and did) go out and write code to demonstrably implement
the specification. does the term "interoperation between virtual
worlds" mean:

a. interoperability between any two existing virtual world or MMO
systems? (i.e. - between second life and world of warcraft?)

b. interoperability between second life, second life / enterprise or
OpenSIm instances?

or

c. interoperability between two OpenSim instances?

if a or b, do we have any interest from any of the implementers of
those systems to adhere to an IETF standard?

-cheers
-meadhbh

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMe= adhbh@gmail.com



On Mon, Mar 28, 2011 at 2:15 PM, Morgaine
<mor= gaine.dinova@googlemail.com> wrote:
=C2=A0
The group's expectation of direction was already manifest at the time o= f
Crista's intervention a few months ago, at which time it was unanimous = that
everybody except one person was seeking interoperation between virtual
worlds as a primary requirement and as a key motivation for the group's=
work.

The dissenting opinion was clearly, if unofficially, outvoted by <count = of
group members> to 1.=EF=BF=BD If that direction is STILL not accepted by= everyone in
the WG, I shall ask Barry to formally call a count of votes and establish the rough consensus officially.=EF=BF=BD Without this we will be perpetuall= y
disrupted by a non-representative minority pulling in the opposite directio= n
to the rest of the group.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
On Mon, Mar 28, 2011 at 8:53 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>
wrote:
=C2=A0 =C2=A0
Um. Morgaine. You don't get to define the wg's expectation or direc= tion.
As a member of this wg (and someone who's actually written code related= to
it's problem domain) I would like to be included in the development of = this
group's consensus.

On Mar 28, 2011 8:29 AM, "Morgaine" <morgaine.dinova@googlemail.com>
wrote:

Barry, is there IETF precedent for a WG that has undergone this particular<= br> train of events, namely a major disconnect between its originators'
intentions and the WG's expectations of direction?

If so, our situation may be slightly easier to handle, since the
originators have withdrawn from pressing their case and there appears to be=
almost no actual dispute remaining in the group.=EF=BF=BD Procedurally thou= gh, I
really don't know where we stand from the IETF's perspective.=EF=BF= =BD We seem to
have a common goal now, but if the IETF demands paperwork, we're not th= ere
yet because the designs and plans have not been worked out.=EF=BF=BD I'= m hoping for
flexibility, but acknowledge that flexibility has a limit.

That said, reading the IETF Mission Statement leaves no doubt that VW
interoperability is right in the middle of the road for the IETF.=EF=BF=BD = Can the
group be left to work out what needs to be worked out?


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Sat, Mar 26, 2011 at 2:40 PM, Barry Leiba <barryleiba@computer.org>
wrote:
=C2=A0 =C2=A0 =C2=A0
Hi, Carlo, Vaugh...
=C2=A0 =C2=A0 =C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

=C2=A0 =C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


=C2=A0 =C2=A0
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

=C2=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--00151748db04bcfc8c049f93bf43-- From ohmeadhbh@gmail.com Mon Mar 28 17:23:49 2011 Return-Path: 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 9FF8D3A6A85 for ; Mon, 28 Mar 2011 17:23:49 -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=[AWL=0.000, 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 tJyfwZARCsog for ; Mon, 28 Mar 2011 17:23:48 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 6171C3A696D for ; Mon, 28 Mar 2011 17:23:48 -0700 (PDT) Received: by iwn39 with SMTP id 39so4207175iwn.31 for ; Mon, 28 Mar 2011 17:25:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=sO88ftfURdKXbrVV0z715K91eHTAU63tFH8oR+wUrUg=; b=G6t/toKRf2+y8H9nQyEsJ5JPOEWlwGBSazNUIvat3XgzOoIzv+iIA6T4AJshhyo8U4 10gTN7D6YxJMZQUchFpF0ZYeUIZIp2gRet+t/Q+3jIgL2glG5wzXUvKsDREg/wYJlFzo ZVfbZUgzBhWTaZwicduI1SKqWU8A6GRt9/NFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=S5gIHKRpjwGnW2uSD1RaQZdNFYkyTrLIY+xPu5ux1cGSJMmVE44ZkYbcfrzARdGt81 wjNh/zaZhX5wiakTavAdWaOyuX+H6LXRNDgx2lOidwVJv/l6SUbP53CkewlLIe6Q76Mz 4PURd7jiq/SndKhGPseKPneaQuG6HbuBN1RIY= Received: by 10.42.175.68 with SMTP id az4mr7952896icb.205.1301358325092; Mon, 28 Mar 2011 17:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.219.129 with HTTP; Mon, 28 Mar 2011 17:25:04 -0700 (PDT) In-Reply-To: <4D9116A4.8010602@boroon.dasgupta.ch> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D9116A4.8010602@boroon.dasgupta.ch> From: Meadhbh Hamrick Date: Mon, 28 Mar 2011 17:25:04 -0700 Message-ID: To: Boroondas Gupte Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 00:23:50 -0000 i think that's the same thing as "service level interop" with the added requirement that participants implement all services. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Mon, Mar 28, 2011 at 4:15 PM, Boroondas Gupte wrote: > On 03/29/2011 12:58 AM, Meadhbh Hamrick wrote: >> in other words, what does "interoperation between virtual worlds" mean? >> >> the "service level interoperability" was sufficiently defined such >> that i could (and did) go out and write code to demonstrably implement >> the specification. does the term "interoperation between virtual >> worlds" mean: >> >> a. interoperability between any two existing virtual world or MMO >> systems? (i.e. - between second life and world of warcraft?) >> >> b. interoperability between second life, second life / enterprise or >> OpenSIm instances? >> >> or >> >> c. interoperability between two OpenSim instances? >> >> if a or b, do we have any interest from any of the implementers of >> those systems to adhere to an IETF standard? > How about: > > d. interoperability between (instances of) any two virtual world systems > conforming to the (to be defined) VWRAP standard. > > Whether implementers of an existing virtual world system want to change > that system so that it becomes conformant to the new standard and thus > potentially interoperable with other conforming ones should be their own > choice, of course. > > Cheers, > Boroondas > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From sllists@boroon.dasgupta.ch Mon Mar 28 18:40:17 2011 Return-Path: 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 4B83028C13E for ; Mon, 28 Mar 2011 18:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, 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 19EAyk0TR8JV for ; Mon, 28 Mar 2011 18:40:16 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id 188233A6833 for ; Mon, 28 Mar 2011 18:40:15 -0700 (PDT) Received: from [192.168.1.101] (adsl-62-167-25-70.adslplus.ch [62.167.25.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id DE4782E047; Tue, 29 Mar 2011 03:44:38 +0200 (CEST) Message-ID: <4D9138E0.6090807@boroon.dasgupta.ch> Date: Tue, 29 Mar 2011 03:41:52 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: Meadhbh Hamrick , Morgaine References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D9116A4.8010602@boroon.dasgupta.ch> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030401000502030407010506" Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 01:40:17 -0000 This is a multi-part message in MIME format. --------------030401000502030407010506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/29/2011 02:00 AM, Morgaine wrote: > On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte > > wrote: > > > d. interoperability between (instances of) any two virtual world > systems > conforming to the (to be defined) VWRAP standard. > > > > Exactly as Boroondas says. Indeed, that is the interoperability goal > sought by the majority of contributors here over the years, so this is > nothing new. It's the feature that virtual worlds don't yet have, and > that's why it's worthwhile to work on it. On 03/29/2011 02:25 AM, Meadhbh Hamrick wrote: > i think that's the same thing as "service level interop" with the > added requirement that participants implement all services. Let me get this straight. If we * take this "interoperability between VW systems" (as propagated by Morgaine), * assume these systems are composed from separable services and * drop the requirement that each service provider (I'd like to avoid the term "participant" here, as that could also refer to end users or their user-agents) provides a complete set of services (i.e. a "whole" virtual world, that could function on its own), but instead allow them to offer single services that only form a virtual world when combined with other services from other compliant providers we end up with "service level interoperability" (as propagated by Meadhbh)? (Please speak up if I'm misreading any of you.) If that is actually the case, most of the differences within the group might be merely in nomenclature. Or maybe the difference isn't mainly in the entities we want to interoperate, but instead in what we mean by interoperation? Or have we ended up at a formulation abstract enough that people can agree with it even when they actually have different goals from each other? Slightly confused, Boroondas --------------030401000502030407010506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/29/2011 02:00 AM, Morgaine wrote:
On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte <sllists@boroon.dasgupta.ch> wrote:

d. interoperability between (instances of) any two virtual world systems
conforming to the (to be defined) VWRAP standard.


Exactly as Boroondas says.  Indeed, that is the interoperability goal sought by the majority of contributors here over the years, so this is nothing new. It's the feature that virtual worlds don't yet have, and that's why it's worthwhile to work on it.

On 03/29/2011 02:25 AM, Meadhbh Hamrick wrote: 
i think that's the same thing as "service level interop" with the
added requirement that participants implement all services.

Let me get this straight. If we
  • take this "interoperability between VW systems" (as propagated by Morgaine),
  • assume these systems are composed from separable services and
  • drop the requirement that each service provider (I'd like to avoid the term "participant" here, as that could also refer to end users or their user-agents) provides a complete set of services (i.e. a "whole" virtual world, that could function on its own), but instead allow them to offer single services that only form a virtual world when combined with other services from other compliant providers
we end up with "service level interoperability" (as propagated by Meadhbh)?

(Please speak up if I'm misreading any of you.)

If that is actually the case, most of the differences within the group might be merely in nomenclature. Or maybe the difference isn't mainly in the entities we want to interoperate, but instead in what we mean by interoperation? Or have we ended up at a formulation abstract enough that people can agree with it even when they actually have different goals from each other?

Slightly confused,
Boroondas
--------------030401000502030407010506-- From dzonatas@gmail.com Mon Mar 28 19:57:11 2011 Return-Path: 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 D45163A68F6 for ; Mon, 28 Mar 2011 19:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 Jsc7PXjj2xzn for ; Mon, 28 Mar 2011 19:57:10 -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 69F573A67A2 for ; Mon, 28 Mar 2011 19:57:10 -0700 (PDT) Received: by iye19 with SMTP id 19so4283168iye.31 for ; Mon, 28 Mar 2011 19:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Z9Xo4V+4oUQhrSQAKKBk3RBTI9Dkd3zGSz9T6xZayIE=; b=P4hEWFTeDoMNUSR3kfH6AWuIgPfJ0kf/6y/4g8Vmi8l9BT9czX/8ekbtg6j9KLmmJ1 H3kcWjPe5+zQwoF5HB9M4DuawfLBAnCYh8nSJ37BDjRg9alRjuPFzI7NwDFbtAxMYOVm NWXfn6lIK35Oxl59v0dFHmmKiJs+qvNYlA0Xg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=JhvxQwedfnlFjRWA2qTuj2bRl4tzSRKzJsGGdcb5CCzUbIfIOQAVYEgLMMDWImUEra AvK6B2deycNPTgEEvlZcjKVITXAJztmbzYOl+dLeaWGFOGQ4Mq9QZxoOveInvjv6SzD7 noYD+hFzCBePZNM/+XR/zyL/z4WvSqEN/I8aI= Received: by 10.43.54.66 with SMTP id vt2mr7830221icb.300.1301367527978; Mon, 28 Mar 2011 19:58:47 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i3sm502031iby.23.2011.03.28.19.58.43 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Mar 2011 19:58:46 -0700 (PDT) Message-ID: <4D914AE8.9050000@gmail.com> Date: Mon, 28 Mar 2011 19:58:48 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Boroondas Gupte References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D9116A4.8010602@boroon.dasgupta.ch> <4D9138E0.6090807@boroon.dasgupta.ch> In-Reply-To: <4D9138E0.6090807@boroon.dasgupta.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, Meadhbh Hamrick Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 02:57:12 -0000 Boroondas Gupte wrote: > Or have we ended up at a formulation abstract enough that people can > agree with it even when they actually have different goals from each > other? > On this note, let me say that the current data packet contains asset data that has too much information. Anotherwords, some of the data should stay on the one end or the other and not transferred. Such like, creation date of the asset. When the asset is transfered, there should be a new creation date. This then easily keeps assets unique and not easily copied. (There is others...) Just sayin'.... -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Mon Mar 28 23:37:06 2011 Return-Path: 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 75CFB3A6826 for ; Mon, 28 Mar 2011 23:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 xu9nZ9YoP0iS for ; Mon, 28 Mar 2011 23:37:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 361DF3A67EF for ; Mon, 28 Mar 2011 23:37:03 -0700 (PDT) Received: by qwg5 with SMTP id 5so2805099qwg.31 for ; Mon, 28 Mar 2011 23:38:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=MgEaBhmbDFmM0RHCVxECp9esyjYzY8SBxtVTL+bg/GE=; b=AvNACMJxwB0f4jf3LKjiCWbijMLjdAweEGj50Cdaa+ygR/JcgP98wAJnwfsxT4Hzep ZOOFTC3/GBAYFOfzJzZMBfHNBh8P2ex8PvDWGwZnj2b6SK7HHgFAarNnD8M+tmkxoNr6 bwF4+JLUGV+hEpP6gGJXqDwa+277PxVy/erVs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AHXtDZnun5cfE+7c6v/XkwzALNtogo4FQ7trNfJGNK6kjyzJFYX93hwVXD21JvPZ4H ARkB2CKx9q4gTM6uGW09XrDFwKWKS+2wVlcWvAaUqTKnp/61YlXAWpIOea2TKQbRrATk q9Nsin0Vyq3VxW7sWFrwaG4qcwWHXCN2Z90nE= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr3259528qck.109.1301380720848; Mon, 28 Mar 2011 23:38:40 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Mon, 28 Mar 2011 23:38:40 -0700 (PDT) In-Reply-To: <4D9138E0.6090807@boroon.dasgupta.ch> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D9116A4.8010602@boroon.dasgupta.ch> <4D9138E0.6090807@boroon.dasgupta.ch> Date: Tue, 29 Mar 2011 07:38:40 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d3569570d2049f994fd4 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 06:37:06 -0000 --00235429d3569570d2049f994fd4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 29, 2011 at 2:41 AM, Boroondas Gupte wrote:Let me get this straight. If we > > - drop the requirement that each service provider (I'd like to avoid > the term "participant" here, as that could also refer to end users or their > user-agents) provides a complete set of services (i.e. a "whole" virtual > world, that could function on its own), but instead allow them to offer > single services that only form a virtual world when combined with other > services from other compliant providers > > we end up with "service level interoperability" (as propagated by Meadhbh)? > Boroondas, there has never been any requirement that a party provide a complete set of services. Any party can provide as many or as few types as services as they want, so that has never been an issue. The interoperability that we're talking about here is the one that every ordinary user of multiple worlds understands perfectly well when they discover to their dismay that each world is an isolated walled garden, and wish it were otherwise. The introduction of "service level interoperability" into the discussion is just an attempt to avoid that most important requirement. We either have interoperability between worlds, in which an inhabitant can travel from one world to another and take their avatar and/or possessions with them, or else we don't have that. It's black and white, and no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it. This is *NOT* a matter of terminology, as some are trying to portray. On the one hand we gain interoperability between worlds, and on the other hand we don't. Morgaine. ======================= On Tue, Mar 29, 2011 at 2:41 AM, Boroondas Gupte wrote: > On 03/29/2011 02:00 AM, Morgaine wrote: > > On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte < > sllists@boroon.dasgupta.ch> wrote: > >> >> d. interoperability between (instances of) any two virtual world systems >> conforming to the (to be defined) VWRAP standard. > > > > Exactly as Boroondas says. Indeed, that is the interoperability goal > sought by the majority of contributors here over the years, so this is > nothing new. It's the feature that virtual worlds don't yet have, and that's > why it's worthwhile to work on it. > > > On 03/29/2011 02:25 AM, Meadhbh Hamrick wrote: > > i think that's the same thing as "service level interop" with the > added requirement that participants implement all services. > > > Let me get this straight. If we > > - take this "interoperability between VW systems" (as propagated by > Morgaine), > - assume these systems are composed from separable services and > - drop the requirement that each service provider (I'd like to avoid > the term "participant" here, as that could also refer to end users or their > user-agents) provides a complete set of services (i.e. a "whole" virtual > world, that could function on its own), but instead allow them to offer > single services that only form a virtual world when combined with other > services from other compliant providers > > we end up with "service level interoperability" (as propagated by Meadhbh)? > > (Please speak up if I'm misreading any of you.) > > If that is actually the case, most of the differences within the group > might be merely in nomenclature. Or maybe the difference isn't mainly in the > entities we want to interoperate, but instead in what we mean by > interoperation? Or have we ended up at a formulation abstract enough that > people can agree with it even when they actually have different goals from > each other? > > Slightly confused, > Boroondas > --00235429d3569570d2049f994fd4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2011 at 2:41 AM, Boroondas Gupte <sllists@boroon.dasgupta.ch>= ; wrote:Let me get this straight. If we
  • drop the requirement that each service provider (I'= ;d like to avoid the term "participant" here, as that could also ref= er to end users or their user-agents) provides a complete set of services (i.e. a "whole" virtual world, that could functi= on on its own), but instead allow them to offer single services that only form a virtual world when combined with other services from other compliant providers
we end up with "service level interoperability" (as propagate= d by Meadhbh)?


Boroondas, there has never been any requirem= ent that a party provide a complete set of services.=A0 Any party can provi= de as many or as few types as services as they want, so that has never been= an issue.

The interoperability that we're talking about here is the one that = every ordinary user of multiple worlds understands perfectly well when they= discover to their dismay that each world is an isolated walled garden, and= wish it were otherwise.=A0 The introduction of "service level interop= erability" into the discussion is just an attempt to avoid that most i= mportant requirement.

We either have interoperability between worlds, in which an inhabitant = can travel from one world to another and take their avatar and/or possessio= ns with them, or else we don't have that.=A0 It's black and white, = and no amount of fudging about "service level interoperability" i= s going to overcome the lack of VW interoperability as a user would underst= and it.

This is NOT a matter of terminology, as some are trying t= o portray.=A0 On the one hand we gain interoperability between worlds, and = on the other hand we don't.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Mar 29, 2011 at 2:41 AM, Boroondas= Gupte <= sllists@boroon.dasgupta.ch> wrote:
=20 =20 =20
On 03/29/2011 02:00 AM, Morgaine wrote:
On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte <sll= ists@boroon.dasgupta.ch> wrote:

d. interoperability between (instances of) any two virtual world systems
conforming to the (to be defined) VWRAP standard.


Exactly as Boroondas says.=A0 Indeed, that is the interoperability goal sought by the majority of contributors here over the years, so this is nothing new. It's the feature that virtual worlds don&= #39;t yet have, and that's why it's worthwhile to work on it.
=

On 03/29/2011 02:25 AM, Meadhbh Hamrick wrote: 
i think that's the same thing as "service level interop=
" with the
added requirement that participants implement all services.

Let me get this straight. If we
  • take this "interoperability between VW systems" (as pro= pagated by Morgaine),
  • assume these systems are composed from separable services and
  • drop the requirement that each service provider (I'd like to avoid the term "participant" here, as that could also ref= er to end users or their user-agents) provides a complete set of services (i.e. a "whole" virtual world, that could functi= on on its own), but instead allow them to offer single services that only form a virtual world when combined with other services from other compliant providers
we end up with "service level interoperability" (as propagate= d by Meadhbh)?

(Please speak up if I'm misreading any of you.)

If that is actually the case, most of the differences within the group might be merely in nomenclature. Or maybe the difference isn'= t mainly in the entities we want to interoperate, but instead in what we mean by interoperation? Or have we ended up at a formulation abstract enough that people can agree with it even when they actually have different goals from each other?

Slightly confused,
Boroondas

--00235429d3569570d2049f994fd4-- From mike.dickson@hp.com Tue Mar 29 05:54:13 2011 Return-Path: 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 5568E3A67B6 for ; Tue, 29 Mar 2011 05:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 8VfP3reC8VVF for ; Tue, 29 Mar 2011 05:54:12 -0700 (PDT) Received: from g4t0015.houston.hp.com (g4t0015.houston.hp.com [15.201.24.18]) by core3.amsl.com (Postfix) with ESMTP id 137193A6452 for ; Tue, 29 Mar 2011 05:54:11 -0700 (PDT) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0015.houston.hp.com (Postfix) with ESMTPS id C558989EF; Tue, 29 Mar 2011 12:55:49 +0000 (UTC) Received: from G4W1852.americas.hpqcorp.net (16.234.97.230) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 29 Mar 2011 12:54:39 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G4W1852.americas.hpqcorp.net ([16.234.97.230]) with mapi; Tue, 29 Mar 2011 12:54:38 +0000 From: "Dickson, Mike (ISS Software)" To: Morgaine , "vwrap@ietf.org" Date: Tue, 29 Mar 2011 12:54:35 +0000 Thread-Topic: [vwrap] Status and future of the VWRAP working group Thread-Index: AcvtpFa3mUmGgSZyRUmFUi+yEnI85QAasuTQ Message-ID: <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4646639E08F58B42836FAC24C94624DD92FDE5FEC5GVW0433EXBame_" MIME-Version: 1.0 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 12:54:13 -0000 --_000_4646639E08F58B42836FAC24C94624DD92FDE5FEC5GVW0433EXBame_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogdndyYXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnZ3cmFwLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBNb3JnYWluZQ0KU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxMSA4 OjAxIFBNDQpUbzogdndyYXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbdndyYXBdIFN0YXR1cyBh bmQgZnV0dXJlIG9mIHRoZSBWV1JBUCB3b3JraW5nIGdyb3VwDQoNClJlc3BvbmRpbmcgdG8gdHdv IHBvc3RzOg0KDQpPbiBUdWUsIE1hciAyOSwgMjAxMSBhdCAxMjoxMyBBTSwgRHpvbmF0YXMgU29s IDxkem9uYXRhc0BnbWFpbC5jb208bWFpbHRvOmR6b25hdGFzQGdtYWlsLmNvbT4+IHdyb3RlOg0K SWYgeW91IHdhbnQgc2VydmljZSBvbmx5LCBJIHRoaW5rIHRoZXJlIGlzIGNvZGUgaW1wbGVtZW50 ZWQgYWxyZWFkeS4NCg0KDQpFeGFjdGx5IGFzIER6b25hdGFzIHNheXMuICBXZSBkb24ndCBuZWVk IHRvIHdvcmsgb24gcHJvdG9jb2xzIGZvciBpbnRlcm5hbCB1c2UgYnkgc2VwYXJhdGUsIGlzb2xh dGVkIHdvcmxkIHNlcnZpY2VzLiAgV2UgaGF2ZSB0aG9zZSBhbHJlYWR5LiAgVGhlIGluZ3JlZGll bnQgdGhhdCBpcyBtb3N0bHkgbWlzc2luZyBmcm9tIHRoZSBWaXJ0dWFsIFdvcmxkIGFyZW5hIGlz IGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBzdWNoIHNlcnZpY2VzLCBhbmQgdGhhdCBpcyB0aGUg Z29hbCB0aGF0IGhhcyBzcGFya2VkIGV4dHJlbWVseSB3aWRlIGludGVyZXN0Lg0KDQpSaWdodCwg c28gd2UgZG8gbmVlZCB0byBzdGFuZGFyZGl6ZSDigJxTZXJ2aWNlIExldmVsIEludGVyb3DigJ0u ICBBcyBoYXMgYmVlbiBwb2ludGVkIG91dCBpdHMgY29uY3JldGUgZW5vdWdoIHlvdSBjYW4gYWN0 dWFsbHkgZG8gaXQgYW5kIGl0IHdvdWxkIGFsbG93IHRoZSBhc3NlbWJseSBvZiB2aXJ0dWFsIHdv cmxkcyBiYXNlZCB1cG9uIGl0LiAgIFRoZSBwb2ludCB0aGF0IHNvbWUgb2YgdGhpcyBleGlzdHMg aXMgYSBnb29kIG9uZSwgdGhlcmXigJlzIHNvbWUgZXhpc3RpbmcgcHJhY3RpY2UgYW5kIGtub3ds ZWRnZSB0aGF0IGNhbiBiZSBsZXZlcmFnZWQuDQoNCk9uIFR1ZSwgTWFyIDI5LCAyMDExIGF0IDEy OjE1IEFNLCBCb3Jvb25kYXMgR3VwdGUgPHNsbGlzdHNAYm9yb29uLmRhc2d1cHRhLmNoPG1haWx0 bzpzbGxpc3RzQGJvcm9vbi5kYXNndXB0YS5jaD4+IHdyb3RlOg0KDQpkLiBpbnRlcm9wZXJhYmls aXR5IGJldHdlZW4gKGluc3RhbmNlcyBvZikgYW55IHR3byB2aXJ0dWFsIHdvcmxkIHN5c3RlbXMN CmNvbmZvcm1pbmcgdG8gdGhlICh0byBiZSBkZWZpbmVkKSBWV1JBUCBzdGFuZGFyZC4NCg0KRXhh Y3RseSBhcyBCb3Jvb25kYXMgc2F5cy4gIEluZGVlZCwgdGhhdCBpcyB0aGUgaW50ZXJvcGVyYWJp bGl0eSBnb2FsIHNvdWdodCBieSB0aGUgbWFqb3JpdHkgb2YgY29udHJpYnV0b3JzIGhlcmUgb3Zl ciB0aGUgeWVhcnMsIHNvIHRoaXMgaXMgbm90aGluZyBuZXcuIEl0J3MgdGhlIGZlYXR1cmUgdGhh dCB2aXJ0dWFsIHdvcmxkcyBkb24ndCB5ZXQgaGF2ZSwgYW5kIHRoYXQncyB3aHkgaXQncyB3b3J0 aHdoaWxlIHRvIHdvcmsgb24gaXQuDQoNCkFnYWluLCB0aGlzIGlzIHNlbnNpYmxlIGFuZCBpdOKA mXMgYWNoaWV2ZWQgdmlhIHRoZSDigJxzdGFuZGFyZCBzZXJ2aWNlc+KAnSBkZWZpbmVkIGFib3Zl LiAgSSBkb27igJl0IGtub3cgd2hhdCBpdCBtZWFuIHRvIGhhdmUgdmlydHVhbCB3b3JsZCBpbnRl cm9wIHBlcnNvbmFsbHkuICBJdOKAmXMgYSBuaWNlIGlkZWFsIGJ1dCBpbiBwcmFjdGljZSBkaWZm ZXJlbmNlcyBpbiBwb2xpY3ksIHRlY2hub2xvZ3ksIGV0YywgbWFrZSBpdCBwcmFjdGljYWxseSBp bXBvc3NpYmxlIHRvIHNwZWNpZnkgZ2l2ZW4gdGhlIGN1cnJlbnQgc3RhdGUgb2YgIGFmZmFpcnMu ICAgIFdlIGNhbuKAmXQgZXZlbiBhZ3JlZSBvbiBhIHRoZSBkYXRhIGRlc2NyaXB0aW9uIHByb3Rv Y29sIGxldCBhbG9uZSBob3cgdG8gaGFuZGxlIHBvbGljeSBhY3Jvc3MgVlcgc3lzdGVtcy4gIEFu ZCB0aGF0IGV4dGVuZHMgcGFzdCBidXNpbmVzcyBwb2xpY3kgaW50byB0ZWNobmljYWwgaXNzdWVz IGxpa2U6IGlmIGFuIOKAnG9iamVjdOKAnSAgaXMgc2NyaXB0ZWQgaG93IGRvZXMgdGhhdCB0cmFu c2ZlciB0byBhbm90aGVyIFZXLiBXaG8gYWxsb2NhdGVzIHRoZSBzY3JpcHQgcmVzb3VyY2VzLiAg QW5kIG9mIGNvdXJzZSB0aGVyZeKAmXMgYWxzbyBjcmVhdG9y4oCZcyByaWdodHMgdnMuIG93bmVy 4oCZcyByaWdodHMuICBUaGUgbGlzdCBpcyBleHRyZW1lbHkgbG9uZyBhbmQgd2UgY2Fu4oCZdCBl dmVuIGFncmVlIG9uIGhvdyBzZXJ2aWNlcyBzaG91bGQgdGFsayBhbmQgd2hpY2ggdGhlcmUgc2hv dWxkIGJlIGluIGEgc3RhbmRhcmQgd2F5Lg0KDQpJTU8sIHRoZSBlZmZvcnQgc2hvdWxkIGZvY3Vz IG9uIFNlcnZpY2UgTGV2ZWwgaW50ZXJvcGVyYWJpbGl0eSBhbmQgdGhlIGRlZmluaXRpb24gb2Yg YSBmZXcgZnVuZGFtZW50YWwgYnVpbGRpbmcgYmxvY2sgc2VydmljZXM6IGkuZSB1c2VyIHNlcnZp Y2UsIGludmVudG9yeSBzZXJ2aWNlLCBhc3NldCBzZXJ2aWNlLiAgSeKAmWQgbGVhdmUgdGhlIHNp bXVsYXRvciBwaWVjZSBvZmYgZm9yIG5vdy4gIElmIHdlIGdldCB0aG9zZSByaWdodCB5b3UgY2Fu IHN0YXJ0IHRvIHNoYXJlIHVzZXIgaW5mb3JtYXRpb24gYmV0d2VlbiDigJx2aXJ0dWFsIHdvcmxk c+KAnSwgbG9jYXRlIGFuZCBhY2Nlc3MgaW52ZW50b3J5IGFuZCBkZWZpbmUgYW4gb2JqZWN0cyBj aGFyYWN0ZXJpc3RpY3MgaW5zaWRlIGEgc2ltdWxhdG9yLiAgQW5kIHRoZSBzaW11bGF0b3IgcGll Y2UgY2FuIGV2b2x2ZSB1bnRpbCBpdHMgcmVhZHkgdG8gYmUgc3RhbmRhcmRpemVkLg0KTWlrZQ0K DQo= --_000_4646639E08F58B42836FAC24C94624DD92FDE5FEC5GVW0433EXBame_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+ PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNl Y3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiB2d3JhcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86dndyYXAtYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5Nb3JnYWluZTxicj48Yj5TZW50OjwvYj4gTW9uZGF5LCBN YXJjaCAyOCwgMjAxMSA4OjAxIFBNPGJyPjxiPlRvOjwvYj4gdndyYXBAaWV0Zi5vcmc8YnI+PGI+ U3ViamVjdDo8L2I+IFJlOiBbdndyYXBdIFN0YXR1cyBhbmQgZnV0dXJlIG9mIHRoZSBWV1JBUCB3 b3JraW5nIGdyb3VwPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+UmVzcG9uZGluZyB0byB0d28gcG9z dHM6PGJyPjxicj5PbiBUdWUsIE1hciAyOSwgMjAxMSBhdCAxMjoxMyBBTSwgRHpvbmF0YXMgU29s ICZsdDs8YSBocmVmPSJtYWlsdG86ZHpvbmF0YXNAZ21haWwuY29tIj5kem9uYXRhc0BnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTogPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHlv dSB3YW50IHNlcnZpY2Ugb25seSwgSSB0aGluayB0aGVyZSBpcyBjb2RlIGltcGxlbWVudGVkIGFs cmVhZHkuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPjxicj5FeGFj dGx5IGFzIER6b25hdGFzIHNheXMuJm5ic3A7IFdlIGRvbid0IG5lZWQgdG8gd29yayBvbiBwcm90 b2NvbHMgZm9yIGludGVybmFsIHVzZSBieSBzZXBhcmF0ZSwgaXNvbGF0ZWQgd29ybGQgc2Vydmlj ZXMuJm5ic3A7IFdlIGhhdmUgdGhvc2UgYWxyZWFkeS4mbmJzcDsgVGhlIGluZ3JlZGllbnQgdGhh dCBpcyBtb3N0bHkgbWlzc2luZyBmcm9tIHRoZSBWaXJ0dWFsIFdvcmxkIGFyZW5hIGlzIGludGVy b3BlcmFiaWxpdHkgPGI+PGk+YmV0d2VlbjwvaT48L2I+IHN1Y2ggc2VydmljZXMsIGFuZCB0aGF0 IGlzIHRoZSBnb2FsIHRoYXQgaGFzIHNwYXJrZWQgZXh0cmVtZWx5IHdpZGUgaW50ZXJlc3QuPGJy Pjxicj48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJpZ2h0LCBzbyB3ZSBkbyBu ZWVkIHRvIHN0YW5kYXJkaXplIOKAnFNlcnZpY2UgTGV2ZWwgSW50ZXJvcOKAnS7CoCBBcyBoYXMg YmVlbiBwb2ludGVkIG91dCBpdHMgY29uY3JldGUgZW5vdWdoIHlvdSBjYW4gYWN0dWFsbHkgZG8g aXQgYW5kIGl0IHdvdWxkIGFsbG93IHRoZSBhc3NlbWJseSBvZiB2aXJ0dWFsIHdvcmxkcyBiYXNl ZCB1cG9uIGl0LsKgwqAgVGhlIHBvaW50IHRoYXQgc29tZSBvZiB0aGlzIGV4aXN0cyBpcyBhIGdv b2Qgb25lLCB0aGVyZeKAmXMgc29tZSBleGlzdGluZyBwcmFjdGljZSBhbmQga25vd2xlZGdlIHRo YXQgY2FuIGJlIGxldmVyYWdlZC7CoCA8L3NwYW4+PGJyPjxicj5PbiBUdWUsIE1hciAyOSwgMjAx MSBhdCAxMjoxNSBBTSwgQm9yb29uZGFzIEd1cHRlICZsdDs8YSBocmVmPSJtYWlsdG86c2xsaXN0 c0Bib3Jvb24uZGFzZ3VwdGEuY2giPnNsbGlzdHNAYm9yb29uLmRhc2d1cHRhLmNoPC9hPiZndDsg d3JvdGU6PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxicj5kLiBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gKGluc3RhbmNlcyBv ZikgYW55IHR3byB2aXJ0dWFsIHdvcmxkIHN5c3RlbXM8YnI+Y29uZm9ybWluZyB0byB0aGUgKHRv IGJlIGRlZmluZWQpIFZXUkFQIHN0YW5kYXJkLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5FeGFjdGx5IGFzIEJv cm9vbmRhcyBzYXlzLiZuYnNwOyBJbmRlZWQsIHRoYXQgaXMgdGhlIGludGVyb3BlcmFiaWxpdHkg Z29hbCBzb3VnaHQgYnkgdGhlIG1ham9yaXR5IG9mIGNvbnRyaWJ1dG9ycyBoZXJlIG92ZXIgdGhl IHllYXJzLCBzbyB0aGlzIGlzIG5vdGhpbmcgbmV3LiBJdCdzIHRoZSBmZWF0dXJlIHRoYXQgdmly dHVhbCB3b3JsZHMgZG9uJ3QgeWV0IGhhdmUsIGFuZCB0aGF0J3Mgd2h5IGl0J3Mgd29ydGh3aGls ZSB0byB3b3JrIG9uIGl0Ljxicj48YnI+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206 MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkFnYWluLCB0aGlzIGlzIHNlbnNpYmxlIGFu ZCBpdOKAmXMgYWNoaWV2ZWQgdmlhIHRoZSDigJxzdGFuZGFyZCBzZXJ2aWNlc+KAnSBkZWZpbmVk IGFib3ZlLsKgIEkgZG9u4oCZdCBrbm93IHdoYXQgaXQgbWVhbiB0byBoYXZlIHZpcnR1YWwgd29y bGQgaW50ZXJvcCBwZXJzb25hbGx5LsKgIEl04oCZcyBhIG5pY2UgaWRlYWwgYnV0IGluIHByYWN0 aWNlIGRpZmZlcmVuY2VzIGluIHBvbGljeSwgdGVjaG5vbG9neSwgZXRjLCBtYWtlIGl0IHByYWN0 aWNhbGx5IGltcG9zc2libGUgdG8gc3BlY2lmeSBnaXZlbiB0aGUgY3VycmVudCBzdGF0ZSBvZiDC oGFmZmFpcnMuwqAgwqDCoFdlIGNhbuKAmXQgZXZlbiBhZ3JlZSBvbiBhIHRoZSBkYXRhIGRlc2Ny aXB0aW9uIHByb3RvY29sIGxldCBhbG9uZSBob3cgdG8gaGFuZGxlIHBvbGljeSBhY3Jvc3MgVlcg c3lzdGVtcy4gwqBBbmQgdGhhdCBleHRlbmRzIHBhc3QgYnVzaW5lc3MgcG9saWN5IGludG8gdGVj aG5pY2FsIGlzc3VlcyBsaWtlOiBpZiBhbiDigJxvYmplY3TigJ0gwqBpcyBzY3JpcHRlZCBob3cg ZG9lcyB0aGF0IHRyYW5zZmVyIHRvIGFub3RoZXIgVlcuIFdobyBhbGxvY2F0ZXMgdGhlIHNjcmlw dCByZXNvdXJjZXMuwqAgQW5kIG9mIGNvdXJzZSB0aGVyZeKAmXMgYWxzbyBjcmVhdG9y4oCZcyBy aWdodHMgdnMuIG93bmVy4oCZcyByaWdodHMuwqAgVGhlIGxpc3QgaXMgZXh0cmVtZWx5IGxvbmcg YW5kIHdlIGNhbuKAmXQgZXZlbiBhZ3JlZSBvbiBob3cgc2VydmljZXMgc2hvdWxkIHRhbGsgYW5k IHdoaWNoIHRoZXJlIHNob3VsZCBiZSBpbiBhIHN0YW5kYXJkIHdheS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5JTU8sIHRoZSBlZmZvcnQgc2hvdWxkIGZvY3VzIG9uIFNlcnZpY2UgTGV2ZWwgaW50ZXJv cGVyYWJpbGl0eSBhbmQgdGhlIGRlZmluaXRpb24gb2YgYSBmZXcgZnVuZGFtZW50YWwgYnVpbGRp bmcgYmxvY2sgc2VydmljZXM6IGkuZSB1c2VyIHNlcnZpY2UsIGludmVudG9yeSBzZXJ2aWNlLCBh c3NldCBzZXJ2aWNlLsKgIEnigJlkIGxlYXZlIHRoZSBzaW11bGF0b3IgcGllY2Ugb2ZmIGZvciBu b3cuwqAgSWYgd2UgZ2V0IHRob3NlIHJpZ2h0IHlvdSBjYW4gc3RhcnQgdG8gc2hhcmUgdXNlciBp bmZvcm1hdGlvbiBiZXR3ZWVuIOKAnHZpcnR1YWwgd29ybGRz4oCdLCBsb2NhdGUgYW5kIGFjY2Vz cyBpbnZlbnRvcnkgYW5kIGRlZmluZSBhbiBvYmplY3RzIGNoYXJhY3RlcmlzdGljcyBpbnNpZGUg YSBzaW11bGF0b3IuwqAgQW5kIHRoZSBzaW11bGF0b3IgcGllY2UgY2FuIGV2b2x2ZSB1bnRpbCBp dHMgcmVhZHkgdG8gYmUgc3RhbmRhcmRpemVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPk1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_4646639E08F58B42836FAC24C94624DD92FDE5FEC5GVW0433EXBame_-- From barryleiba.mailing.lists@gmail.com Tue Mar 29 07:14:29 2011 Return-Path: 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 8D7D23A6824 for ; Tue, 29 Mar 2011 07:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Yh-pLV8wBwk7 for ; Tue, 29 Mar 2011 07:14:28 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 839B93A6A26 for ; Tue, 29 Mar 2011 07:14:28 -0700 (PDT) Received: by wwa36 with SMTP id 36so166558wwa.13 for ; Tue, 29 Mar 2011 07:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=qt0OrbBzGuMqKSBHshnvd3xPm0sSSb/zRcHRSIEqWH4=; b=KXvTNedllooG++OsmvlUlooz6PJdl9yepsAHqtm/rMRsviQhAMW1J2xEqMmZQp4EF/ 9/dk00qTpYFgWZpMzFu1P+QJbnv/aNiyChNSIfXl6Q46Tlj/MBjQZeIZa/n10Jy9OzGe qH7PXZHG+iDptztHxWMw2Yy4xPP1aOd3VsX0M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=n3ILBGR99GooIBvvdA8GWpN/k+i2MQ13q0BB0DlO6ZFQ7EFrGQyeQfZAZBYxEPZPkK oXlOXYMQ2aVRJLgIVvd6hVfBdGrAiEdNj1OH1ljmssRuzkVjmoM6pLAFT8pZl+By1rZA Easlmp3u0dUN0ZJ3rtPXz+v9J+NddjpE3lIoE= MIME-Version: 1.0 Received: by 10.216.245.6 with SMTP id n6mr4087519wer.40.1301408165885; Tue, 29 Mar 2011 07:16:05 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.227.208.83 with HTTP; Tue, 29 Mar 2011 07:15:59 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Tue, 29 Mar 2011 10:15:59 -0400 X-Google-Sender-Auth: dTBEewfYEsKnCMbyVdWZPIjr6dg Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:14:29 -0000 I have no time this week, during IETF week, to respond in detail. And I'll be on vacation next week. I'll try to give a full response when I get back home, after 8 April. But something quick now: > Notwithstanding that the IETF places certain duties on Barry and others to > ensure that there is visible progress in the form of documents, I must say > that "documents at all costs" is not a particularly good way of achieving > technical progress. So people don't misunderstand, here: documents are what the IETF produces. Therefore, in the end, we need to have documents. On the way there, we need to see progress. We ultimately measure progress by finished documents, and sometimes measure progress along the way by progress on documents. Productive discussion is good, too. Don't interpret from this that the only thing I or the ADs care about are getting documents cranked out "at all costs". The problem is that we haven't had any progress in a long time, and we need to push things along. We can talk forever; I know that. That talk *eventually* has to turn into documents, or we might as well close the working group and just let people chat on the mailing list. That's why I'm pushing for some visible progress on at least one document, the introduction/overview one. I'm not suggesting that we should be posting documents with individual opinions, at the expense of group consensus. What I'm saying is that if, as a group, we can't talk a bit, tease consensus out of that, write that consensus down, and post it as a draft proposal... then we're being ineffective. There's enough going on here that we're not going to shut things down on 10 April because nothing's been posted. That said, we need to be leading this discussion on consensus that can be documented and posted. And we need to focus on that and accomplish it soon, for a vague but near-term value of "soon". Barry, as chair (Now, my attention is back to the PLASMA BoF....) From izzyalanis@gmail.com Tue Mar 29 07:56:53 2011 Return-Path: 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 A976B3A682B for ; Tue, 29 Mar 2011 07:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.532 X-Spam-Level: X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 vGNQkImOfDpE for ; Tue, 29 Mar 2011 07:56:53 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AA71E3A67AB for ; Tue, 29 Mar 2011 07:56:52 -0700 (PDT) Received: by fxm15 with SMTP id 15so310617fxm.31 for ; Tue, 29 Mar 2011 07:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=JukIvTzHakpKI6WJM9M2xL03Jpexe0cQDZL2vptA9yg=; b=FyvQqT8AminB+9DOzmEUkzUaKWvkRuJIC23g163IVxmGVz4/rx3+FWpqKtlmJO2zRj 36KlUM74myY/oVzTlWl63ZsGovTRCrlhN3SSmrTz9HQJZeDzI2iCwcJch0gngSMwHVs5 WqfhoAR2YLGaz7FNgh7F66S+4mdg++qvpKdS0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=YFj8KDVUCEEl9W7LWsDugehtaFlOakp7KjSc0OGh508C8ot9LKcM1Eb0ZisYBK9gao pDm0xH1e2RhecjErfc/DkE+d0R73Kw54NiP7OHItnMlp9FHC/aviWxIjkzCbHv2uX6Nr II2LhAMGuVGEp5Wc0ZWQgldnZMjyrHwT9ZssE= MIME-Version: 1.0 Received: by 10.223.158.9 with SMTP id d9mr4730089fax.124.1301410710428; Tue, 29 Mar 2011 07:58:30 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Tue, 29 Mar 2011 07:58:30 -0700 (PDT) Date: Tue, 29 Mar 2011 10:58:30 -0400 Message-ID: From: Izzy Alanis To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 14:56:53 -0000 Starting new thread as the previous one is becoming too unwieldily. Morgaine said: > We either have interoperability between worlds, in which an inhabitant ca= n travel from one world to another and take their avatar and/or possessions= with them, or else we don't have that. =A0It's black and white, and no amo= unt of fudging about "service level interoperability" is going to overcome = the lack of VW interoperability as a user would understand it. The world is full of shades of grey. Is there an assumption that an Avatar has/uses one (and only one?) "Asset Service" -- that I have a single repository of possessions to take? Can I have and use different asset services? Can I use multiple asset services? Can people share? - Izzy From morgaine.dinova@googlemail.com Tue Mar 29 08:00:23 2011 Return-Path: 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 B68AA3A6824 for ; Tue, 29 Mar 2011 08:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 gE+SZKfF+5XF for ; Tue, 29 Mar 2011 08:00:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 59B0E3A6A41 for ; Tue, 29 Mar 2011 08:00:17 -0700 (PDT) Received: by qyk7 with SMTP id 7so184737qyk.10 for ; Tue, 29 Mar 2011 08:01:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RU8SLnCwTR9g3V+cepkR8b1WCo6Btv706u+/19csusA=; b=QZm00c424nVDg44ARKKf0hDbUsFeiNt+n26Uae73lQ17bC+8zUU01Jd3/daXlo+Do6 4bIH3TTHHFXjrdanbBVq5nPtqo4SFQ0RnRu7bXxaAFC6aIvBEmQJCOqHea26RPvIfS+F 4Bk9VzB6Uu2WwdCBE9U9DnKY1XWP8bx8ZvxAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=slcv0kU3vf4+xGHHTgDtioNY6kpoD31Q+prRdpwZDCDPOH6SMJOtq6mUz9+tpQzjow gxKAKZub9JTQ8qJNXRRLpTs+CVxXiZxWtuc6UwlX5IerbPMCYwVHvZ/voGnUoEN/ei6D RRh/OZS/ExCbwTvZS10yBmaVGzRgm4aq2qc7Y= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr3647797qck.109.1301410915316; Tue, 29 Mar 2011 08:01:55 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 08:01:54 -0700 (PDT) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Tue, 29 Mar 2011 16:01:54 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d35650744c049fa05734 Cc: Barry Leiba Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:00:23 -0000 --00235429d35650744c049fa05734 Content-Type: text/plain; charset=ISO-8859-1 Thanks Barry. That's what I assumed the IETF wants, documents reflecting the group's technical progress and working towards a consensus, not documents as an end in themselves even when they do not reflect any consensus. We had a round of documents produced by one or more parties who openly and explicitly confirmed to us here that *interoperation between VWs was not intended*, but only belatedly after the group exerted intense pressure to make the issue clear. Obtaining that fact has been like drawing blood from a stone, instead of reading an openly stated requirement. That's how far the documents process has got us so far, and it has been very unhelpful for the group's progress, effectively wasting some years of our lives with very little to show for our time and effort. Let's not let that happen again. We need a group consensus on this core issue before we can even begin to think about documents again, because the nature of most of our documents is entirely dependent on that choice. On Tue, Mar 29, 2011 at 3:15 PM, Barry Leiba wrote: > > That said, we need to be leading this discussion on consensus that can > be documented and posted. And we need to focus on that and accomplish > it soon, for a vague but near-term value of "soon". > Here, here! :-) Morgaine. ========================== On Tue, Mar 29, 2011 at 3:15 PM, Barry Leiba wrote: > I have no time this week, during IETF week, to respond in detail. And > I'll be on vacation next week. I'll try to give a full response when > I get back home, after 8 April. But something quick now: > > > Notwithstanding that the IETF places certain duties on Barry and others > to > > ensure that there is visible progress in the form of documents, I must > say > > that "documents at all costs" is not a particularly good way of achieving > > technical progress. > > So people don't misunderstand, here: documents are what the IETF > produces. Therefore, in the end, we need to have documents. On the > way there, we need to see progress. We ultimately measure progress by > finished documents, and sometimes measure progress along the way by > progress on documents. Productive discussion is good, too. > > Don't interpret from this that the only thing I or the ADs care about > are getting documents cranked out "at all costs". The problem is that > we haven't had any progress in a long time, and we need to push things > along. We can talk forever; I know that. That talk *eventually* has > to turn into documents, or we might as well close the working group > and just let people chat on the mailing list. > > That's why I'm pushing for some visible progress on at least one > document, the introduction/overview one. I'm not suggesting that we > should be posting documents with individual opinions, at the expense > of group consensus. What I'm saying is that if, as a group, we can't > talk a bit, tease consensus out of that, write that consensus down, > and post it as a draft proposal... then we're being ineffective. > > There's enough going on here that we're not going to shut things down > on 10 April because nothing's been posted. > > That said, we need to be leading this discussion on consensus that can > be documented and posted. And we need to focus on that and accomplish > it soon, for a vague but near-term value of "soon". > > Barry, as chair > (Now, my attention is back to the PLASMA BoF....) > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d35650744c049fa05734 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Barry.=A0 That's what I assumed the IETF wants, documents reflec= ting the group's technical progress and working towards a consensus, no= t documents as an end in themselves even when they do not reflect any conse= nsus.

We had a round of documents produced by one or more parties who openly = and explicitly confirmed to us here that interoperation between VWs w= as not intended, but only belatedly after the group exerted intense= pressure to make the issue clear.=A0 Obtaining that fact has been like dra= wing blood from a stone, instead of reading an openly stated requirement.
That's how far the documents process has got us so far, and it has = been very unhelpful for the group's progress, effectively wasting some = years of our lives with very little to show for our time and effort.=A0 Let= 's not let that happen again.

We need a group consensus on this core issue before we can even begin t= o think about documents again, because the nature of most of our documents = is entirely dependent on that choice.


On Tue, Mar 29, 2011 at 3:= 15 PM, Barry Leiba <barryleiba@computer.org> wrote:

That said, we need to be leading this discussion on consensus that can
be documented and posted. =A0And we need to focus on that and accomplish it soon, for a vague but near-term value of "soon".


Here, here! :-)


Morgaine.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D

On Tue, Mar 29, 2011 at 3:15 PM, B= arry Leiba <barryleiba@computer.org> wrote:
I have no time th= is week, during IETF week, to respond in detail. =A0And
I'll be on vacation next week. =A0I'll try to give a full response = when
I get back home, after 8 April. =A0But something quick now:

> Notwithstanding that the IETF places certain duties on Barry and other= s to
> ensure that there is visible progress in the form of documents, I must= say
> that "documents at all costs" is not a particularly good way= of achieving
> technical progress.

So people don't misunderstand, here: =A0documents are what the IE= TF
produces. =A0Therefore, in the end, we need to have documents. =A0On the way there, we need to see progress. =A0We ultimately measure progress by finished documents, and sometimes measure progress along the way by
progress on documents. =A0Productive discussion is good, too.

Don't interpret from this that the only thing I or the ADs care about are getting documents cranked out "at all costs". =A0The problem = is that
we haven't had any progress in a long time, and we need to push things<= br> along. =A0We can talk forever; I know that. =A0That talk *eventually* has to turn into documents, or we might as well close the working group
and just let people chat on the mailing list.

That's why I'm pushing for some visible progress on at least one document, the introduction/overview one. =A0I'm not suggesting that we<= br> should be posting documents with individual opinions, at the expense
of group consensus. =A0What I'm saying is that if, as a group, we can&#= 39;t
talk a bit, tease consensus out of that, write that consensus down,
and post it as a draft proposal... then we're being ineffective.

There's enough going on here that we're not going to shut things do= wn
on 10 April because nothing's been posted.

That said, we need to be leading this discussion on consensus that can
be documented and posted. =A0And we need to focus on that and accomplish it soon, for a vague but near-term value of "soon".

Barry, as chair
(Now, my attention is back to the PLASMA BoF....)
_________________________________________= ______
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d35650744c049fa05734-- From morgaine.dinova@googlemail.com Tue Mar 29 08:35:53 2011 Return-Path: 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 1D8123A697F for ; Tue, 29 Mar 2011 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 UD62ywU1kB4s for ; Tue, 29 Mar 2011 08:35:51 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 18EE13A6932 for ; Tue, 29 Mar 2011 08:35:51 -0700 (PDT) Received: by qwg5 with SMTP id 5so227832qwg.31 for ; Tue, 29 Mar 2011 08:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=WYpyrk1ut33OlPn515v0WRLJf7N9ZJaBQsenDmTHQaM=; b=Qqj7fKUEbVzr77Fa0bpMZ7umqTcEUQw39ifj+C5ozr2889f1/h/5XqXQsmiKYfgQZP xFJVtp+blr+b8ADgzzsOvTMZYZPWGlSO62uwO+b6uDpEEHK4zgnDlvjB3ReuUR8YwyqQ Rgn3+zOjOJl2RTMNZgnL3djKM5sdRfhw2AYtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MU5i3pvsEVxXgfn9qzFx71+iGT4qt+IN1GaG9CNRseTPot7JJLmsH2AM5oFiCLcdH5 aQItqJ9kg3G/lcK6ESsi4nTrK/eE/KVE6BScHieev+vOrDmaEgbjri1WL11OBarSzv0D yXT4H8slqxwK0Lj5g6Xa269hdRGPCMEwm+pt0= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr4643729qcr.71.1301413049023; Tue, 29 Mar 2011 08:37:29 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 08:37:28 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> Date: Tue, 29 Mar 2011 16:37:28 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25cae7e3d77049fa0d619 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:35:53 -0000 --000e0cd25cae7e3d77049fa0d619 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > > Right, so we do need to standardize =93Service Level Interop=94. As has = been > pointed out its concrete enough you can actually do it and it would allow > the assembly of virtual worlds based upon it. > I think you misunderstood the point that I wrote, since you concluded the opposite. No, it does not follow that we need to standardize "service leve= l interop", because that does not give us interoperation between virtual worlds. It only allows us to standardize (as you correctly state) the "assembly of virtual worlds", one world at a time, instead of standardizing their interoperation. We don't need to standardize how VWs are assembled, it's not even our remit to do that because that's up to each provider. > > I don=92t know what it mean to have virtual world interop personally. > Why? It's very easy to understand, and I would guess that every VW user today who is using two or more virtual worlds like (say) OSgrid and InWorld= z can probably describe it very eloquently. I'll just repaste how I describe= d it yesterday: > We either have interoperability between worlds, in which an inhabitant ca= n > travel from one world to another and take their avatar and/or possessions > with them, or else we don't have that. It's black and white, and no amou= nt > of fudging about "service level interoperability" is going to overcome th= e > lack of VW interoperability as a user would understand it. Interoperability between VWs is truly a simple concept, and users are askin= g for it continually and woeing its absence daily. Its lack is so clear and self-evident and annoying that people even write export-import programs to try to alleviate the user "suffering" through its absence. Frankly, professing not to understand what it means is very bizarre. All I can suggest is, I'll try to clarify it further for you if you still don't understand what it means. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > *From:* vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] *On Behalf > Of *Morgaine > *Sent:* Monday, March 28, 2011 8:01 PM > *To:* vwrap@ietf.org > > *Subject:* Re: [vwrap] Status and future of the VWRAP working group > > > > Responding to two posts: > > > On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol wrote= : > > > If you want service only, I think there is code implemented already. > > > > Exactly as Dzonatas says. We don't need to work on protocols for interna= l > use by separate, isolated world services. We have those already. The > ingredient that is mostly missing from the Virtual World arena is > interoperability *between* such services, and that is the goal that has > sparked extremely wide interest. > > Right, so we do need to standardize =93Service Level Interop=94. As has = been > pointed out its concrete enough you can actually do it and it would allow > the assembly of virtual worlds based upon it. The point that some of th= is > exists is a good one, there=92s some existing practice and knowledge that= can > be leveraged. > > On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte < > sllists@boroon.dasgupta.ch> wrote: > > > d. interoperability between (instances of) any two virtual world systems > conforming to the (to be defined) VWRAP standard. > > > Exactly as Boroondas says. Indeed, that is the interoperability goal > sought by the majority of contributors here over the years, so this is > nothing new. It's the feature that virtual worlds don't yet have, and tha= t's > why it's worthwhile to work on it. > > Again, this is sensible and it=92s achieved via the =93standard services= =94 > defined above. I don=92t know what it mean to have virtual world interop > personally. It=92s a nice ideal but in practice differences in policy, > technology, etc, make it practically impossible to specify given the curr= ent > state of affairs. We can=92t even agree on a the data description pro= tocol > let alone how to handle policy across VW systems. And that extends past > business policy into technical issues like: if an =93object=94 is script= ed how > does that transfer to another VW. Who allocates the script resources. An= d > of course there=92s also creator=92s rights vs. owner=92s rights. The li= st is > extremely long and we can=92t even agree on how services should talk and = which > there should be in a standard way. > > > > IMO, the effort should focus on Service Level interoperability and the > definition of a few fundamental building block services: i.e user service= , > inventory service, asset service. I=92d leave the simulator piece off fo= r > now. If we get those right you can start to share user information betwe= en > =93virtual worlds=94, locate and access inventory and define an objects > characteristics inside a simulator. And the simulator piece can evolve > until its ready to be standardized. > > Mike > > > --000e0cd25cae7e3d77049fa0d619 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) <mike.dickson@hp.com>= wrote:


Right, so we do need to standardize =93Service Level Interop=94.=A0 As has been= =20 pointed out its concrete enough you can actually do it and it would=20 allow the assembly of virtual worlds based upon it.

<= /div>


I think you misunderstood the point that I w= rote, since you concluded the opposite.=A0 No, it does not follow that we n= eed to standardize "service level interop", because that does not= give us interoperation between virtual worlds.=A0 It only allows us to sta= ndardize (as you correctly state) the "assembly of virtual worlds"= ;, one world at a time, instead of standardizing their interoperation.=A0 W= e don't need to standardize how VWs are assembled, it's not even ou= r remit to do that because that's up to each provider.


I don=92t know what it mean to h= ave virtual world interop=20 personally.


Why?=A0 It's ve= ry easy to understand, and I would guess that every VW user today who is us= ing two or more virtual worlds like (say) OSgrid and InWorldz can probably = describe it very eloquently.=A0 I'll just repaste how I described it ye= sterday:=A0


We either have interoperability between worlds, in which an=20 inhabitant can travel from one world to another and take their avatar=20 and/or possessions with them, or else we don't have that.=A0 It's b= lack=20 and white, and no amount of fudging about "service level=20 interoperability" is going to overcome the lack of VW interoperability= =20 as a user would understand it.


Interoperability between= VWs is truly a simple concept, and users are asking for it continually and= woeing its absence daily.=A0 Its lack is so clear and self-evident and ann= oying that people even write export-import programs to try to alleviate the= user "suffering" through its absence.=A0 Frankly, professing not= to understand what it means is very bizarre.=A0 All I can suggest is, I= 9;ll try to clarify it further for you if you still don't understand wh= at it means.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)= <mike.dickson@= hp.com> wrote:

From: vwrap-bounces@iet= f.org [mailto:vwrap-bounces@ietf.org] On Behalf Of Morgaine
Sent: Monday, March 28, 2011 8:01 PM
To: vwrap@ietf.org


= Subject: Re: [vwrap] Status and future of the VWRAP working group

=A0

Responding = to two posts:



On Tue, Mar 29, 2011 at 12:13 AM= , Dzonatas Sol <= dzonatas@gmail.com> wrote:

If you want service only, I think = there is code implemented already.



Exactly as Dzonatas says.=A0 We don't need to wo= rk on protocols for internal use by separate, isolated world services.=A0 W= e have those already.=A0 The ingredient that is mostly missing from the Vir= tual World arena is interoperability between such services, a= nd that is the goal that has sparked extremely wide interest.

Right, = so we do need to standardize =93Service Level Interop=94.=A0 As has been po= inted out its concrete enough you can actually do it and it would allow the= assembly of virtual worlds based upon it.=A0=A0 The point that some of thi= s exists is a good one, there=92s some existing practice and knowledge that= can be leveraged.=A0


On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte= <sllist= s@boroon.dasgupta.ch> wrote:


d. interoperability between (i= nstances of) any two virtual world systems
conforming to the (to be defi= ned) VWRAP standard.


Exactly as Boroondas says.=A0 Indeed, that is the interoperability goal= sought by the majority of contributors here over the years, so this is not= hing new. It's the feature that virtual worlds don't yet have, and = that's why it's worthwhile to work on it.

Again, this is sensible and it=92s achieved via the= =93standard services=94 defined above.=A0 I don=92t know what it mean to h= ave virtual world interop personally.=A0 It=92s a nice ideal but in practic= e differences in policy, technology, etc, make it practically impossible to= specify given the current state of =A0affairs.=A0 =A0=A0We can=92t even ag= ree on a the data description protocol let alone how to handle policy acros= s VW systems. =A0And that extends past business policy into technical issue= s like: if an =93object=94 =A0is scripted how does that transfer to another= VW. Who allocates the script resources.=A0 And of course there=92s also cr= eator=92s rights vs. owner=92s rights.=A0 The list is extremely long and we= can=92t even agree on how services should talk and which there should be i= n a standard way.

=A0

IMO, the effort should focus on Service Level interoperability= and the definition of a few fundamental building block services: i.e user = service, inventory service, asset service.=A0 I=92d leave the simulator pie= ce off for now.=A0 If we get those right you can start to share user inform= ation between =93virtual worlds=94, locate and access inventory and define = an objects characteristics inside a simulator.=A0 And the simulator piece c= an evolve until its ready to be standardized.

Mike

=A0


--000e0cd25cae7e3d77049fa0d619-- From morgaine.dinova@googlemail.com Tue Mar 29 08:45:11 2011 Return-Path: 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 7C4523A687E for ; Tue, 29 Mar 2011 08:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 U5l5drjPczrI for ; Tue, 29 Mar 2011 08:45:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 620EC3A692D for ; Tue, 29 Mar 2011 08:45:09 -0700 (PDT) Received: by qwg5 with SMTP id 5so235786qwg.31 for ; Tue, 29 Mar 2011 08:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0rlfFP9nIejrcw9WmL/UDR5/XiLK4TIgq3mFRTT+cJk=; b=nR9gJqRoOTqj9A1s+vbn5adQULkZW6kOVpezLgZvwrLrG5yQa/krH5BHQacLvPEDfz nfNLe+S8KzVwCQ3AjAjhql9ONeXY9WbwSqC19FhfKf7KU0m4y1vajdoED2mmC0QEeGa5 JIcLVEe2VdbHhgyYUIpt8ICcWIjwtnauGU/pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gthAmN+N9p7DI6vgxKTBp85ghF/bMqdwjNHFbGVXqPb/K4VZRzX0hYRUpfo+0XGFdN bGd6Lc7hgxEFcBKJzRd/EzliWs34SQ8qmFJPeq1UfRJeBHMVjdx4MRlseFQGLGDJ0CVs U7uFaYFNj9gucA7BNQzNLjhM7IvJBRDjSe9yQ= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr4654449qcr.71.1301413607464; Tue, 29 Mar 2011 08:46:47 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 08:46:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 16:46:47 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caec75fa5049fa0f75f Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:45:11 -0000 --000e0cd25caec75fa5049fa0f75f Content-Type: text/plain; charset=ISO-8859-1 Izzy, several months ago on this list I was discussing exactly that issue with Joshua, highlighting how multiple asset services being handled simultaneously by regions and clients is the scalable way of achieving virtual tourism of visitors from multiple separate worlds to a central "tourist world". Those tourists each have asset services back in their home worlds or on 3rd party asset services, and on arriving in the tourist zone the region needs to hand out references to assets in all those remote asset services for the clients to be able to render all the people present with their correct avatars and possessions. So the simple answer is "No, no assumption of single asset service." That would not be a scalable design anyway. Morgaine. ======================== On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis wrote: > Starting new thread as the previous one is becoming too unwieldily. > > Morgaine said: > > We either have interoperability between worlds, in which an inhabitant > can travel from one world to another and take their avatar and/or > possessions with them, or else we don't have that. It's black and white, > and no amount of fudging about "service level interoperability" is going to > overcome the lack of VW interoperability as a user would understand it. > > The world is full of shades of grey. > > Is there an assumption that an Avatar has/uses one (and only one?) > "Asset Service" -- that I have a single repository of possessions to > take? Can I have and use different asset services? Can I use multiple > asset services? Can people share? > > - Izzy > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --000e0cd25caec75fa5049fa0f75f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Izzy, several months ago on this list I was discussing exactly that issue w= ith Joshua, highlighting how multiple asset services being handled simultan= eously by regions and clients is the scalable way of achieving virtual tour= ism of visitors from multiple separate worlds to a central "tourist wo= rld".

Those tourists each have asset services back in their home worlds or on= 3rd party asset services, and on arriving in the tourist zone the region n= eeds to hand out references to assets in all those remote asset services fo= r the clients to be able to render all the people present with their correc= t avatars and possessions.

So the simple answer is "No, no assumption of single asset service= ."=A0 That would not be a scalable design anyway.


Morgaine.=





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D


On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis <izzyalanis@gmail.com> wrote:=
Starting new thread as the previous one is becoming too unwieldily.

Morgaine said:
> We either have interoperability between worlds, in which an inhabitant= can travel from one world to another and take their avatar and/or possessi= ons with them, or else we don't have that. =A0It's black and white,= and no amount of fudging about "service level interoperability" = is going to overcome the lack of VW interoperability as a user would unders= tand it.

The world is full of shades of grey.

Is there an assumption that an Avatar has/uses one (and only one?)
"Asset Service" -- that I have a single repository of possessions= to
take? Can I have and use different asset services? Can I use multiple
asset services? Can people share?

=A0- Izzy
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--000e0cd25caec75fa5049fa0f75f-- From izzyalanis@gmail.com Tue Mar 29 08:45:17 2011 Return-Path: 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 2A7BF3A6A47 for ; Tue, 29 Mar 2011 08:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ZWOzrSRx9S1i for ; Tue, 29 Mar 2011 08:45:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8008C3A687E for ; Tue, 29 Mar 2011 08:45:15 -0700 (PDT) Received: by fxm15 with SMTP id 15so356720fxm.31 for ; Tue, 29 Mar 2011 08:46:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EQdX9volOAlsPmO3I6Nnmaj19AS9PsPeSe3W0t6+3r0=; b=PTk2O1nt+DemG8yXI3+/FC7kCdb5MVnraOTPOtkXOdTmqT8SOODRoB/F9p8smdvvb5 vzDfbdN/HgKAgbWM63soLfahmpVB1tRNtZH5hN8mYV/G2Tao/GaphT+QQTIJJNIKnYVz PeC74WUtWg4Xoy5JWeijq4inyVgnoT0Jw4yp0= 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 :cc:content-type:content-transfer-encoding; b=C6to8AhxPCwhDUL0tkJK3hjsyJ8/+/dx+4nJuYOrlxermW5BRtFbEupl5J5fG3eqtM bwMm4uF3snYjjWjc9T2liyM+mt1lKghHWYWCn4sdW79ikfOl8bwt5KCy8JmKrGKMLh2C nta68hcMkJf5TY5Wg+6BUUAkkHuJ8oZY4UGCg= MIME-Version: 1.0 Received: by 10.223.97.196 with SMTP id m4mr392348fan.105.1301413603224; Tue, 29 Mar 2011 08:46:43 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Tue, 29 Mar 2011 08:46:42 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> Date: Tue, 29 Mar 2011 11:46:42 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:45:17 -0000 I'll second Mike's comment: I don=92t know what it mean to have virtual world interop personally. Do I have to be able to teleport from one world to the next within the same viewer to qualify as "interop"? Or would it be OK if I was able to log in using different viewers/clients as long as my 'identity' was maintained? What if I had to have separate identities between virtual worlds, but could still access my bank of assets? What if I could maintain the concept of "identity" but not transfer assets/use a particular asset service? What if I couldn't access my assets from a particular asset service in a particular virtual world due to policy reasons (e.g. virtual world "A" doesn't like asset service provider "B")? - Izzy On Tue, Mar 29, 2011 at 11:37 AM, Morgaine wrote: > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) > wrote: >> >> Right, so we do need to standardize =93Service Level Interop=94.=A0 As h= as been >> pointed out its concrete enough you can actually do it and it would allo= w >> the assembly of virtual worlds based upon it. > > I think you misunderstood the point that I wrote, since you concluded the > opposite.=A0 No, it does not follow that we need to standardize "service = level > interop", because that does not give us interoperation between virtual > worlds.=A0 It only allows us to standardize (as you correctly state) the > "assembly of virtual worlds", one world at a time, instead of standardizi= ng > their interoperation.=A0 We don't need to standardize how VWs are assembl= ed, > it's not even our remit to do that because that's up to each provider. > >> >> >> I don=92t know what it mean to have virtual world interop personally. > > Why?=A0 It's very easy to understand, and I would guess that every VW use= r > today who is using two or more virtual worlds like (say) OSgrid and InWor= ldz > can probably describe it very eloquently.=A0 I'll just repaste how I desc= ribed > it yesterday: > >> >> We either have interoperability between worlds, in which an inhabitant c= an >> travel from one world to another and take their avatar and/or possession= s >> with them, or else we don't have that.=A0 It's black and white, and no a= mount >> of fudging about "service level interoperability" is going to overcome t= he >> lack of VW interoperability as a user would understand it. > > Interoperability between VWs is truly a simple concept, and users are ask= ing > for it continually and woeing its absence daily.=A0 Its lack is so clear = and > self-evident and annoying that people even write export-import programs t= o > try to alleviate the user "suffering" through its absence.=A0 Frankly, > professing not to understand what it means is very bizarre.=A0 All I can > suggest is, I'll try to clarify it further for you if you still don't > understand what it means. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) > wrote: >> >> From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf O= f >> Morgaine >> Sent: Monday, March 28, 2011 8:01 PM >> To: vwrap@ietf.org >> >> Subject: Re: [vwrap] Status and future of the VWRAP working group >> >> >> >> Responding to two posts: >> >> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol wrot= e: >> >> If you want service only, I think there is code implemented already. >> >> Exactly as Dzonatas says.=A0 We don't need to work on protocols for inte= rnal >> use by separate, isolated world services.=A0 We have those already.=A0 T= he >> ingredient that is mostly missing from the Virtual World arena is >> interoperability between such services, and that is the goal that has >> sparked extremely wide interest. >> >> Right, so we do need to standardize =93Service Level Interop=94.=A0 As h= as been >> pointed out its concrete enough you can actually do it and it would allo= w >> the assembly of virtual worlds based upon it.=A0=A0 The point that some = of this >> exists is a good one, there=92s some existing practice and knowledge tha= t can >> be leveraged. >> >> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte >> wrote: >> >> d. interoperability between (instances of) any two virtual world systems >> conforming to the (to be defined) VWRAP standard. >> >> Exactly as Boroondas says.=A0 Indeed, that is the interoperability goal >> sought by the majority of contributors here over the years, so this is >> nothing new. It's the feature that virtual worlds don't yet have, and th= at's >> why it's worthwhile to work on it. >> >> Again, this is sensible and it=92s achieved via the =93standard services= =94 >> defined above.=A0 I don=92t know what it mean to have virtual world inte= rop >> personally.=A0 It=92s a nice ideal but in practice differences in policy= , >> technology, etc, make it practically impossible to specify given the cur= rent >> state of =A0affairs.=A0 =A0=A0We can=92t even agree on a the data descri= ption protocol >> let alone how to handle policy across VW systems. =A0And that extends pa= st >> business policy into technical issues like: if an =93object=94 =A0is scr= ipted how >> does that transfer to another VW. Who allocates the script resources.=A0= And >> of course there=92s also creator=92s rights vs. owner=92s rights.=A0 The= list is >> extremely long and we can=92t even agree on how services should talk and= which >> there should be in a standard way. >> >> >> >> IMO, the effort should focus on Service Level interoperability and the >> definition of a few fundamental building block services: i.e user servic= e, >> inventory service, asset service.=A0 I=92d leave the simulator piece off= for >> now.=A0 If we get those right you can start to share user information be= tween >> =93virtual worlds=94, locate and access inventory and define an objects >> characteristics inside a simulator.=A0 And the simulator piece can evolv= e >> until its ready to be standardized. >> >> Mike >> >> > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From izzyalanis@gmail.com Tue Mar 29 08:53:17 2011 Return-Path: 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 9778828C0F0 for ; Tue, 29 Mar 2011 08:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 yTxj3T7qHnM9 for ; Tue, 29 Mar 2011 08:53:16 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id C875728C0FB for ; Tue, 29 Mar 2011 08:53:06 -0700 (PDT) Received: by fxm15 with SMTP id 15so364067fxm.31 for ; Tue, 29 Mar 2011 08:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RFEiooB/qcZWky355ibgpVZd4X3CYAmxo9MQrhPLOVE=; b=tkSAAf9MT4XnMNkJqsZRIJyvI6Q0bAKtwuz2d/6Tlhr/ADvaPQOOHASGx2QrSkoBKc V8JSHSk9n3gvL1LGAKx2c6qd27jqlzUQXjvyYkAjkxoy0+N6fAXE0HR5BwzIYKT4SUJI IDBYKnZ5SCibyAXNEaM8fBz74GS7ujnMQvLpw= 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 :cc:content-type:content-transfer-encoding; b=Rm/eJ1xj6gsO18HeHvGGtco4EMbfnEsSol521zEyFy6JMba5IvL1FsgHvyKLCzZCmq 7vuYOdzVhGuCCfGx8tpoRTU88HFrVEGTrokjAGF2Us6dp40NMiVrticgFQuqVfor5pzF Zocz5/+v6My+plxca5Nqd9xj7uxsjaZ18cCpQ= MIME-Version: 1.0 Received: by 10.223.25.197 with SMTP id a5mr1569403fac.29.1301414083013; Tue, 29 Mar 2011 08:54:43 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Tue, 29 Mar 2011 08:54:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 11:54:42 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 15:53:17 -0000 I mean to question the cardinality of the relationship between avatar/identity and asset service(s). Does an avatar only have a single home asset server, or can I simultaneously access assets provided by 3rd party asset services? Can I access "AssetServicesRUS (TM)" and services provided by "Acme Asset Services, LLC"? Or is my identity intractably linked with a particular asset service provider? On Tue, Mar 29, 2011 at 11:46 AM, Morgaine wrote: > Izzy, several months ago on this list I was discussing exactly that issue > with Joshua, highlighting how multiple asset services being handled > simultaneously by regions and clients is the scalable way of achieving > virtual tourism of visitors from multiple separate worlds to a central > "tourist world". > > Those tourists each have asset services back in their home worlds or on 3= rd > party asset services, and on arriving in the tourist zone the region need= s > to hand out references to assets in all those remote asset services for t= he > clients to be able to render all the people present with their correct > avatars and possessions. > > So the simple answer is "No, no assumption of single asset service."=A0 T= hat > would not be a scalable design anyway. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis wrote= : >> >> Starting new thread as the previous one is becoming too unwieldily. >> >> Morgaine said: >> > We either have interoperability between worlds, in which an inhabitant >> > can travel from one world to another and take their avatar and/or >> > possessions with them, or else we don't have that. =A0It's black and w= hite, >> > and no amount of fudging about "service level interoperability" is goi= ng to >> > overcome the lack of VW interoperability as a user would understand it= . >> >> The world is full of shades of grey. >> >> Is there an assumption that an Avatar has/uses one (and only one?) >> "Asset Service" -- that I have a single repository of possessions to >> take? Can I have and use different asset services? Can I use multiple >> asset services? Can people share? >> >> =A0- Izzy >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap > > From morgaine.dinova@googlemail.com Tue Mar 29 09:04:53 2011 Return-Path: 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 399D53A6862 for ; Tue, 29 Mar 2011 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 vm5YQ3nzLQFC for ; Tue, 29 Mar 2011 09:04:51 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 01BCE3A695D for ; Tue, 29 Mar 2011 09:04:50 -0700 (PDT) Received: by qyk7 with SMTP id 7so237401qyk.10 for ; Tue, 29 Mar 2011 09:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rImll2d0qOQ4ZHzZ/YWi8hFcxODDggwVdc8RFnGcOY4=; b=FBsxwp4gtEdUv3PYZBV7VJnLqIAigs5zKBsr1+iFwI44AYv0x3Ef59+/MbIX0V4P5i 5ULi6/+YBeDFhr0J4ceiocsXCthtrok15pnb7ZgPyQ08zd+/PqFEpLEYjhe9sNSbbkDk rkIBiRB6BWIc1+j11copYWo5+mTGDoTCCGBZA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pJVr1SJGDeE49/8XxrnM093z1PCNOrgusdwMo0wHjmkTa1eDWPPmR8HQsB1OBIgEtJ PRUFMUg/dosGXbIv2fOtI+pV2MulNvASUoK0i5REYuFHo1HOByl35Ut6wq/U3J9bCTgS yTVVlRh7j/c6NmDSYJ/Dt2aOJcCKuzYIQ9oFc= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr2497414qcd.147.1301414788914; Tue, 29 Mar 2011 09:06:28 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 09:06:28 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> Date: Tue, 29 Mar 2011 17:06:28 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c032dd88049fa13e94 Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:04:53 -0000 --0016368340c032dd88049fa13e94 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Izzy, it's truly simple, and I see that you understand it. You have listed a number of possible restrictions or constraints that could be applied to limit or modify interop between worlds, but your list of questions is only meaningful because you already understand what interop between virtual worlds means at its most open and powerful. You are there already in your understanding! :-) When our protocols support such interoperation between virtual worlds, restrictions can of course be placed on that interoperation by world providers, just like an email service provider can place restrictions on wh= o can access their service, where people can send emails, the kinds of conten= t permitted, and so on. It's totally normal for services on the Internet to apply their own restrictions, and it would be no different for interoperabl= e VWs. Likewise for us, we know what interoperation between virtual worlds means i= n concept (I described it in simple user language in my previous email), but any individual deployment might reduce or limit that based on local policy. It's not up to us to mandate local policy, but it is up to us to create a protocol that provides interoperation between virtual worlds so that it's available for those worlds that do want to interoperate. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D On Tue, Mar 29, 2011 at 4:46 PM, Izzy Alanis wrote: > I'll second Mike's comment: I don=92t know what it mean to have virtual > world interop personally. > > Do I have to be able to teleport from one world to the next within the > same viewer to qualify as "interop"? Or would it be OK if I was able > to log in using different viewers/clients as long as my 'identity' was > maintained? What if I had to have separate identities between virtual > worlds, but could still access my bank of assets? What if I could > maintain the concept of "identity" but not transfer assets/use a > particular asset service? What if I couldn't access my assets from a > particular asset service in a particular virtual world due to policy > reasons (e.g. virtual world "A" doesn't like asset service provider > "B")? > > - Izzy > > On Tue, Mar 29, 2011 at 11:37 AM, Morgaine > wrote: > > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) > > wrote: > >> > >> Right, so we do need to standardize =93Service Level Interop=94. As h= as > been > >> pointed out its concrete enough you can actually do it and it would > allow > >> the assembly of virtual worlds based upon it. > > > > I think you misunderstood the point that I wrote, since you concluded t= he > > opposite. No, it does not follow that we need to standardize "service > level > > interop", because that does not give us interoperation between virtual > > worlds. It only allows us to standardize (as you correctly state) the > > "assembly of virtual worlds", one world at a time, instead of > standardizing > > their interoperation. We don't need to standardize how VWs are > assembled, > > it's not even our remit to do that because that's up to each provider. > > > >> > >> > >> I don=92t know what it mean to have virtual world interop personally. > > > > Why? It's very easy to understand, and I would guess that every VW use= r > > today who is using two or more virtual worlds like (say) OSgrid and > InWorldz > > can probably describe it very eloquently. I'll just repaste how I > described > > it yesterday: > > > >> > >> We either have interoperability between worlds, in which an inhabitant > can > >> travel from one world to another and take their avatar and/or > possessions > >> with them, or else we don't have that. It's black and white, and no > amount > >> of fudging about "service level interoperability" is going to overcome > the > >> lack of VW interoperability as a user would understand it. > > > > Interoperability between VWs is truly a simple concept, and users are > asking > > for it continually and woeing its absence daily. Its lack is so clear > and > > self-evident and annoying that people even write export-import programs > to > > try to alleviate the user "suffering" through its absence. Frankly, > > professing not to understand what it means is very bizarre. All I can > > suggest is, I'll try to clarify it further for you if you still don't > > understand what it means. > > > > > > Morgaine. > > > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) > > wrote: > >> > >> From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf > Of > >> Morgaine > >> Sent: Monday, March 28, 2011 8:01 PM > >> To: vwrap@ietf.org > >> > >> Subject: Re: [vwrap] Status and future of the VWRAP working group > >> > >> > >> > >> Responding to two posts: > >> > >> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol > wrote: > >> > >> If you want service only, I think there is code implemented already. > >> > >> Exactly as Dzonatas says. We don't need to work on protocols for > internal > >> use by separate, isolated world services. We have those already. The > >> ingredient that is mostly missing from the Virtual World arena is > >> interoperability between such services, and that is the goal that has > >> sparked extremely wide interest. > >> > >> Right, so we do need to standardize =93Service Level Interop=94. As h= as > been > >> pointed out its concrete enough you can actually do it and it would > allow > >> the assembly of virtual worlds based upon it. The point that some of > this > >> exists is a good one, there=92s some existing practice and knowledge t= hat > can > >> be leveraged. > >> > >> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte > >> wrote: > >> > >> d. interoperability between (instances of) any two virtual world syste= ms > >> conforming to the (to be defined) VWRAP standard. > >> > >> Exactly as Boroondas says. Indeed, that is the interoperability goal > >> sought by the majority of contributors here over the years, so this is > >> nothing new. It's the feature that virtual worlds don't yet have, and > that's > >> why it's worthwhile to work on it. > >> > >> Again, this is sensible and it=92s achieved via the =93standard servic= es=94 > >> defined above. I don=92t know what it mean to have virtual world inte= rop > >> personally. It=92s a nice ideal but in practice differences in policy= , > >> technology, etc, make it practically impossible to specify given the > current > >> state of affairs. We can=92t even agree on a the data description > protocol > >> let alone how to handle policy across VW systems. And that extends pa= st > >> business policy into technical issues like: if an =93object=94 is scr= ipted > how > >> does that transfer to another VW. Who allocates the script resources. > And > >> of course there=92s also creator=92s rights vs. owner=92s rights. The= list is > >> extremely long and we can=92t even agree on how services should talk a= nd > which > >> there should be in a standard way. > >> > >> > >> > >> IMO, the effort should focus on Service Level interoperability and the > >> definition of a few fundamental building block services: i.e user > service, > >> inventory service, asset service. I=92d leave the simulator piece off= for > >> now. If we get those right you can start to share user information > between > >> =93virtual worlds=94, locate and access inventory and define an object= s > >> characteristics inside a simulator. And the simulator piece can evolv= e > >> until its ready to be standardized. > >> > >> Mike > >> > >> > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > --0016368340c032dd88049fa13e94 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Izzy, it's truly simple, and I see that you understand it.=A0 You have = listed a number of possible restrictions or constraints that could be appli= ed to limit or modify interop between worlds, but your list of questions is= only meaningful because you already understand what interop between virtua= l worlds means at its most open and powerful.

You are there already in your understanding! :-)

When our protoc= ols support such interoperation between virtual worlds, restrictions can of= course be placed on that interoperation by world providers, just like an e= mail service provider can place restrictions on who can access their servic= e, where people can send emails, the kinds of content permitted, and so on.= =A0 It's totally normal for services on the Internet to apply their own= restrictions, and it would be no different for interoperable VWs.

Likewise for us, we know what interoperation between virtual worlds mea= ns in concept (I described it in simple user language in my previous email)= , but any individual deployment might reduce or limit that based on local p= olicy.=A0 It's not up to us to mandate local policy, but it is up to us= to create a protocol that provides interoperation between virtual worlds s= o that it's available for those worlds that do want to interoperate.

Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Tue, Mar 29, 2011 at 4:46 PM, Izzy Alanis <= izzyalanis@gmail.com>= wrote:
I'll second M= ike's comment: I don=92t know what it mean to have virtual
world interop personally.

Do I have to be able to teleport from one world to the next within the
same viewer to qualify as "interop"? Or would it be OK if I was a= ble
to log in using different viewers/clients as long as my 'identity' = was
maintained? What if I had to have separate identities between virtual
worlds, but could still access my bank of assets? What if I could
maintain the concept of "identity" but not transfer assets/use a<= br> particular asset service? What if I couldn't access my assets from a particular asset service in a particular virtual world due to policy
reasons (e.g. virtual world "A" doesn't like asset service pr= ovider
"B")?

=A0- Izzy

On Tue, Mar 29, 2011 at 11:37 AM, Morgaine
<morgaine.dinova@googl= email.com> wrote:
> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> <mike.dickson@hp.com>= wrote:
>>
>> Right, so we do need to standardize =93Service Level Interop=94.= =A0 As has been
>> pointed out its concrete enough you can actually do it and it woul= d allow
>> the assembly of virtual worlds based upon it.
>
> I think you misunderstood the point that I wrote, since you concluded = the
> opposite.=A0 No, it does not follow that we need to standardize "= service level
> interop", because that does not give us interoperation between vi= rtual
> worlds.=A0 It only allows us to standardize (as you correctly state) t= he
> "assembly of virtual worlds", one world at a time, instead o= f standardizing
> their interoperation.=A0 We don't need to standardize how VWs are = assembled,
> it's not even our remit to do that because that's up to each p= rovider.
>
>>
>>
>> I don=92t know what it mean to have virtual world interop personal= ly.
>
> Why?=A0 It's very easy to understand, and I would guess that every= VW user
> today who is using two or more virtual worlds like (say) OSgrid and In= Worldz
> can probably describe it very eloquently.=A0 I'll just repaste how= I described
> it yesterday:
>
>>
>> We either have interoperability between worlds, in which an inhabi= tant can
>> travel from one world to another and take their avatar and/or poss= essions
>> with them, or else we don't have that.=A0 It's black and w= hite, and no amount
>> of fudging about "service level interoperability" is goi= ng to overcome the
>> lack of VW interoperability as a user would understand it.
>
> Interoperability between VWs is truly a simple concept, and users are = asking
> for it continually and woeing its absence daily.=A0 Its lack is so cle= ar and
> self-evident and annoying that people even write export-import program= s to
> try to alleviate the user "suffering" through its absence.= =A0 Frankly,
> professing not to understand what it means is very bizarre.=A0 All I c= an
> suggest is, I'll try to clarify it further for you if you still do= n't
> understand what it means.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
>
> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software)
> <mike.dickson@hp.com>= wrote:
>>
>> From: vwrap-bounces@ietf= .org [mailto:vwrap-bounces@ie= tf.org] On Behalf Of
>> Morgaine
>> Sent: Monday, March 28, 2011 8:01 PM
>> To: vwrap@ietf.org
>>
>> Subject: Re: [vwrap] Status and future of the VWRAP working group<= br> >>
>>
>>
>> Responding to two posts:
>>
>> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
>>
>> If you want service only, I think there is code implemented alread= y.
>>
>> Exactly as Dzonatas says.=A0 We don't need to work on protocol= s for internal
>> use by separate, isolated world services.=A0 We have those already= .=A0 The
>> ingredient that is mostly missing from the Virtual World arena is<= br> >> interoperability between such services, and that is the goal that = has
>> sparked extremely wide interest.
>>
>> Right, so we do need to standardize =93Service Level Interop=94.= =A0 As has been
>> pointed out its concrete enough you can actually do it and it woul= d allow
>> the assembly of virtual worlds based upon it.=A0=A0 The point that= some of this
>> exists is a good one, there=92s some existing practice and knowled= ge that can
>> be leveraged.
>>
>> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte
>> <sllists@boroon.d= asgupta.ch> wrote:
>>
>> d. interoperability between (instances of) any two virtual world s= ystems
>> conforming to the (to be defined) VWRAP standard.
>>
>> Exactly as Boroondas says.=A0 Indeed, that is the interoperability= goal
>> sought by the majority of contributors here over the years, so thi= s is
>> nothing new. It's the feature that virtual worlds don't ye= t have, and that's
>> why it's worthwhile to work on it.
>>
>> Again, this is sensible and it=92s achieved via the =93standard se= rvices=94
>> defined above.=A0 I don=92t know what it mean to have virtual worl= d interop
>> personally.=A0 It=92s a nice ideal but in practice differences in = policy,
>> technology, etc, make it practically impossible to specify given t= he current
>> state of =A0affairs.=A0 =A0=A0We can=92t even agree on a the data = description protocol
>> let alone how to handle policy across VW systems. =A0And that exte= nds past
>> business policy into technical issues like: if an =93object=94 =A0= is scripted how
>> does that transfer to another VW. Who allocates the script resourc= es.=A0 And
>> of course there=92s also creator=92s rights vs. owner=92s rights.= =A0 The list is
>> extremely long and we can=92t even agree on how services should ta= lk and which
>> there should be in a standard way.
>>
>>
>>
>> IMO, the effort should focus on Service Level interoperability and= the
>> definition of a few fundamental building block services: i.e user = service,
>> inventory service, asset service.=A0 I=92d leave the simulator pie= ce off for
>> now.=A0 If we get those right you can start to share user informat= ion between
>> =93virtual worlds=94, locate and access inventory and define an ob= jects
>> characteristics inside a simulator.=A0 And the simulator piece can= evolve
>> until its ready to be standardized.
>>
>> Mike
>>
>>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

--0016368340c032dd88049fa13e94-- From morgaine.dinova@googlemail.com Tue Mar 29 09:17:09 2011 Return-Path: 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 8D9C83A6981 for ; Tue, 29 Mar 2011 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.938 X-Spam-Level: X-Spam-Status: No, score=-2.938 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 Iwj7YHh62oAq for ; Tue, 29 Mar 2011 09:17:08 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 4391D3A6863 for ; Tue, 29 Mar 2011 09:17:08 -0700 (PDT) Received: by qyk29 with SMTP id 29so1984507qyk.10 for ; Tue, 29 Mar 2011 09:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DG4wedJN5rv2bRV/h7o+vw/IxQy5qaM+uP101O4ZafQ=; b=G2QKMg+s8aVYi8ObQv+lHbzJ8be6aeaNeZ30lyyCfolY7P6YX/cbljXC2N+Cz7b25j /81k9YgJEp17x+PHQKUEf7SJpJeh7k4x98X8T8zlEAh4j9GyS+vAEbneG8EH09WMPBGy pNy9Auv/sOQfQObxFaa/G7PsWu5FKALarODNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sU18mDkOo/XtDEEeDwR6CqwEj7TIkaXp002tpTRgQKQLau3TiWP8U3RGr74NFgtNTx 4YeOiMWduF1OudBBuT7aI1j+8K7CM/4Gr1/cZMfL139HLNmgWtOmyOf/wKoVZa6F8DFu FTaG/dy4JgtbJ9YjZsPz8MjUYGF4S20Wrs9Vg= MIME-Version: 1.0 Received: by 10.224.137.32 with SMTP id u32mr4885144qat.322.1301415524979; Tue, 29 Mar 2011 09:18:44 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 09:18:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 17:18:43 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00151748db041254de049fa16ac0 Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:17:09 -0000 --00151748db041254de049fa16ac0 Content-Type: text/plain; charset=ISO-8859-1 Any number of asset services per user. We generally frown on singletons, but a more important reason for "multiple" is that a given provider may limit your freedom to hold items in ways that you do not wish, so it's important that you be able to keep other stuff disallowed by that provider elsewhere. There are lots of other reasons for "multiple" too. For example it is very likely that people (power users at least) will want to set up an asset service for backups (either local or in the cloud), which will become ever more important as VWs contain more and more of our virtual items and backups become crucial. I hope that answers your question about cardinality. Morgaine. =============== On Tue, Mar 29, 2011 at 4:54 PM, Izzy Alanis wrote: > I mean to question the cardinality of the relationship between > avatar/identity and asset service(s). Does an avatar only have a > single home asset server, or can I simultaneously access assets > provided by 3rd party asset services? Can I access "AssetServicesRUS > (TM)" and services provided by "Acme Asset Services, LLC"? Or is my > identity intractably linked with a particular asset service provider? > > > On Tue, Mar 29, 2011 at 11:46 AM, Morgaine > wrote: > > Izzy, several months ago on this list I was discussing exactly that issue > > with Joshua, highlighting how multiple asset services being handled > > simultaneously by regions and clients is the scalable way of achieving > > virtual tourism of visitors from multiple separate worlds to a central > > "tourist world". > > > > Those tourists each have asset services back in their home worlds or on > 3rd > > party asset services, and on arriving in the tourist zone the region > needs > > to hand out references to assets in all those remote asset services for > the > > clients to be able to render all the people present with their correct > > avatars and possessions. > > > > So the simple answer is "No, no assumption of single asset service." > That > > would not be a scalable design anyway. > > > > > > Morgaine. > > > > > > > > > > > > ======================== > > > > > > On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis > wrote: > >> > >> Starting new thread as the previous one is becoming too unwieldily. > >> > >> Morgaine said: > >> > We either have interoperability between worlds, in which an inhabitant > >> > can travel from one world to another and take their avatar and/or > >> > possessions with them, or else we don't have that. It's black and > white, > >> > and no amount of fudging about "service level interoperability" is > going to > >> > overcome the lack of VW interoperability as a user would understand > it. > >> > >> The world is full of shades of grey. > >> > >> Is there an assumption that an Avatar has/uses one (and only one?) > >> "Asset Service" -- that I have a single repository of possessions to > >> take? Can I have and use different asset services? Can I use multiple > >> asset services? Can people share? > >> > >> - Izzy > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > > > > > --00151748db041254de049fa16ac0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any number of asset services per user.

We generally frown on singlet= ons, but a more important reason for "multiple" is that a given p= rovider may limit your freedom to hold items in ways that you do not wish, = so it's important that you be able to keep other stuff disallowed by th= at provider elsewhere.

There are lots of other reasons for "multiple" too.=A0 For ex= ample it is very likely that people (power users at least) will want to set= up an asset service for backups (either local or in the cloud), which will= become ever more important as VWs contain more and more of our virtual ite= ms and backups become crucial.

I hope that answers your question about cardinality.


Morgain= e.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=
On Tue, Mar 29, 2011 at 4:54 PM, Izzy Alanis <izzyalanis@gmail= .com> wrote:
I mean to questio= n the cardinality of the relationship between
avatar/identity and asset service(s). Does an avatar only have a
single home asset server, or can I simultaneously access assets
provided by 3rd party asset services? Can I access "AssetServicesRUS (TM)" and services provided by "Acme Asset Services, LLC"? O= r is my
identity intractably linked with a particular asset service provider?


On Tue, Mar 29, 2011 at 11:46 AM, Morgaine
<morgaine.dinova@googl= email.com> wrote:
> Izzy, several months ago on this list I was discussing exactly that is= sue
> with Joshua, highlighting how multiple asset services being handled > simultaneously by regions and clients is the scalable way of achieving=
> virtual tourism of visitors from multiple separate worlds to a central=
> "tourist world".
>
> Those tourists each have asset services back in their home worlds or o= n 3rd
> party asset services, and on arriving in the tourist zone the region n= eeds
> to hand out references to assets in all those remote asset services fo= r the
> clients to be able to render all the people present with their correct=
> avatars and possessions.
>
> So the simple answer is "No, no assumption of single asset servic= e."=A0 That
> would not be a scalable design anyway.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
>
>
> On Tue, Mar 29, 2011 at 3:58 PM, Izzy Alanis <izzyalanis@gmail.com> wrote:
>>
>> Starting new thread as the previous one is becoming too unwieldily= .
>>
>> Morgaine said:
>> > We either have interoperability between worlds, in which an i= nhabitant
>> > can travel from one world to another and take their avatar an= d/or
>> > possessions with them, or else we don't have that. =A0It&= #39;s black and white,
>> > and no amount of fudging about "service level interopera= bility" is going to
>> > overcome the lack of VW interoperability as a user would unde= rstand it.
>>
>> The world is full of shades of grey.
>>
>> Is there an assumption that an Avatar has/uses one (and only one?)=
>> "Asset Service" -- that I have a single repository of po= ssessions to
>> take? Can I have and use different asset services? Can I use multi= ple
>> asset services? Can people share?
>>
>> =A0- Izzy
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>
>

--00151748db041254de049fa16ac0-- From ohmeadhbh@gmail.com Tue Mar 29 09:37:08 2011 Return-Path: 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 A364028C0E9 for ; Tue, 29 Mar 2011 09:37:08 -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=[AWL=0.000, 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 y-s6MPw+yi9c for ; Tue, 29 Mar 2011 09:37:07 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4C21A28C0EA for ; Tue, 29 Mar 2011 09:37:07 -0700 (PDT) Received: by qwg5 with SMTP id 5so278227qwg.31 for ; Tue, 29 Mar 2011 09:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=TBUlR4vad5+xuD821I/+a3BoCM0jGSVZp/SCXpXslN0=; b=qU/L83F/aJGXJwGcFqiX5uYr07MY4ipckAXc57Qq0l7giPolHS4h5SmmXjdlE37d05 BvZH1rM35jGdDbcvrYhvJT6O4v/bUHNLpuFW5Ykv2A9Gp5k+Gow7RnW5X2l88eUtw42X 9QYEEg/h8Be59ZbqP2IYl02VoCJfJ7HSycZ04= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=aeK1TTYBKf7tNUuXqGQhFPzbgIVBYTDMY1VaQ3/O8NW3+HEmPPEiDnGGhU0nMKigFZ +Q9Bry+4qr4BhPFJbBq9bog452OOmtLwZoQx4KrF60fQBMn8jlOW3hSgLDlLaSv3z6dG 9VEnTO+tjrOgWTIJ4YWdPjJoY5T40IE/N0ZGM= Received: by 10.229.62.8 with SMTP id v8mr14688qch.33.1301416725225; Tue, 29 Mar 2011 09:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.81.210 with HTTP; Tue, 29 Mar 2011 09:38:24 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Tue, 29 Mar 2011 09:38:24 -0700 Message-ID: To: Izzy Alanis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:37:08 -0000 Hey Izzy, FWIW... despite what morgaine says, the original members of this group were actually interested in "service level interop." and here's the use case. part of the reason Linden was interested in open protocols was so we could attempt to become the center of a much larger virtual ecosystem. the vision we shared with some of our partners was a world where you could log into Second Life or OpenSIm instance with your facebook or twitter credentials. or google. or yahoo! or OSGrid or Linden / Second Life. we also wanted to allow individual organizations (either your corporate IT department or a commercial online service like the Wikimedia commons) to act as an asset server for your inventory. we wanted to give individual grid deployers (or even individual users) the ability to pick who routed their voice and audio packets. these are just a few examples of the use cases we wanted to support that we felt justified "service level interop." people who wanted to be able to walk from one world to the other, could still do that, but only if both virtual worlds supported enough services to move avatars between them. so "virtual worlds level interop" is less interesting, IMHO, since it requires participants to effectively implement all services if they want to participate in the virtual world. now... Linden, IBM and Intel seem to have de-prioritized their participation in this group, so it's certainly a valid thing to say "hey, let's focus on full-on VW interop." but ultimately, this will be limiting your participation to a much smaller community of deployers. and at the end of the day, you're going to have to specify services as... well... services, so the VW interop thing has always seemed like a red herring at worst and an artificial constraint at best. the current charter was developed at a time when "service level interop" was the assumption, which is why we split off each service into a different document. the charter was also too small a document to capture the assumptions of the types of systems we wanted to work with, which is why in 2009 Dave Crocker recommended we put a bare minimum in the charter with the understanding that the intro doc would expand that understanding. so... if peeps here want to continue with service level interop, that's fine. we _may_ be able to keep the same charter and even some parts of the intro doc. if we want to go with full-on interop between OpenSim instances, that will probably necessitate a change in the charter and definitely a change in the intro. just my 2 cents. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Mar 29, 2011 at 7:58 AM, Izzy Alanis wrote: > Starting new thread as the previous one is becoming too unwieldily. > > Morgaine said: >> We either have interoperability between worlds, in which an inhabitant c= an travel from one world to another and take their avatar and/or possession= s with them, or else we don't have that. =A0It's black and white, and no am= ount of fudging about "service level interoperability" is going to overcome= the lack of VW interoperability as a user would understand it. > > The world is full of shades of grey. > > Is there an assumption that an Avatar has/uses one (and only one?) > "Asset Service" -- that I have a single repository of possessions to > take? Can I have and use different asset services? Can I use multiple > asset services? Can people share? > > =A0- Izzy > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Tue Mar 29 09:50:53 2011 Return-Path: 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 371E63A6870 for ; Tue, 29 Mar 2011 09:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.456 X-Spam-Level: X-Spam-Status: No, score=-3.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 u5MwMgb3gWxp for ; Tue, 29 Mar 2011 09:50:51 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 5ED323A6A59 for ; Tue, 29 Mar 2011 09:50:51 -0700 (PDT) Received: by gyf3 with SMTP id 3so175099gyf.31 for ; Tue, 29 Mar 2011 09:52:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=g1WTN+sjg80VECab3bETO/457QHT5OhhDGd/R9y17SI=; b=ZgVGoTDce8BKxgRaJUIhThZAR552I3oc/5g0gvxFTdl3sacUWWVNa0xRBBE6U45OnM 7VE/chUbx7/vbp1RhPGkmIhhDp7ozRpNX3NPYCL7debwI9r3uNdF8HryuHhwLMYF/IJN MdihbaOmz/GETSwFHapMJYtyKY0d7rHvhHk0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xNmbI3c2+H/4EjLaqYqiSRq+MC/chf88DPoBCfv3BcgyBek0HCPDCzOMB1ImPsPY3m A2KPJFb706hWlRDJr91IcfN9yKpAQVv4teZpjsgIKKPn+d5gEmMYg7IQvAxyEuXe6zPB ttxLUESGM4JE02w8TrnveqCZXvKbD0zJIWV0c= Received: by 10.91.33.1 with SMTP id l1mr316249agj.207.1301417549338; Tue, 29 Mar 2011 09:52:29 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 8sm3764702iba.4.2011.03.29.09.52.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 09:52:28 -0700 (PDT) Message-ID: <4D920E50.7070500@gmail.com> Date: Tue, 29 Mar 2011 09:52:32 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 16:50:53 -0000 Always remember the use case of one business that has one public VW and their private asset server which any number of internal clients can connect to and publish assets to the public VW. Once any asset is published then any number of external clients could then see the asset, work on it, or maybe even get a local asset version of the published asset. Meadhbh Hamrick wrote: > Hey Izzy, > > FWIW... despite what morgaine says, the original members of this group > were actually interested in "service level interop." and here's the > use case. > > part of the reason Linden was interested in open protocols was so we > could attempt to become the center of a much larger virtual ecosystem. > the vision we shared with some of our partners was a world where you > could log into Second Life or OpenSIm instance with your facebook or > twitter credentials. or google. or yahoo! or OSGrid or Linden / Second > Life. we also wanted to allow individual organizations (either your > corporate IT department or a commercial online service like the > Wikimedia commons) to act as an asset server for your inventory. we > wanted to give individual grid deployers (or even individual users) > the ability to pick who routed their voice and audio packets. > > these are just a few examples of the use cases we wanted to support > that we felt justified "service level interop." > > people who wanted to be able to walk from one world to the other, > could still do that, but only if both virtual worlds supported enough > services to move avatars between them. > > so "virtual worlds level interop" is less interesting, IMHO, since it > requires participants to effectively implement all services if they > want to participate in the virtual world. > > now... Linden, IBM and Intel seem to have de-prioritized their > participation in this group, so it's certainly a valid thing to say > "hey, let's focus on full-on VW interop." but ultimately, this will be > limiting your participation to a much smaller community of deployers. > and at the end of the day, you're going to have to specify services > as... well... services, so the VW interop thing has always seemed like > a red herring at worst and an artificial constraint at best. > > the current charter was developed at a time when "service level > interop" was the assumption, which is why we split off each service > into a different document. the charter was also too small a document > to capture the assumptions of the types of systems we wanted to work > with, which is why in 2009 Dave Crocker recommended we put a bare > minimum in the charter with the understanding that the intro doc would > expand that understanding. > > so... if peeps here want to continue with service level interop, > that's fine. we _may_ be able to keep the same charter and even some > parts of the intro doc. if we want to go with full-on interop between > OpenSim instances, that will probably necessitate a change in the > charter and definitely a change in the intro. > > just my 2 cents. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Mar 29, 2011 at 7:58 AM, Izzy Alanis wrote: > >> Starting new thread as the previous one is becoming too unwieldily. >> >> Morgaine said: >> >>> We either have interoperability between worlds, in which an inhabitant can travel from one world to another and take their avatar and/or possessions with them, or else we don't have that. �It's black and white, and no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it. >>> >> The world is full of shades of grey. >> >> Is there an assumption that an Avatar has/uses one (and only one?) >> "Asset Service" -- that I have a single repository of possessions to >> take? Can I have and use different asset services? Can I use multiple >> asset services? Can people share? >> >> �- Izzy >> _______________________________________________ >> 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 > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Tue Mar 29 10:12:27 2011 Return-Path: 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 F217E3A6986 for ; Tue, 29 Mar 2011 10:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 f13bpKuntnpB for ; Tue, 29 Mar 2011 10:12:25 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id D69EF3A6A32 for ; Tue, 29 Mar 2011 10:12:24 -0700 (PDT) Received: by qyk7 with SMTP id 7so286586qyk.10 for ; Tue, 29 Mar 2011 10:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Aj81JpAqeZ3IJupazi7uJRnxCDCw/B/YpAec3bAQ1mg=; b=fzw9qhEjMfy62P+1nfj7W4yRGGkpS0m4C0Me/6e0oomN4DmnYNBrpO32CqjMfaCKBc 0CNZonzL/NXVAyjd0MJt5hJ2bslzeFbI42to++ODNBOKsHXpyCEMBJdt7fyGYKHloh6k piem/6+2m3XwRWun5Vnj+AJNytiUd9tCA6xx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Bnk/lBb8ykQjgMNTWDMgcXw9v3b1RsO7Qh+khLoHfI0svKR/CTOi7/DK2RYC28gWn9 gQwVI0qkfiidGwnBQqj+S9BzpB39HwcN+PfO+BAub4Uglgir/3QzdFOcDrKaUJZ5HVSA P43IjdFNUxSGJKpV329pJ04W9oVybD1hSE8RI= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr34230qck.109.1301418842893; Tue, 29 Mar 2011 10:14:02 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Tue, 29 Mar 2011 10:14:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2011 18:14:02 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d356d5af93049fa22f0d Subject: Re: [vwrap] Relationship between Avatar/Agent and Asset Service? X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:12:27 -0000 --00235429d356d5af93049fa22f0d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 29, 2011 at 5:38 PM, Meadhbh Hamrick wrote: > > so "virtual worlds level interop" is less interesting, IMHO, since it > requires participants to effectively implement all services if they > want to participate in the virtual world. No it does not. Any virtual world is free to implement as few or as many services itself as it wants, or to choose 3rd party services in their place, or none at all, or any combination of these strategies. This is why David produced his VWRAP Deployments document, to highlight the total flexibility that would exist. As to "less interesting" ... well virtually all VW users who reside in more than one world would disagree that it is "less interesting". In fact, they do often state in no uncertain terms how hugely desirable such interop would be, and how extremely annoying it is to live without it, like RL planets lacking any means of transport between them. What's "less interesting" is producing a protocol that produces walled gardens and provides nill interop between them, because that is what we have already today. Morgaine. ========================= On Tue, Mar 29, 2011 at 5:38 PM, Meadhbh Hamrick wrote: > Hey Izzy, > > FWIW... despite what morgaine says, the original members of this group > were actually interested in "service level interop." and here's the > use case. > > part of the reason Linden was interested in open protocols was so we > could attempt to become the center of a much larger virtual ecosystem. > the vision we shared with some of our partners was a world where you > could log into Second Life or OpenSIm instance with your facebook or > twitter credentials. or google. or yahoo! or OSGrid or Linden / Second > Life. we also wanted to allow individual organizations (either your > corporate IT department or a commercial online service like the > Wikimedia commons) to act as an asset server for your inventory. we > wanted to give individual grid deployers (or even individual users) > the ability to pick who routed their voice and audio packets. > > these are just a few examples of the use cases we wanted to support > that we felt justified "service level interop." > > people who wanted to be able to walk from one world to the other, > could still do that, but only if both virtual worlds supported enough > services to move avatars between them. > > so "virtual worlds level interop" is less interesting, IMHO, since it > requires participants to effectively implement all services if they > want to participate in the virtual world. > > now... Linden, IBM and Intel seem to have de-prioritized their > participation in this group, so it's certainly a valid thing to say > "hey, let's focus on full-on VW interop." but ultimately, this will be > limiting your participation to a much smaller community of deployers. > and at the end of the day, you're going to have to specify services > as... well... services, so the VW interop thing has always seemed like > a red herring at worst and an artificial constraint at best. > > the current charter was developed at a time when "service level > interop" was the assumption, which is why we split off each service > into a different document. the charter was also too small a document > to capture the assumptions of the types of systems we wanted to work > with, which is why in 2009 Dave Crocker recommended we put a bare > minimum in the charter with the understanding that the intro doc would > expand that understanding. > > so... if peeps here want to continue with service level interop, > that's fine. we _may_ be able to keep the same charter and even some > parts of the intro doc. if we want to go with full-on interop between > OpenSim instances, that will probably necessitate a change in the > charter and definitely a change in the intro. > > just my 2 cents. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Tue, Mar 29, 2011 at 7:58 AM, Izzy Alanis wrote: > > Starting new thread as the previous one is becoming too unwieldily. > > > > Morgaine said: > >> We either have interoperability between worlds, in which an inhabitant > can travel from one world to another and take their avatar and/or > possessions with them, or else we don't have that. It's black and white, > and no amount of fudging about "service level interoperability" is going to > overcome the lack of VW interoperability as a user would understand it. > > > > The world is full of shades of grey. > > > > Is there an assumption that an Avatar has/uses one (and only one?) > > "Asset Service" -- that I have a single repository of possessions to > > take? Can I have and use different asset services? Can I use multiple > > asset services? Can people share? > > > > - Izzy > > _______________________________________________ > > 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 > --00235429d356d5af93049fa22f0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2011 at 5:38 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote= :

so "virtual worlds level interop" is less interesting, IMHO, sinc= e it
requires participants to effectively implement all services if they
want to participate in the virtual world.


No it do= es not.=A0 Any virtual world is free to implement as few or as many service= s itself as it wants, or to choose 3rd party services in their place, or no= ne at all, or any combination of these strategies.=A0 This is why David pro= duced his VWRAP Deployments document, to highlight the total flexibility th= at would exist.

As to "less interesting" ... well virtually all VW users who = reside in more than one world would disagree that it is "less interest= ing".=A0 In fact, they do often state in no uncertain terms how hugely= desirable such interop would be, and how extremely annoying it is to live = without it, like RL planets lacking any means of transport between them.
What's "less interesting" is producing a protocol that pr= oduces walled gardens and provides nill interop between them, because that = is what we have already today.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

On Tue, Mar 29, 2011 at 5:38= PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
Hey Izzy,

FWIW... despite what morgaine says, the original members of this group
were actually interested in "service level interop." and here'= ;s the
use case.

part of the reason Linden was interested in open protocols was so we
could attempt to become the center of a much larger virtual ecosystem.
the vision we shared with some of our partners was a world where you
could log into Second Life or OpenSIm instance with your facebook or
twitter credentials. or google. or yahoo! or OSGrid or Linden / Second
Life. we also wanted to allow individual organizations (either your
corporate IT department or a commercial online service like the
Wikimedia commons) to act as an asset server for your inventory. we
wanted to give individual grid deployers (or even individual users)
the ability to pick who routed their voice and audio packets.

these are just a few examples of the use cases we wanted to support
that we felt justified "service level interop."

people who wanted to be able to walk from one world to the other,
could still do that, but only if both virtual worlds supported enough
services to move avatars between them.

so "virtual worlds level interop" is less interesting, IMHO, sinc= e it
requires participants to effectively implement all services if they
want to participate in the virtual world.

now... Linden, IBM and Intel seem to have de-prioritized their
participation in this group, so it's certainly a valid thing to say
"hey, let's focus on full-on VW interop." but ultimately, thi= s will be
limiting your participation to a much smaller community of deployers.
and at the end of the day, you're going to have to specify services
as... well... services, so the VW interop thing has always seemed like
a red herring at worst and an artificial constraint at best.

the current charter was developed at a time when "service level
interop" was the assumption, which is why we split off each service into a different document. the charter was also too small a document
to capture the assumptions of the types of systems we wanted to work
with, which is why in 2009 Dave Crocker recommended we put a bare
minimum in the charter with the understanding that the intro doc would
expand that understanding.

so... if peeps here want to continue with service level interop,
that's fine. we _may_ be able to keep the same charter and even some parts of the intro doc. if we want to go with full-on interop between
OpenSim instances, that will probably necessitate a change in the
charter and definitely a change in the intro.

just my 2 cents.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Tue, Mar 29, 2011 at 7:58 AM, Izzy Alanis <izzyalanis@gmail.com> wrote:
> Starting new thread as the previous one is becoming too unwieldily. >
> Morgaine said:
>> We either have interoperability between worlds, in which an inhabi= tant can travel from one world to another and take their avatar and/or poss= essions with them, or else we don't have that. =A0It's black and wh= ite, and no amount of fudging about "service level interoperability&qu= ot; is going to overcome the lack of VW interoperability as a user would un= derstand it.
>
> The world is full of shades of grey.
>
> Is there an assumption that an Avatar has/uses one (and only one?)
> "Asset Service" -- that I have a single repository of posses= sions to
> take? Can I have and use different asset services? Can I use multiple<= br> > asset services? Can people share?
>
> =A0- Izzy
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d356d5af93049fa22f0d-- From kmancuso@gmail.com Tue Mar 29 13:46:38 2011 Return-Path: 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 ; 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: References: From: Katherine Mancuso Date: Tue, 29 Mar 2011 13:42:14 -0700 Message-ID: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 ---------------------------------------------------------------------------------------------- From mike.dickson@hp.com Tue Mar 29 14:02:30 2011 Return-Path: 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 8BA4B3A6AB5 for ; Tue, 29 Mar 2011 14:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.759 X-Spam-Level: X-Spam-Status: No, score=-100.759 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] 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 9hRa6ZrIJ6RD for ; Tue, 29 Mar 2011 14:02:29 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id 6A7843A68FF for ; Tue, 29 Mar 2011 14:02:29 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=Nm3SJc7L3wlcojC9snsyzORkYWw1JOu3BeZkTeIwPUk= c=1 sm=0 a=lpDWfFNTT9MA:10 a=-Iv2emOgpcYA:10 a=8nJEP1OIZ-IA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=qrv8pW-eu1m0xrMj-mwA:9 a=uL4XPW6C-_P-PVIdYNIA:7 a=Dic7jxkPJBEfkky08X7rrZIrPd4A:4 a=wPNLvfGTeEIA:10 a=8O7rT0t75xPOq_A6:21 a=TV0OT6-M5Tb_cB5X:21 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:41472] helo=[192.168.0.101]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id FF/97-11439-649429D4; Tue, 29 Mar 2011 21:04:07 +0000 Message-ID: <4D924945.7050001@hp.com> Date: Tue, 29 Mar 2011 17:04:05 -0400 From: Mike Dickson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 21:02:30 -0000 On 03/29/2011 04:42 PM, Katherine Mancuso wrote: > 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: Just saying up front I'd give this approach a strong +1 from me. It recognizes the fact that others are interested in full VW interop while placing the short term focus on service definition and interaction for which we have some existing documents and experience that can be leveraged. Its a walk before you run approach and personally I think it would be far more productive in the short term versus the VW interop approach. > 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. > Again yes, strongly agree. Full VW interop needs a roadmap to have a chance to be successful. At present there are lots of cart paths that can sort of get you there. And tons of unanswered questions. Its valuable to spend cycles on that but not at the expense of specifying existing services and approaches that work now. > 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. > Yes, again I think thats been what we've seen. Too little agreement over a hard problem that limits progress on something for which we do have some experience. > 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 > Well said overall. I hope teh group gives this approach real consideration. Mike From izzyalanis@gmail.com Tue Mar 29 17:00:01 2011 Return-Path: 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 CB5393A69A9 for ; Tue, 29 Mar 2011 17:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 G46QKco2I8+T for ; Tue, 29 Mar 2011 17:00:00 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 9B27F3A67D3 for ; Tue, 29 Mar 2011 16:59:59 -0700 (PDT) Received: by fxm15 with SMTP id 15so706820fxm.31 for ; Tue, 29 Mar 2011 17:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YUC2i3SFviwPZYeYfgYxGcZESSouBHF29suFHSx5MUQ=; b=VqU0hlUx/mIHXjUqcajjbVDV12kNb4MpvuYYUGwxF6Sq5cDEMZUnIlJSvLZ3Y5ku+2 NbXP+eqMdPzjbe9+PH9qLGrwHyTywsnuCG+htsmUbJFr5DsERT00zO1DT37/6AXoCORx A0svAGr15Tv3MoV10KIhwCbfN80Eg63QiDTOc= 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 :cc:content-type:content-transfer-encoding; b=vrLgoqyFibvDJsvsg6APcmKLobMdRZLxxwDu38ysXmen0u/8wJtxsSYizrUj6afd6Q v6eGf4ripHEDbJ+rO78vr+5uB2jiwaqqFOgInex3PeMQARMi7gF5Ni3idT9peSvm/Qb9 cs/wgX+vCtlamIDmFQlXjRJweK8CGYHlt2DF0= MIME-Version: 1.0 Received: by 10.223.158.9 with SMTP id d9mr472413fax.124.1301443297111; Tue, 29 Mar 2011 17:01:37 -0700 (PDT) Received: by 10.223.74.204 with HTTP; Tue, 29 Mar 2011 17:01:36 -0700 (PDT) In-Reply-To: References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> Date: Tue, 29 Mar 2011 20:01:36 -0400 Message-ID: From: Izzy Alanis To: Morgaine Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 00:00:02 -0000 So, I'm still trying to understand your sentence: > no amount of fudging about "service level interoperability" is going to o= vercome the lack of VW interoperability as a user would understand it. Certainly, a small amount of service level interop would go a long way to overcome VW interoperability. In your mind, how does service level interop *not* lead to "VW Interoperability"? This whole argument between service level interop and 'full' interop eludes me. On Tue, Mar 29, 2011 at 12:06 PM, Morgaine wrote: > Izzy, it's truly simple, and I see that you understand it.=A0 You have li= sted > a number of possible restrictions or constraints that could be applied to > limit or modify interop between worlds, but your list of questions is onl= y > meaningful because you already understand what interop between virtual > worlds means at its most open and powerful. > > You are there already in your understanding! :-) > > When our protocols support such interoperation between virtual worlds, > restrictions can of course be placed on that interoperation by world > providers, just like an email service provider can place restrictions on = who > can access their service, where people can send emails, the kinds of cont= ent > permitted, and so on.=A0 It's totally normal for services on the Internet= to > apply their own restrictions, and it would be no different for interopera= ble > VWs. > > Likewise for us, we know what interoperation between virtual worlds means= in > concept (I described it in simple user language in my previous email), bu= t > any individual deployment might reduce or limit that based on local polic= y. > It's not up to us to mandate local policy, but it is up to us to create a > protocol that provides interoperation between virtual worlds so that it's > available for those worlds that do want to interoperate. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > On Tue, Mar 29, 2011 at 4:46 PM, Izzy Alanis wrote= : >> >> I'll second Mike's comment: I don=92t know what it mean to have virtual >> world interop personally. >> >> Do I have to be able to teleport from one world to the next within the >> same viewer to qualify as "interop"? Or would it be OK if I was able >> to log in using different viewers/clients as long as my 'identity' was >> maintained? What if I had to have separate identities between virtual >> worlds, but could still access my bank of assets? What if I could >> maintain the concept of "identity" but not transfer assets/use a >> particular asset service? What if I couldn't access my assets from a >> particular asset service in a particular virtual world due to policy >> reasons (e.g. virtual world "A" doesn't like asset service provider >> "B")? >> >> =A0- Izzy >> >> On Tue, Mar 29, 2011 at 11:37 AM, Morgaine >> wrote: >> > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) >> > wrote: >> >> >> >> Right, so we do need to standardize =93Service Level Interop=94.=A0 A= s has >> >> been >> >> pointed out its concrete enough you can actually do it and it would >> >> allow >> >> the assembly of virtual worlds based upon it. >> > >> > I think you misunderstood the point that I wrote, since you concluded >> > the >> > opposite.=A0 No, it does not follow that we need to standardize "servi= ce >> > level >> > interop", because that does not give us interoperation between virtual >> > worlds.=A0 It only allows us to standardize (as you correctly state) t= he >> > "assembly of virtual worlds", one world at a time, instead of >> > standardizing >> > their interoperation.=A0 We don't need to standardize how VWs are >> > assembled, >> > it's not even our remit to do that because that's up to each provider. >> > >> >> >> >> >> >> I don=92t know what it mean to have virtual world interop personally. >> > >> > Why?=A0 It's very easy to understand, and I would guess that every VW = user >> > today who is using two or more virtual worlds like (say) OSgrid and >> > InWorldz >> > can probably describe it very eloquently.=A0 I'll just repaste how I >> > described >> > it yesterday: >> > >> >> >> >> We either have interoperability between worlds, in which an inhabitan= t >> >> can >> >> travel from one world to another and take their avatar and/or >> >> possessions >> >> with them, or else we don't have that.=A0 It's black and white, and n= o >> >> amount >> >> of fudging about "service level interoperability" is going to overcom= e >> >> the >> >> lack of VW interoperability as a user would understand it. >> > >> > Interoperability between VWs is truly a simple concept, and users are >> > asking >> > for it continually and woeing its absence daily.=A0 Its lack is so cle= ar >> > and >> > self-evident and annoying that people even write export-import program= s >> > to >> > try to alleviate the user "suffering" through its absence.=A0 Frankly, >> > professing not to understand what it means is very bizarre.=A0 All I c= an >> > suggest is, I'll try to clarify it further for you if you still don't >> > understand what it means. >> > >> > >> > Morgaine. >> > >> > >> > >> > >> > >> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) >> > wrote: >> >> >> >> From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behal= f >> >> Of >> >> Morgaine >> >> Sent: Monday, March 28, 2011 8:01 PM >> >> To: vwrap@ietf.org >> >> >> >> Subject: Re: [vwrap] Status and future of the VWRAP working group >> >> >> >> >> >> >> >> Responding to two posts: >> >> >> >> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol >> >> wrote: >> >> >> >> If you want service only, I think there is code implemented already. >> >> >> >> Exactly as Dzonatas says.=A0 We don't need to work on protocols for >> >> internal >> >> use by separate, isolated world services.=A0 We have those already.= =A0 The >> >> ingredient that is mostly missing from the Virtual World arena is >> >> interoperability between such services, and that is the goal that has >> >> sparked extremely wide interest. >> >> >> >> Right, so we do need to standardize =93Service Level Interop=94.=A0 A= s has >> >> been >> >> pointed out its concrete enough you can actually do it and it would >> >> allow >> >> the assembly of virtual worlds based upon it.=A0=A0 The point that so= me of >> >> this >> >> exists is a good one, there=92s some existing practice and knowledge = that >> >> can >> >> be leveraged. >> >> >> >> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte >> >> wrote: >> >> >> >> d. interoperability between (instances of) any two virtual world >> >> systems >> >> conforming to the (to be defined) VWRAP standard. >> >> >> >> Exactly as Boroondas says.=A0 Indeed, that is the interoperability go= al >> >> sought by the majority of contributors here over the years, so this i= s >> >> nothing new. It's the feature that virtual worlds don't yet have, and >> >> that's >> >> why it's worthwhile to work on it. >> >> >> >> Again, this is sensible and it=92s achieved via the =93standard servi= ces=94 >> >> defined above.=A0 I don=92t know what it mean to have virtual world i= nterop >> >> personally.=A0 It=92s a nice ideal but in practice differences in pol= icy, >> >> technology, etc, make it practically impossible to specify given the >> >> current >> >> state of =A0affairs.=A0 =A0=A0We can=92t even agree on a the data des= cription >> >> protocol >> >> let alone how to handle policy across VW systems. =A0And that extends >> >> past >> >> business policy into technical issues like: if an =93object=94 =A0is = scripted >> >> how >> >> does that transfer to another VW. Who allocates the script resources. >> >> And >> >> of course there=92s also creator=92s rights vs. owner=92s rights.=A0 = The list >> >> is >> >> extremely long and we can=92t even agree on how services should talk = and >> >> which >> >> there should be in a standard way. >> >> >> >> >> >> >> >> IMO, the effort should focus on Service Level interoperability and th= e >> >> definition of a few fundamental building block services: i.e user >> >> service, >> >> inventory service, asset service.=A0 I=92d leave the simulator piece = off >> >> for >> >> now.=A0 If we get those right you can start to share user information >> >> between >> >> =93virtual worlds=94, locate and access inventory and define an objec= ts >> >> characteristics inside a simulator.=A0 And the simulator piece can ev= olve >> >> until its ready to be standardized. >> >> >> >> Mike >> >> >> >> >> > >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> > https://www.ietf.org/mailman/listinfo/vwrap >> > >> > > > From dzonatas@gmail.com Tue Mar 29 17:29:25 2011 Return-Path: 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 C6F103A6AEF for ; Tue, 29 Mar 2011 17:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 USqauSaDl-yp for ; Tue, 29 Mar 2011 17:29:23 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 864763A6A84 for ; Tue, 29 Mar 2011 17:29:23 -0700 (PDT) Received: by iwn39 with SMTP id 39so774359iwn.31 for ; Tue, 29 Mar 2011 17:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=OQurIkszjutIHwAajdsimlWqgwTZagbtMr76SprSWz0=; b=VPbo5E9YRQq5A4B1otyJd+9k9MaVEr2UFaRuIVNetaiRrdem/nrqbt61OqqGlO7kVl kca2gNaViRIt081ltCgfZEmgRkNeY0NicsYZe6vLszTM/aji7OUEybB7KskZESeVtNV/ 1jf/472ZMzwGf3TxuROyWW35M6+OiFN8Jbq0o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=BY94AHIEiiKsHASHEOOoONJj1TsdonZtjZTea8oeKfZqm5s7t+dMgqIr6mqJvwJY7N FLCHhEW43BrbNsA+ijzCn4dBd7vzKRkJepu9I3K59r1h8DAUHj/nP0TGoi7r5T6YEib1 /0Sit/wGoWozepTHSMZ1BRTBbfO2ZAVdfy2cY= Received: by 10.42.1.82 with SMTP id 18mr239452icf.456.1301445060279; Tue, 29 Mar 2011 17:31:00 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id o3sm3975669ibd.61.2011.03.29.17.30.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2011 17:30:58 -0700 (PDT) Message-ID: <4D92799E.5090508@gmail.com> Date: Tue, 29 Mar 2011 17:30:22 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Izzy Alanis References: <956AEC85-F919-4C64-96BA-277B620CAB18@gmail.com> <20110326135320.GC29908@alinoe.com> <4D911618.7060706@gmail.com> <4646639E08F58B42836FAC24C94624DD92FDE5FEC5@GVW0433EXB.americas.hpqcorp.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Status and future of the VWRAP working group X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 00:29:26 -0000 Especially since this is the Virtual World Region-Agent Protocol, I'm wondering where is "full" and "service level" in the region/agent dissection. Izzy Alanis wrote: > So, I'm still trying to understand your sentence: > >> no amount of fudging about "service level interoperability" is going to overcome the lack of VW interoperability as a user would understand it. >> > Certainly, a small amount of service level interop would go a long way > to overcome VW interoperability. > > In your mind, how does service level interop *not* lead to "VW > Interoperability"? This whole argument between service level interop > and 'full' interop eludes me. > > > On Tue, Mar 29, 2011 at 12:06 PM, Morgaine > wrote: > >> Izzy, it's truly simple, and I see that you understand it.� You have listed >> a number of possible restrictions or constraints that could be applied to >> limit or modify interop between worlds, but your list of questions is only >> meaningful because you already understand what interop between virtual >> worlds means at its most open and powerful. >> >> You are there already in your understanding! :-) >> >> When our protocols support such interoperation between virtual worlds, >> restrictions can of course be placed on that interoperation by world >> providers, just like an email service provider can place restrictions on who >> can access their service, where people can send emails, the kinds of content >> permitted, and so on.� It's totally normal for services on the Internet to >> apply their own restrictions, and it would be no different for interoperable >> VWs. >> >> Likewise for us, we know what interoperation between virtual worlds means in >> concept (I described it in simple user language in my previous email), but >> any individual deployment might reduce or limit that based on local policy. >> It's not up to us to mandate local policy, but it is up to us to create a >> protocol that provides interoperation between virtual worlds so that it's >> available for those worlds that do want to interoperate. >> >> >> Morgaine. >> >> >> >> >> ============================ >> >> On Tue, Mar 29, 2011 at 4:46 PM, Izzy Alanis wrote: >> >>> I'll second Mike's comment: I don�t know what it mean to have virtual >>> world interop personally. >>> >>> Do I have to be able to teleport from one world to the next within the >>> same viewer to qualify as "interop"? Or would it be OK if I was able >>> to log in using different viewers/clients as long as my 'identity' was >>> maintained? What if I had to have separate identities between virtual >>> worlds, but could still access my bank of assets? What if I could >>> maintain the concept of "identity" but not transfer assets/use a >>> particular asset service? What if I couldn't access my assets from a >>> particular asset service in a particular virtual world due to policy >>> reasons (e.g. virtual world "A" doesn't like asset service provider >>> "B")? >>> >>> �- Izzy >>> >>> On Tue, Mar 29, 2011 at 11:37 AM, Morgaine >>> wrote: >>> >>>> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) >>>> wrote: >>>> >>>>> Right, so we do need to standardize �Service Level Interop�.� As has >>>>> been >>>>> pointed out its concrete enough you can actually do it and it would >>>>> allow >>>>> the assembly of virtual worlds based upon it. >>>>> >>>> I think you misunderstood the point that I wrote, since you concluded >>>> the >>>> opposite.� No, it does not follow that we need to standardize "service >>>> level >>>> interop", because that does not give us interoperation between virtual >>>> worlds.� It only allows us to standardize (as you correctly state) the >>>> "assembly of virtual worlds", one world at a time, instead of >>>> standardizing >>>> their interoperation.� We don't need to standardize how VWs are >>>> assembled, >>>> it's not even our remit to do that because that's up to each provider. >>>> >>>> >>>>> I don�t know what it mean to have virtual world interop personally. >>>>> >>>> Why?� It's very easy to understand, and I would guess that every VW user >>>> today who is using two or more virtual worlds like (say) OSgrid and >>>> InWorldz >>>> can probably describe it very eloquently.� I'll just repaste how I >>>> described >>>> it yesterday: >>>> >>>> >>>>> We either have interoperability between worlds, in which an inhabitant >>>>> can >>>>> travel from one world to another and take their avatar and/or >>>>> possessions >>>>> with them, or else we don't have that.� It's black and white, and no >>>>> amount >>>>> of fudging about "service level interoperability" is going to overcome >>>>> the >>>>> lack of VW interoperability as a user would understand it. >>>>> >>>> Interoperability between VWs is truly a simple concept, and users are >>>> asking >>>> for it continually and woeing its absence daily.� Its lack is so clear >>>> and >>>> self-evident and annoying that people even write export-import programs >>>> to >>>> try to alleviate the user "suffering" through its absence.� Frankly, >>>> professing not to understand what it means is very bizarre.� All I can >>>> suggest is, I'll try to clarify it further for you if you still don't >>>> understand what it means. >>>> >>>> >>>> Morgaine. >>>> >>>> >>>> >>>> >>>> >>>> =========================== >>>> >>>> On Tue, Mar 29, 2011 at 1:54 PM, Dickson, Mike (ISS Software) >>>> wrote: >>>> >>>>> From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf >>>>> Of >>>>> Morgaine >>>>> Sent: Monday, March 28, 2011 8:01 PM >>>>> To: vwrap@ietf.org >>>>> >>>>> Subject: Re: [vwrap] Status and future of the VWRAP working group >>>>> >>>>> >>>>> >>>>> Responding to two posts: >>>>> >>>>> On Tue, Mar 29, 2011 at 12:13 AM, Dzonatas Sol >>>>> wrote: >>>>> >>>>> If you want service only, I think there is code implemented already. >>>>> >>>>> Exactly as Dzonatas says.� We don't need to work on protocols for >>>>> internal >>>>> use by separate, isolated world services.� We have those already.� The >>>>> ingredient that is mostly missing from the Virtual World arena is >>>>> interoperability between such services, and that is the goal that has >>>>> sparked extremely wide interest. >>>>> >>>>> Right, so we do need to standardize �Service Level Interop�.� As has >>>>> been >>>>> pointed out its concrete enough you can actually do it and it would >>>>> allow >>>>> the assembly of virtual worlds based upon it.�� The point that some of >>>>> this >>>>> exists is a good one, there�s some existing practice and knowledge that >>>>> can >>>>> be leveraged. >>>>> >>>>> On Tue, Mar 29, 2011 at 12:15 AM, Boroondas Gupte >>>>> wrote: >>>>> >>>>> d. interoperability between (instances of) any two virtual world >>>>> systems >>>>> conforming to the (to be defined) VWRAP standard. >>>>> >>>>> Exactly as Boroondas says.� Indeed, that is the interoperability goal >>>>> sought by the majority of contributors here over the years, so this is >>>>> nothing new. It's the feature that virtual worlds don't yet have, and >>>>> that's >>>>> why it's worthwhile to work on it. >>>>> >>>>> Again, this is sensible and it�s achieved via the �standard services� >>>>> defined above.� I don�t know what it mean to have virtual world interop >>>>> personally.� It�s a nice ideal but in practice differences in policy, >>>>> technology, etc, make it practically impossible to specify given the >>>>> current >>>>> state of �affairs.� ��We can�t even agree on a the data description >>>>> protocol >>>>> let alone how to handle policy across VW systems. �And that extends >>>>> past >>>>> business policy into technical issues like: if an �object� �is scripted >>>>> how >>>>> does that transfer to another VW. Who allocates the script resources. >>>>> And >>>>> of course there�s also creator�s rights vs. owner�s rights.� The list >>>>> is >>>>> extremely long and we can�t even agree on how services should talk and >>>>> which >>>>> there should be in a standard way. >>>>> >>>>> >>>>> >>>>> IMO, the effort should focus on Service Level interoperability and the >>>>> definition of a few fundamental building block services: i.e user >>>>> service, >>>>> inventory service, asset service.� I�d leave the simulator piece off >>>>> for >>>>> now.� If we get those right you can start to share user information >>>>> between >>>>> �virtual worlds�, locate and access inventory and define an objects >>>>> characteristics inside a simulator.� And the simulator piece can evolve >>>>> until its ready to be standardized. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> 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 > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From carlo@alinoe.com Tue Mar 29 17:41:49 2011 Return-Path: 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 269363A6AFA for ; Tue, 29 Mar 2011 17:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 mgHnahR1Q-qV for ; Tue, 29 Mar 2011 17:41:48 -0700 (PDT) Received: from fep20.mx.upcmail.net (fep20.mx.upcmail.net [62.179.121.40]) by core3.amsl.com (Postfix) with ESMTP id 78D183A6AF8 for ; Tue, 29 Mar 2011 17:41:46 -0700 (PDT) Received: from edge03.upcmail.net ([192.168.13.238]) by viefep20-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110330004323.KTP23900.viefep20-int.chello.at@edge03.upcmail.net> for ; Wed, 30 Mar 2011 02:43:23 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge03.upcmail.net with edge id RCjN1g00J0FlQed03CjPUb; Wed, 30 Mar 2011 02:43:23 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q4jVJ-0002hq-UP for vwrap@ietf.org; Wed, 30 Mar 2011 02:43:21 +0200 Date: Wed, 30 Mar 2011 02:43:21 +0200 From: Carlo Wood To: "" Message-ID: <20110330004321.GA8908@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=zlRBWuFCZaNL9+WHNm1pWLowY5Lx061w2zJBJiDkNAU= c=1 sm=0 a=XYJHFtupD_QA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=48vgC7mUAAAA:8 a=BjFOTwK7AAAA:8 a=Fpj4q4rEzAiwMgVR80sA:9 a=sgbbXk6Ekr0QJ9BFd73ucfCISaAA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=o-lgMkWmYBMksEVX:21 a=QYGRWDajpLF0x1Q1:21 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [vwrap] Glossary X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 00:41:49 -0000 I added an Entry for "VWRAP" and "Trust domain" to http://trac.tools.ietf.org/wg/vwrap/trac/wiki/Glossary Please everyone verify ;). 'Trust domain' is still empty though. It needs definitions. -- Carlo Wood From carlo@alinoe.com Tue Mar 29 18:13:25 2011 Return-Path: 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 08F9F28C0EF for ; Tue, 29 Mar 2011 18:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 zWx9uSRCAaRZ for ; Tue, 29 Mar 2011 18:13:24 -0700 (PDT) Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id 6FAAA28C0D7 for ; Tue, 29 Mar 2011 18:13:23 -0700 (PDT) Received: from edge05.upcmail.net ([192.168.13.212]) by viefep17-int.chello.at (InterMail vM.8.01.02.02 201-2260-120-106-20100312) with ESMTP id <20110330011500.PUIN11401.viefep17-int.chello.at@edge05.upcmail.net> for ; Wed, 30 Mar 2011 03:15:00 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upcmail.net with edge id RDEy1g00f0FlQed05DEz93; Wed, 30 Mar 2011 03:15:00 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.72) (envelope-from ) id 1Q4jzu-0002y6-7H for vwrap@ietf.org; Wed, 30 Mar 2011 03:14:58 +0200 Date: Wed, 30 Mar 2011 03:14:58 +0200 From: Carlo Wood To: "" Message-ID: <20110330011458.GB8908@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Cloudmark-Analysis: v=1.1 cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0 a=XYJHFtupD_QA:10 a=T713mU-8qjYA:10 a=lF6S9qf5Q1oA:10 a=kj9zAlcOel0A:10 a=BjFOTwK7AAAA:8 a=aMMpENY4S25QXj7jSpoA:9 a=aXpdYrQcjlTMpObtOJVRXrdz08oA:4 a=CjuIK1q_8ugA:10 a=bW3kdApBr58A:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Subject: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 01:13:25 -0000 Perhaps we should also start a wiki page (it's nice to have a stable url that one can refer to, which still is editable; that give me at least a feeling of progress), about statements that we reached consensus over. Being an abstract thinker and analyst, I believe we can tackle many of the current discussions at a much higer abstraction level first, making it easier, or even possible, to deal with the more detailed points of discussion. I'd like to start with one such statement and ask for consensus on it (and if not, give your rationale why not). * Whenever a change X in the protocol is proposed (which might be an addition, a change of existing protocol or even deletion: any change, making the protocol (VWRAP) go from A --> B), then that change is accepted as part of VWRAP provided that: 1) Protocol B can do everything that A could do. 2) No substantial extra demands are being made on an implementation that only implements the functionality of A. In other words: we choose for flexibility. Under no circumstances we want the *protocol* itself to be a limitation in what is possible, when that extra flexibility/possibility doesn't cost much for those not needing or using it. Companies be warned: that DOES mean that you lose control: sometimes it is "nice" if it's impossible to do with a protocol what your company doesn't want. However, if that is what you want-- I'd like to hear good reasons for that at THIS abstraction level, and not while discussion details, because then it's too easy to go against some proposal for "different" reasons (not really saying that what you really want is that something is just not possible with the protocol, in order to garantee that things will deviate from YOUR goals and ideas). I sincerely hope we can reach consensus on this and ask everyone to give their 'yes' or 'reasons for their no'. -- Carlo Wood From morgaine.dinova@googlemail.com Wed Mar 30 01:59:57 2011 Return-Path: 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 3BE6C3A6919 for ; Wed, 30 Mar 2011 01:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] 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 COZ75sv7OeIQ for ; Wed, 30 Mar 2011 01:59:55 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id A7D333A6957 for ; Wed, 30 Mar 2011 01:59:55 -0700 (PDT) Received: by qyk7 with SMTP id 7so716496qyk.10 for ; Wed, 30 Mar 2011 02:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7xwr7aHNvjGWWwcu3rpPAST5eloZ9/HGYLPG/Lvzpek=; b=QPLjGc2wcNgmCWEo5SEZzivcf+YqFTtfMIR2vJyP5q+Cy3yodngC4bOnn8oVbQk2OX rpdgOuYwCqEm1gZ7s+Oy4M+2QPkiMCUbEaCDLSLRvk8SpkCcTaU2oYnz31xYh62bj12f P6d2pEaT8Awsvgywbp7SoSR5U1g1s6eSGTemk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=AilPll31lx3uI518mignWAs7V6deo8u+Zrw2j5bGwQ7gsYy+FVtDW3c8o8vN/3RyDb FnM7rZss+TzZX8zOg27iUcP7nS67tfxsDivGJ/mnMsLXutFYWrZtrNR4TcOOrD/KqvTs iUVr5vmraOAjwIudRiZPY0XwFAannjc+l6PkM= MIME-Version: 1.0 Received: by 10.229.62.8 with SMTP id v8mr796065qch.33.1301475693949; Wed, 30 Mar 2011 02:01:33 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 02:01:33 -0700 (PDT) In-Reply-To: <20110330011458.GB8908@alinoe.com> References: <20110330011458.GB8908@alinoe.com> Date: Wed, 30 Mar 2011 10:01:33 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180db26bf357049faf6c61 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 08:59:57 -0000 --90e6ba180db26bf357049faf6c61 Content-Type: text/plain; charset=ISO-8859-1 I support Carlo's call for maintaining a page on the IETF wiki that lists requirements and implementation details in a concise format,and hence marks our progress along the path. The items on the wiki would then be required to be included in subsequent released specification drafts, at least through placeholders. Carlo, your suggested paragraph for consensus is a good one, but is too easy to evade . It makes it trivial for a detractor to argue that "substantial extra demands are being made [by B] on an implementation that only implements the functionality of A", because every B will impose extra demands on A." That exception contains the recipe for neutralizing all progress. Instead of providing such an easy opportunity for veto by people who only want A, place the onus on the people requiring B, which is much more forward looking. I suggest something like this: - Whenever a change X in the protocol is proposed (which might be an addition, a change of existing protocol or even deletion: any change, making the protocol (VWRAP) go from A --> B), then that change is accepted as part of VWRAP provided that: 1. Protocol B can do everything that A could do. 2. Good use-case justification for B is provided. 3. Implementation requirements of B are listed. This would make it clear that features are incremental (A+B must always be a superset of A), offer an initial level of technical detail about how functionality B can be achieved, and most importantly, make everyone aware of the impact that B has on A. It will also ensure that an implementation that provides A but not B is by choice a subset implementation. Morgaine. ================== On Wed, Mar 30, 2011 at 2:14 AM, Carlo Wood wrote: > Perhaps we should also start a wiki page (it's nice > to have a stable url that one can refer to, which still > is editable; that give me at least a feeling of progress), > about statements that we reached consensus over. > > Being an abstract thinker and analyst, I believe we > can tackle many of the current discussions at a much > higer abstraction level first, making it easier, or > even possible, to deal with the more detailed points > of discussion. > > I'd like to start with one such statement and ask > for consensus on it (and if not, give your rationale > why not). > > > * Whenever a change X in the protocol is proposed > (which might be an addition, a change of existing > protocol or even deletion: any change, making > the protocol (VWRAP) go from A --> B), then that > change is accepted as part of VWRAP provided that: > 1) Protocol B can do everything that A could do. > 2) No substantial extra demands are being made on > an implementation that only implements the > functionality of A. > > > In other words: we choose for flexibility. > > Under no circumstances we want the *protocol* itself > to be a limitation in what is possible, when that > extra flexibility/possibility doesn't cost much for > those not needing or using it. > > Companies be warned: that DOES mean that you lose > control: sometimes it is "nice" if it's impossible > to do with a protocol what your company doesn't > want. However, if that is what you want-- I'd like > to hear good reasons for that at THIS abstraction > level, and not while discussion details, because then > it's too easy to go against some proposal for "different" > reasons (not really saying that what you really want > is that something is just not possible with the protocol, > in order to garantee that things will deviate from YOUR > goals and ideas). > > > I sincerely hope we can reach consensus on this and > ask everyone to give their 'yes' or 'reasons for their > no'. > > -- > Carlo Wood > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --90e6ba180db26bf357049faf6c61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support Carlo's call for maintaining a page on the IETF wiki that lis= ts requirements and implementation details in a concise format,and hence ma= rks our progress along the path.=A0 The items on the wiki would then be req= uired to be included in subsequent released specification drafts, at least = through placeholders.

Carlo, your suggested paragraph for consensus is a good one, but is too= easy to evade .=A0 It makes it trivial for a detractor to argue that "= ;substantial extra demands are being made [by B] on an implementation that = only implements the functionality of A", because every B will impose e= xtra demands on A."=A0 That exception contains the recipe for neutrali= zing all progress.

Instead of providing such an easy opportunity for veto by people who on= ly want A, place the onus on the people requiring B, which is much more for= ward looking.=A0 I suggest something like this:

  • Whenever a c= hange X in the protocol is proposed (which might be an addition, a change o= f existing protocol or even deletion: any change, making the protocol (VWRA= P) go from A --> B), then that change is accepted as part of VWRAP provi= ded that:
  1. Protocol B can do everything that A could do.
  2. Good use-case justif= ication for B is provided.
  3. Implementation requirements of B are listed.

This would make = it clear that features are incremental (A+B must always be a superset of A)= , offer an initial level of technical detail about how functionality B can = be achieved, and most importantly, make everyone aware of the impact that B= has on A.=A0 It will also ensure that an implementation that provides A bu= t not B is by choice a subset implementation.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 30, 201= 1 at 2:14 AM, Carlo Wood <carlo@alinoe.com> wrote:
Perhaps we should= also start a wiki page (it's nice
to have a stable url that one can refer to, which still
is editable; that give me at least a feeling of progress),
about statements that we reached consensus over.

Being an abstract thinker and analyst, I believe we
can tackle many of the current discussions at a much
higer abstraction level first, making it easier, or
even possible, to deal with the more detailed points
of discussion.

I'd like to start with one such statement and ask
for consensus on it (and if not, give your rationale
why not).


* Whenever a change X in the protocol is proposed
=A0(which might be an addition, a change of existing
=A0protocol or even deletion: any change, making
=A0the protocol (VWRAP) go from A --> B), then that
=A0change is accepted as part of VWRAP provided that:
=A01) Protocol B can do everything that A could do.
=A02) No substantial extra demands are being made on
=A0 =A0 an implementation that only implements the
=A0 =A0 functionality of A.


In other words: we choose for flexibility.

Under no circumstances we want the *protocol* itself
to be a limitation in what is possible, when that
extra flexibility/possibility doesn't cost much for
those not needing or using it.

Companies be warned: that DOES mean that you lose
control: sometimes it is "nice" if it's impossible
to do with a protocol what your company doesn't
want. However, if that is what you want-- I'd like
to hear good reasons for that at THIS abstraction
level, and not while discussion details, because then
it's too easy to go against some proposal for "different"
reasons (not really saying that what you really want
is that something is just not possible with the protocol,
in order to garantee that things will deviate from YOUR
goals and ideas).


I sincerely hope we can reach consensus on this and
ask everyone to give their 'yes' or 'reasons for their
no'.

--
Carlo Wood <carlo@alinoe.com>=
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--90e6ba180db26bf357049faf6c61-- From sllists@boroon.dasgupta.ch Wed Mar 30 04:28:27 2011 Return-Path: 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 B3EA128C0DB for ; Wed, 30 Mar 2011 04:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] 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 bOfij--dApgB for ; Wed, 30 Mar 2011 04:28:27 -0700 (PDT) Received: from datendelphin.net (india288.server4you.de [85.25.150.202]) by core3.amsl.com (Postfix) with ESMTP id AA12F28C159 for ; Wed, 30 Mar 2011 04:28:18 -0700 (PDT) Received: from [192.168.1.101] (adsl-62-167-25-70.adslplus.ch [62.167.25.70]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by datendelphin.net (Postfix) with ESMTPSA id 439AD2E047 for ; Wed, 30 Mar 2011 13:32:44 +0200 (CEST) Message-ID: <4D931434.2030206@boroon.dasgupta.ch> Date: Wed, 30 Mar 2011 13:29:56 +0200 From: Boroondas Gupte User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110313 Lightning/1.0b3pre Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: <20110330011458.GB8908@alinoe.com> In-Reply-To: <20110330011458.GB8908@alinoe.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 11:28:27 -0000 On 03/30/2011 03:14 AM, Carlo Wood wrote: > Perhaps we should also start a wiki page (it's nice > to have a stable url that one can refer to, which still > is editable; that give me at least a feeling of progress), > about statements that we reached consensus over. Good idea. > Being an abstract thinker and analyst, I believe we > can tackle many of the current discussions at a much > higer abstraction level first, making it easier, or > even possible, to deal with the more detailed points > of discussion. We'll probably have to switch back and forth between levels of abstraction during the discussion. A pure top-down design often won't work. But I feel it's indeed reasonable to start at a higher abstraction and see where we can go from there. > I'd like to start with one such statement and ask > for consensus on it (and if not, give your rationale > why not). > > > * Whenever a change X in the protocol is proposed > (which might be an addition, a change of existing > protocol or even deletion: any change, making > the protocol (VWRAP) go from A --> B), then that > change is accepted as part of VWRAP provided that: Formulated like this, it sounds like the following requirements together would be sufficient for acceptance. I guess you rather wanted to express that they should be necessary for acceptance, but might not be sufficient (further requirements might apply). > 1) Protocol B can do everything that A could do. > 2) No substantial extra demands are being made on > an implementation that only implements the > functionality of A. As necessary but not sufficient acceptance requirements, I can consent to these. I cannot consent to them as sufficient acceptance requirements. > In other words: we choose for flexibility. Or more specifically, total backwards compatibility between versions of VWRAP. However, to make it easy (or at least easier/possible) to design changes X or new versions B, such that they fulfill these backwards compatibility requirements, we should already design previous versions A for "forward compatibility". If I remember correctly, you have made suggestions in past messages on how to achieve such forward compatibility (e.g. protocol versioning combined with protocol negotiation). > Under no circumstances we want the *protocol* itself > to be a limitation in what is possible, when that > extra flexibility/possibility doesn't cost much for > those not needing or using it. Agreed. Cheers, Boroondas From mike.dickson@hp.com Wed Mar 30 07:26:49 2011 Return-Path: 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 118543A6936 for ; Wed, 30 Mar 2011 07:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xc7inOdvGLPq for ; Wed, 30 Mar 2011 07:26:48 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by core3.amsl.com (Postfix) with ESMTP id 2A28F3A67FC for ; Wed, 30 Mar 2011 07:26:48 -0700 (PDT) Received: from G5W0603.americas.hpqcorp.net (g5w0603.americas.hpqcorp.net [16.228.9.186]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id B8AF638A74; Wed, 30 Mar 2011 14:28:26 +0000 (UTC) Received: from G3W0629.americas.hpqcorp.net (16.233.58.78) by G5W0603.americas.hpqcorp.net (16.228.9.186) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 30 Mar 2011 14:27:28 +0000 Received: from GVW0433EXB.americas.hpqcorp.net ([16.234.32.148]) by G3W0629.americas.hpqcorp.net ([16.233.58.78]) with mapi; Wed, 30 Mar 2011 14:27:27 +0000 From: "Dickson, Mike (ISS Software)" To: Boroondas Gupte , "vwrap@ietf.org" Date: Wed, 30 Mar 2011 14:27:27 +0000 Thread-Topic: [vwrap] Statements of Consensus. Flexibity First. Thread-Index: AcvuzdvDoTMIzAzjRd6PpNXXSWIuOQAF1q2E Message-ID: <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> References: <20110330011458.GB8908@alinoe.com>, <4D931434.2030206@boroon.dasgupta.ch> In-Reply-To: <4D931434.2030206@boroon.dasgupta.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 14:26:49 -0000 On 03/30/2011 03:14 AM, Carlo Wood wrote: > Perhaps we should also start a wiki page (it's nice > to have a stable url that one can refer to, which still > is editable; that give me at least a feeling of progress), > about statements that we reached consensus over. We don't need to make a process that forces agreement under a set of terms.= That's not how the IETF=20 works. We need consensus and documents. As a contributor I'll choose to a= gree or disagree based on the topic. And in some cases I'm not sure I'd choose flexibility over stab= ility, etc. It seems to me we've sorted drifted to a point we're there are 2 camps and = a proposal was made for how to deal with it. There are those that want to work on service level interop. = And others want to define the whole concept of virtual world interop. IMO we need to either agree that se= peration exists and arrange the=20 docs so it describes the 2 work streams or agree that we can't agree and di= sband. The service level interop. is a subset of the other and given our track record I prefer to walk rather= than run. And I don't buy the "evil=20 corporate interests" argument. Ideally if we do this right there *should*= be some participation from business interests that are looking at the space. So in summary, no, I'm not going to agree to a fixed process that favours f= lexibility. The IETF already has a process for how this stuff gets worked. And we need to decide what we'r= e working on and move on. I=20 think there's room for 2 work streams here and that personally would be my = vote. I'll put my energy into service level interop personally. Mike (speaking as me and not for HP) From morgaine.dinova@googlemail.com Wed Mar 30 08:21:49 2011 Return-Path: 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 ECEF83A690D for ; Wed, 30 Mar 2011 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 OWGj96Ub+gGm for ; Wed, 30 Mar 2011 08:21:43 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C225A3A6A57 for ; Wed, 30 Mar 2011 08:21:40 -0700 (PDT) Received: by qwg5 with SMTP id 5so1032883qwg.31 for ; Wed, 30 Mar 2011 08:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=AWluGGg+DjfrVUg13/HFSC+gV3H2cmbdrkTYjb7nF8k=; b=oat/4CqdaXPtZ/84azFpgdhqHeQ9W+lyL96ncMgRmEEQ7PNW88+U8H/lmCNlrQNJbY x7EteTvgFStGHhZyPc35Q7O6d//v8fY0cfi1SlbM+sPIxKY/4isxjnPuu7TmssJO4yjE XT0/zwStbFIPTXDUrgcdImdw1r8oL27s0GUUs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=NmMUVRtT37DFPu2YcNNnzktW2Vp6kEceb+CiLXgwRPZwcV2a8Hki+sKq8Wx/HuMGa1 5q4yyZKEUJd3TltAQw0s36jV8zIQ7NCUO/8uPcK/k4MNE8HZoVjvHyqTzpCipd/vduiH I6paRCcBNa9Ky4Q5t1KNkmsJ0qNecMKccMD/Y= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr1155173qck.109.1301498599410; Wed, 30 Mar 2011 08:23:19 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 08:23:19 -0700 (PDT) In-Reply-To: <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> Date: Wed, 30 Mar 2011 16:23:19 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d356b1a93b049fb4c138 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:21:49 -0000 --00235429d356b1a93b049fb4c138 Content-Type: text/plain; charset=ISO-8859-1 Mike, if you don't need the flexibility available in a protocol, simply don't use the flexible features that you don't want. But denying those who require a flexible and extensible protocol with a degree of future-proofing to it is, I believe, not in line with the goals expressed here from the start of this process. Perhaps closed enterprises don't need flexibility, but open communities certainly do, and they are typically long-lived and hence require the ability to evolve and to adapt to change. And open communities most certainly need interoperability between their many virtual worlds. The needs of inwardly-focused companies do not override the needs of open Internet communities. This IETF protocol project serves both sets of interests, and it will need to satisfy both sets of requirements. Morgaine. ======================== On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software) < mike.dickson@hp.com> wrote: > > On 03/30/2011 03:14 AM, Carlo Wood wrote: > > Perhaps we should also start a wiki page (it's nice > > to have a stable url that one can refer to, which still > > is editable; that give me at least a feeling of progress), > > about statements that we reached consensus over. > > We don't need to make a process that forces agreement under a set of terms. > That's not how the IETF > works. We need consensus and documents. As a contributor I'll choose to > agree or disagree based on > the topic. And in some cases I'm not sure I'd choose flexibility over > stability, etc. > > It seems to me we've sorted drifted to a point we're there are 2 camps and > a proposal was made for how to > deal with it. There are those that want to work on service level interop. > And others want to define the > whole concept of virtual world interop. IMO we need to either agree that > seperation exists and arrange the > docs so it describes the 2 work streams or agree that we can't agree and > disband. The service level interop. > is a subset of the other and given our track record I prefer to walk rather > than run. And I don't buy the "evil > corporate interests" argument. Ideally if we do this right there *should* > be some participation from business > interests that are looking at the space. > > So in summary, no, I'm not going to agree to a fixed process that favours > flexibility. The IETF already has > a process for how this stuff gets worked. And we need to decide what > we're working on and move on. I > think there's room for 2 work streams here and that personally would be my > vote. I'll put my energy into > service level interop personally. > > Mike (speaking as me and not for HP) > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d356b1a93b049fb4c138 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mike, if you don't need the flexibility available in a protocol, simply= don't use the flexible features that you don't want.=A0 But denyin= g those who require a flexible and extensible protocol with a degree of fut= ure-proofing to it is, I believe, not in line with the goals expressed here= from the start of this process.

Perhaps closed enterprises don't need flexibility, but open communi= ties certainly do, and they are typically long-lived and hence require the = ability to evolve and to adapt to change.=A0 And open communities most cert= ainly need interoperability between their many virtual worlds.

The needs of inwardly-focused companies do not override the needs of op= en Internet communities.=A0 This IETF protocol project serves both sets of = interests, and it will need to satisfy both sets of requirements.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


= On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software) <mike.dickson@hp.com>= wrote:

On 03/30/2011 03:14 AM, Carlo Wood wrote:
> Perhaps we should also start a wiki page (it's nice
> to have a stable url that one can refer to, which still
> is editable; that give me at least a feeling of progress),
> about statements that we reached consensus over.

We don't need to make a process that forces agreement under a set= of terms. =A0That's not how the IETF
works. =A0We need consensus and documents. =A0As a contributor I'll cho= ose to agree or disagree based on
the topic. =A0And in some cases I'm not sure I'd choose flexibility= over stability, etc.

It seems to me we've sorted drifted to a point we're there are 2 ca= mps and a proposal was made for how to
deal with it. =A0There are those that want to work on service level interop= . =A0And others want to define the
whole concept of virtual world interop. IMO we need to either agree that se= peration exists and arrange the
docs so it describes the 2 work streams or agree that we can't agree an= d disband. =A0The service level interop.
is a subset of the other and given our track record I prefer to walk rather= than run. =A0And I don't buy the "evil
corporate interests" argument. =A0Ideally if =A0we do this right there= *should* be some participation from business
interests that are looking at the space.

So in summary, no, I'm not going to agree to a fixed process that favou= rs flexibility. =A0The IETF already has
a process for how this stuff gets worked. =A0 And we need to decide what we= 're working on and move on. I
think there's room for 2 work streams here and that personally would be= my vote. =A0I'll put my energy into
service level interop personally.

Mike (speaking as me and not for HP)


_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d356b1a93b049fb4c138-- From mike.dickson@hp.com Wed Mar 30 08:39:15 2011 Return-Path: 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 81E463A6B7D for ; Wed, 30 Mar 2011 08:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.679 X-Spam-Level: X-Spam-Status: No, score=-101.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FoINpP220FFo for ; Wed, 30 Mar 2011 08:39:13 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.122]) by core3.amsl.com (Postfix) with ESMTP id DE5743A6B61 for ; Wed, 30 Mar 2011 08:39:08 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=2pE2Kh9Ye2ywHyyFZnC5ZQ1FvuPrdOtuPO5uN4ysVDU= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=cH6R9-kdAAAA:8 a=48vgC7mUAAAA:8 a=ZVnC9hWN30Gu0FJL59MA:9 a=5VfERT56rQ_mKVTSldEA:7 a=Doc7XZBrJyK6ReruHgjxaDX6LSAA:4 a=QEXdDO2ut3YA:10 a=bt0zGP92IBIA:10 a=lZB815dzVvQA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:53679] helo=[192.168.0.101]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 47/31-05159-FFE439D4; Wed, 30 Mar 2011 15:40:47 +0000 From: Mike Dickson To: Morgaine In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Mar 2011 11:40:45 -0400 Message-ID: <1301499645.12359.10.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:39:15 -0000 On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote: > Mike, if you don't need the flexibility available in a protocol, > simply don't use the flexible features that you don't want. But > denying those who require a flexible and extensible protocol with a > degree of future-proofing to it is, I believe, not in line with the > goals expressed here from the start of this process. That's not actually consistent with what I thought Carlo wrote. There's only one set of specs and I didn't see a commitment to backwards compatibility, only that flexibility to evolve features would take precedence over other factors. And honestly all of this is moot. I'm not personally going to agree to any overriding principle other than to participate in the process and try and reach consensus in the documents produced. This whole discussion is a proverbial "red herring". We don't need to agree on how to produce consensus we need to agree on what goes into the documents. > > Perhaps closed enterprises don't need flexibility, but open > communities certainly do, and they are typically long-lived and hence > require the ability to evolve and to adapt to change. And open > communities most certainly need interoperability between their many > virtual worlds. I personally believe that focusing on services definitions and interop will produce the needed "flexibility" your after. I really want that level of flexibilty (to be able to compose "virtual worlds" flexibly) hence the reason I think focusing on the services is important. And I doubt that corporate needs and individual needs are that different in this respect. Use models for VW technologies are still evolving. > The needs of inwardly-focused companies do not override the needs of > open Internet communities. This IETF protocol project serves both > sets of interests, and it will need to satisfy both sets of > requirements. Yes, I get that. I have lots of standards experience, even serving on the board of one organization in the past. I honestly find the whole us vs. them rhetoric tiring. A healthy community will include both individual and corporate interests. And its to be expected that they'll all argue from their respective POV. That's healthy. Mike > > > Morgaine. > > > > > > ======================== > > > On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software) > wrote: > > On 03/30/2011 03:14 AM, Carlo Wood wrote: > > Perhaps we should also start a wiki page (it's nice > > to have a stable url that one can refer to, which still > > is editable; that give me at least a feeling of progress), > > about statements that we reached consensus over. > > > We don't need to make a process that forces agreement under a > set of terms. That's not how the IETF > works. We need consensus and documents. As a contributor > I'll choose to agree or disagree based on > the topic. And in some cases I'm not sure I'd choose > flexibility over stability, etc. > > It seems to me we've sorted drifted to a point we're there are > 2 camps and a proposal was made for how to > deal with it. There are those that want to work on service > level interop. And others want to define the > whole concept of virtual world interop. IMO we need to either > agree that seperation exists and arrange the > docs so it describes the 2 work streams or agree that we can't > agree and disband. The service level interop. > is a subset of the other and given our track record I prefer > to walk rather than run. And I don't buy the "evil > corporate interests" argument. Ideally if we do this right > there *should* be some participation from business > interests that are looking at the space. > > So in summary, no, I'm not going to agree to a fixed process > that favours flexibility. The IETF already has > a process for how this stuff gets worked. And we need to > decide what we're working on and move on. I > think there's room for 2 work streams here and that personally > would be my vote. I'll put my energy into > service level interop personally. > > Mike (speaking as me and not for HP) > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From mike.dickson@hp.com Wed Mar 30 09:18:58 2011 Return-Path: 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 C30253A6A48 for ; Wed, 30 Mar 2011 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 exQKbe3rYjfg for ; Wed, 30 Mar 2011 09:18:58 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.121]) by core3.amsl.com (Postfix) with ESMTP id CE5363A6A4C for ; Wed, 30 Mar 2011 09:18:57 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=ToWar1fa9ljTHbeJIRNQycBnYxCRNi5M/11QAwRcJ6A= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=hZ_-gT8fNLuY8eIOWXcA:9 a=LtoFQAL4v433bhy62VdVkpGYLwcA:4 a=QEXdDO2ut3YA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:41319] helo=[192.168.0.101]) by cdptpa-oedge04.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 29/E1-29678-458539D4; Wed, 30 Mar 2011 16:20:36 +0000 From: Mike Dickson To: Kopilo Hallard In-Reply-To: <4D93620C.3000505@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Mar 2011 12:20:34 -0400 Message-ID: <1301502034.12359.19.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:18:58 -0000 On Wed, 2011-03-30 at 17:02 +0000, Kopilo Hallard wrote: > On 31-03-2011 1-10, Mike Dickson wrote: > > On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote: > >> Mike, if you don't need the flexibility available in a protocol, > >> simply don't use the flexible features that you don't want. But > >> denying those who require a flexible and extensible protocol with a > >> degree of future-proofing to it is, I believe, not in line with the > >> goals expressed here from the start of this process. > > That's not actually consistent with what I thought Carlo wrote. There's > > only one set of specs and I didn't see a commitment to backwards > > compatibility, only that flexibility to evolve features would take > > precedence over other factors. And honestly all of this is moot. I'm > > not personally going to agree to any overriding principle other than to > > participate in the process and try and reach consensus in the documents > > produced. This whole discussion is a proverbial "red herring". We don't > > need to agree on how to produce consensus we need to agree on what goes > > into the documents. > Huh, Morgaine was writing about interoperability in regards to future > flexibility not backwards compatibility... Yes, and I'm saying I'm not going to agree that flexibility is *the* most important guiding principle over other factors like compatibility. That was the original assertion (that we should agree that flexibility is most important). I'm going to agree or disagree to things that go into documents based on their individual merit and not an overriding principle. I don't see any benefit in trying to get agreement that flexibility is most important. Here's a for instance... I happen to like LLSD not because its elegant and wonderful but because there are actually viewers I can use that implement it. I bet we can sort out a protocol mechanism that could support other encoding formats between services but I don't want to throw out LLSD because its not forward thinking or "most flexible". I'm guessing we can make the best decision about issues like that when discussing specific examples of service level interoperability. So agreeing in advance that we should focus on "flexibility" doesn't help. It simply derails the important discussion about what we're talking about; wether service level interoperability is what we need to be focused on or something more (or both as 2 work streams). Mike From dzonatas@gmail.com Wed Mar 30 10:09:33 2011 Return-Path: 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 3A5CE3A6B9F for ; Wed, 30 Mar 2011 10:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 KRoAOxjuck14 for ; Wed, 30 Mar 2011 10:09:31 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 3547C3A6BA5 for ; Wed, 30 Mar 2011 10:09:31 -0700 (PDT) Received: by iwn39 with SMTP id 39so1675893iwn.31 for ; Wed, 30 Mar 2011 10:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KABvBYVWrMG7MLmGo9ILzJQcSr0JmtCnHG8sQvfLfeE=; b=VMqH97IoB74GuwJPlUbdytjZbV1ZEt/Pl68d5iTLhQkTrQE1jUhVBnJta5x+DEzw/i qgneaxVMRqZ7TJhKvSOWAGHQtXrfGqizKE5wpVIR7vzuNxqGH3GjPt5XjlfR3oBIV1Xn 5Ac3lMtejwvPl4xUR110f93fmzcJv41uCRFHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dsGRHjf104c7JAKovXYakE8SwqURI02d64hedcmBMFObtyUV2rKJCL/91Ync+h6Uvo gH2RNTT3qL6/KfjddzHNGntO/45S6p8Ba+A/jTgaCzL2huVWAYyviGxcRuLGAxTich1v ISNityU6niim467JaBRMpksKnfN3l+m0z1mzg= Received: by 10.231.193.233 with SMTP id dv41mr1512700ibb.186.1301505069798; Wed, 30 Mar 2011 10:11:09 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm146146ibb.56.2011.03.30.10.11.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 10:11:08 -0700 (PDT) Message-ID: <4D936430.4090401@gmail.com> Date: Wed, 30 Mar 2011 10:11:12 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> In-Reply-To: <1301502034.12359.19.camel@mdickson-hplinux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:09:33 -0000 Mike Dickson wrote: > [...] So > agreeing in advance that we should focus on "flexibility" doesn't help. > It simply derails the important discussion about what we're talking > about; wether service level interoperability is what we need to be > focused on or something more (or both as 2 work streams). This pretty much concludes we need solid definition of "service level interoperability" due to the fact that it is being used flexibly at the moment to whatever best interest of said-defined parties. I know everyone hates to hear it that way, yet let's not future push away by such newer terminology. Documents exist that define partitions to region/agent protocols, so why can't we start there? Are they too drafty? -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 10:12:08 2011 Return-Path: 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 B14943A6B95 for ; Wed, 30 Mar 2011 10:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 pQv0ZjrFIQs7 for ; Wed, 30 Mar 2011 10:11:57 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id B3F8B3A6BA3 for ; Wed, 30 Mar 2011 10:11:53 -0700 (PDT) Received: by qwg5 with SMTP id 5so1126389qwg.31 for ; Wed, 30 Mar 2011 10:13:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=lYwthwK9HC6zfkJxMIUjIgshuFtn94KfLMEfwYoUau0=; b=B2AngZIYqXb7jQVLbnmSG8lEMURgtSBnLZr1bt+dqzEXRJZQtPEAA/QWPOCGVMfnh+ VZa6t3ddkdtCRGir3tTMrGQo/t836LbxXaR9+E8i2y2szvHN+pzsR7DUln0nt07k53zH ntPcfFnA7O1qYRqUrfMMyFFSv3QvS2dVHhbes= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LVqhPAbu8zjOud1p5RwPyoxhJm2jPJcKuP1vXQvWPr03P6ZM84dEG9vbOZflZ1szIH eDx72f82GlOi5fME7Ow4Xl9hgAZQiTEtyqpgHJquKP+RZJXjTj6wJkPejdJWnLqyJPbd ko8eXi/HP+9jlvDm/ZPKN9PpQ61tpQnSiVPmw= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr1312727qcd.147.1301505208563; Wed, 30 Mar 2011 10:13:28 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 10:13:28 -0700 (PDT) In-Reply-To: <1301499645.12359.10.camel@mdickson-hplinux> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> Date: Wed, 30 Mar 2011 18:13:28 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0a1399e049fb64ba5 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:12:08 -0000 --0016368340c0a1399e049fb64ba5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 30, 2011 at 4:40 PM, Mike Dickson wrote: > On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote: > > > The needs of inwardly-focused companies do not override the needs of > > open Internet communities. This IETF protocol project serves both > > sets of interests, and it will need to satisfy both sets of > > requirements. > > Yes, I get that. I have lots of standards experience, even serving on > the board of one organization in the past. I honestly find the whole us > vs. them rhetoric tiring. A healthy community will include both > individual and corporate interests. And its to be expected that they'll > all argue from their respective POV. That's healthy. Unfortunately that tension will not go away, because the needs of businesses and the needs of user communities are inherently in conflict in our area, To put it bluntly, VW *business* thinks it is best served by denying interop between worlds, because denying interop holds users captive and prevents them from easily leaving with their virtual possessions to better worlds. (A myopic business model, I agree, but we have many current examples of it.) In contrast, interop between worlds serves *individuals* and *user communities* wonderfully in numerous ways: - It frees users from being at the mercy of a large but poor VW operator. - It greatly increases competition and puts downward pressure on prices. - It allows users to visit potentially thousands of worlds without having to register new accounts everywhere just to be able to visit. - It creates a whole culture out of virtual tourism, and probably a business. - It avoids having to recreate avatars and obtain new virtual clothing in each new world visited, which is a major pain point for all VW tourists. - it greatly increases the value of virtual goods to their owners when they can use them everywhere, particularly virtual clothing. Items that are imprisoned in their home worlds are highly unsatisfactory, analogous to music that you cannot move from one music player to another. - It aids in cooperative working when there are no artificial barriers erected between worlds, and this advantage spans a huge number of realms, from higher education and research through to the smallest groupings of people getting together to share common interests. - Philosophically, it removes the stranglehold of world operators on the virtual items created by their residents, and makes taxation on items much more difficult to impose without negative repercussions. The disparity between VW business and VW community goals is so vast that this tension is here to stay, as long as VW businesses believe in the short-term gains of closed systems versus the big picture of a huge open metaverse of millions of interoperating worlds, full of opportunities. Morgaine. =========================== On Wed, Mar 30, 2011 at 4:40 PM, Mike Dickson wrote: > On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote: > > Mike, if you don't need the flexibility available in a protocol, > > simply don't use the flexible features that you don't want. But > > denying those who require a flexible and extensible protocol with a > > degree of future-proofing to it is, I believe, not in line with the > > goals expressed here from the start of this process. > > That's not actually consistent with what I thought Carlo wrote. There's > only one set of specs and I didn't see a commitment to backwards > compatibility, only that flexibility to evolve features would take > precedence over other factors. And honestly all of this is moot. I'm > not personally going to agree to any overriding principle other than to > participate in the process and try and reach consensus in the documents > produced. This whole discussion is a proverbial "red herring". We don't > need to agree on how to produce consensus we need to agree on what goes > into the documents. > > > > > Perhaps closed enterprises don't need flexibility, but open > > communities certainly do, and they are typically long-lived and hence > > require the ability to evolve and to adapt to change. And open > > communities most certainly need interoperability between their many > > virtual worlds. > > I personally believe that focusing on services definitions and interop > will produce the needed "flexibility" your after. I really want that > level of flexibilty (to be able to compose "virtual worlds" flexibly) > hence the reason I think focusing on the services is important. And I > doubt that corporate needs and individual needs are that different in > this respect. Use models for VW technologies are still evolving. > > > The needs of inwardly-focused companies do not override the needs of > > open Internet communities. This IETF protocol project serves both > > sets of interests, and it will need to satisfy both sets of > > requirements. > > Yes, I get that. I have lots of standards experience, even serving on > the board of one organization in the past. I honestly find the whole us > vs. them rhetoric tiring. A healthy community will include both > individual and corporate interests. And its to be expected that they'll > all argue from their respective POV. That's healthy. > > Mike > > > > > > > Morgaine. > > > > > > > > > > > > ======================== > > > > > > On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software) > > wrote: > > > > On 03/30/2011 03:14 AM, Carlo Wood wrote: > > > Perhaps we should also start a wiki page (it's nice > > > to have a stable url that one can refer to, which still > > > is editable; that give me at least a feeling of progress), > > > about statements that we reached consensus over. > > > > > > We don't need to make a process that forces agreement under a > > set of terms. That's not how the IETF > > works. We need consensus and documents. As a contributor > > I'll choose to agree or disagree based on > > the topic. And in some cases I'm not sure I'd choose > > flexibility over stability, etc. > > > > It seems to me we've sorted drifted to a point we're there are > > 2 camps and a proposal was made for how to > > deal with it. There are those that want to work on service > > level interop. And others want to define the > > whole concept of virtual world interop. IMO we need to either > > agree that seperation exists and arrange the > > docs so it describes the 2 work streams or agree that we can't > > agree and disband. The service level interop. > > is a subset of the other and given our track record I prefer > > to walk rather than run. And I don't buy the "evil > > corporate interests" argument. Ideally if we do this right > > there *should* be some participation from business > > interests that are looking at the space. > > > > So in summary, no, I'm not going to agree to a fixed process > > that favours flexibility. The IETF already has > > a process for how this stuff gets worked. And we need to > > decide what we're working on and move on. I > > think there's room for 2 work streams here and that personally > > would be my vote. I'll put my energy into > > service level interop personally. > > > > Mike (speaking as me and not for HP) > > > > > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > > > --0016368340c0a1399e049fb64ba5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2011 at 4:40 PM, Mike Dickson <mike.dickson@hp.com> wrote:
On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote:

> The needs of inwardly-focused companies do not override the needs of > open Internet communities. =A0This IETF protocol project serves both > sets of interests, and it will need to satisfy both sets of
> requirements.

Yes, I get that. I have lots of standards experience, even serving on=
the board of one organization in the past. =A0I honestly find the whole us<= br> vs. them rhetoric tiring. =A0A healthy community will include both
individual and corporate interests. =A0And its to be expected that they'= ;ll
all argue from their respective POV. =A0That's healthy.

Unfortunately that tension will not go away, because the needs of busi= nesses and the needs of user communities are inherently in conflict in our = area,

To put it bluntly, VW business thinks it is best served by denyi= ng interop between worlds, because denying interop holds users captive and = prevents them from easily leaving with their virtual possessions to better = worlds.=A0 (A myopic business model, I agree, but we have many current exam= ples of it.)

In contrast, interop between worlds serves individuals and us= er communities wonderfully in numerous ways:

  • It frees us= ers from being at the mercy of a large but poor VW operator.
  • It gre= atly increases competition and puts downward pressure on prices.
  • It allows users to visit potentially thousands of worlds without h= aving to register new accounts everywhere just to be able to visit.
    • It creates a whole culture out of virtual tourism, and probably a business= .
  • It avoids having to recreate avatars and obtain new virtual clothi= ng in each new world visited, which is a major pain point for all VW touris= ts.
  • it greatly increases the value of virtual goods to their owners= when they can use them everywhere, particularly virtual clothing. Items th= at are imprisoned in their home worlds are highly unsatisfactory, analogous= to music that you cannot move from one music player to another.
  • It aids in cooperative working when there are no artificial barriers er= ected between worlds, and this advantage spans a huge number of realms, fro= m higher education and research through to the smallest groupings of people= getting together to share common interests.
  • Philosophically, it removes the stranglehold of world operators on the = virtual items created by their residents, and makes taxation on items much = more difficult to impose without negative repercussions.

The disparity between VW business and VW community goals is so vast that th= is tension is here to stay, as long as VW businesses believe in the short-t= erm gains of closed systems versus the big picture of a huge open metaverse= of millions of interoperating worlds, full of opportunities.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Wed, Mar 30, 2011 at 4:40 PM, Mike Dickson &l= t;mike.dickson@hp.com>= wrote:
On Wed, 2011-03-30 at 15:23 +0000, Morgaine wrote:
> Mike, if you don't need the flexibility available in a protocol, > simply don't use the flexible features that you don't want. = =A0But
> denying those who require a flexible and extensible protocol with a > degree of future-proofing to it is, I believe, not in line with the > goals expressed here from the start of this process.

That's not actually consistent with what I thought Carlo wrote. = =A0There's
only one set of specs and I didn't see a commitment to backwards
compatibility, only that flexibility to evolve features would take
precedence over other factors. =A0And honestly all of this is moot. =A0I= 9;m
not personally going to agree to any overriding principle other than to
participate in the process and try and reach consensus in the documents
produced. This whole discussion is a proverbial "red herring". = =A0We don't
need to agree on how to produce consensus we need to agree on what goes
into the documents.

>
> Perhaps closed enterprises don't need flexibility, but open
> communities certainly do, and they are typically long-lived and hence<= br> > require the ability to evolve and to adapt to change. =A0And open
> communities most certainly need interoperability between their many > virtual worlds.

I personally believe that focusing on services definitions and intero= p
will produce the needed "flexibility" your after. =A0 I really wa= nt that
level of flexibilty (to be able to compose "virtual worlds" flexi= bly)
hence the reason I think focusing on the services is important. =A0And I doubt that corporate needs and individual needs are that different in
this respect. Use models for VW technologies are still evolving.

> The needs of inwardly-focused companies do not override the needs of > open Internet communities. =A0This IETF protocol project serves both > sets of interests, and it will need to satisfy both sets of
> requirements.

Yes, I get that. I have lots of standards experience, even serving on=
the board of one organization in the past. =A0I honestly find the whole us<= br> vs. them rhetoric tiring. =A0A healthy community will include both
individual and corporate interests. =A0And its to be expected that they'= ;ll
all argue from their respective POV. =A0That's healthy.

Mike

>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
>
>
> On Wed, Mar 30, 2011 at 3:27 PM, Dickson, Mike (ISS Software)
> <mike.dickson@hp.com>= wrote:
>
> =A0 =A0 =A0 =A0 On 03/30/2011 03:14 AM, Carlo Wood wrote:
> =A0 =A0 =A0 =A0 > Perhaps we should also start a wiki page (it'= s nice
> =A0 =A0 =A0 =A0 > to have a stable url that one can refer to, which= still
> =A0 =A0 =A0 =A0 > is editable; that give me at least a feeling of p= rogress),
> =A0 =A0 =A0 =A0 > about statements that we reached consensus over.<= br> >
>
> =A0 =A0 =A0 =A0 We don't need to make a process that forces agreem= ent under a
> =A0 =A0 =A0 =A0 set of terms. =A0That's not how the IETF
> =A0 =A0 =A0 =A0 works. =A0We need consensus and documents. =A0As a con= tributor
> =A0 =A0 =A0 =A0 I'll choose to agree or disagree based on
> =A0 =A0 =A0 =A0 the topic. =A0And in some cases I'm not sure I'= ;d choose
> =A0 =A0 =A0 =A0 flexibility over stability, etc.
>
> =A0 =A0 =A0 =A0 It seems to me we've sorted drifted to a point we&= #39;re there are
> =A0 =A0 =A0 =A0 2 camps and a proposal was made for how to
> =A0 =A0 =A0 =A0 deal with it. =A0There are those that want to work on = service
> =A0 =A0 =A0 =A0 level interop. =A0And others want to define the
> =A0 =A0 =A0 =A0 whole concept of virtual world interop. IMO we need to= either
> =A0 =A0 =A0 =A0 agree that seperation exists and arrange the
> =A0 =A0 =A0 =A0 docs so it describes the 2 work streams or agree that = we can't
> =A0 =A0 =A0 =A0 agree and disband. =A0The service level interop.
> =A0 =A0 =A0 =A0 is a subset of the other and given our track record I = prefer
> =A0 =A0 =A0 =A0 to walk rather than run. =A0And I don't buy the &q= uot;evil
> =A0 =A0 =A0 =A0 corporate interests" argument. =A0Ideally if =A0w= e do this right
> =A0 =A0 =A0 =A0 there *should* be some participation from business
> =A0 =A0 =A0 =A0 interests that are looking at the space.
>
> =A0 =A0 =A0 =A0 So in summary, no, I'm not going to agree to a fix= ed process
> =A0 =A0 =A0 =A0 that favours flexibility. =A0The IETF already has
> =A0 =A0 =A0 =A0 a process for how this stuff gets worked. =A0 And we n= eed to
> =A0 =A0 =A0 =A0 decide what we're working on and move on. I
> =A0 =A0 =A0 =A0 think there's room for 2 work streams here and tha= t personally
> =A0 =A0 =A0 =A0 would be my vote. =A0I'll put my energy into
> =A0 =A0 =A0 =A0 service level interop personally.
>
> =A0 =A0 =A0 =A0 Mike (speaking as me and not for HP)
>
>
>
> =A0 =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 =A0 vwrap mailing list
> =A0 =A0 =A0 =A0 vwrap@ietf.org > =A0 =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/vwrap
>
>



--0016368340c0a1399e049fb64ba5-- From mike.dickson@hp.com Wed Mar 30 10:44:28 2011 Return-Path: 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 4D4AF3A6BAB for ; Wed, 30 Mar 2011 10:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.292 X-Spam-Level: X-Spam-Status: No, score=-102.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HiO7z+wyz3+J for ; Wed, 30 Mar 2011 10:44:27 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 6C0F73A6BA9 for ; Wed, 30 Mar 2011 10:44:27 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=Nm3SJc7L3wlcojC9snsyzORkYWw1JOu3BeZkTeIwPUk= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=ZKLc-dHVtmuyFMiBmSoA:9 a=aFBtd6esOODPLeR7RIwcuVzvsaEA:4 a=QEXdDO2ut3YA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:58412] helo=[192.168.0.101]) by cdptpa-oedge02.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 9C/F7-11439-D5C639D4; Wed, 30 Mar 2011 17:46:06 +0000 From: Mike Dickson To: Dzonatas Sol In-Reply-To: <4D936430.4090401@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> <4D936430.4090401@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Mar 2011 13:46:03 -0400 Message-ID: <1301507163.12359.21.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:44:28 -0000 On Wed, 2011-03-30 at 17:11 +0000, Dzonatas Sol wrote: > Mike Dickson wrote: > > [...] So > > agreeing in advance that we should focus on "flexibility" doesn't help. > > It simply derails the important discussion about what we're talking > > about; wether service level interoperability is what we need to be > > focused on or something more (or both as 2 work streams). > > This pretty much concludes we need solid definition of "service level > interoperability" due to the fact that it is being used flexibly at the > moment to whatever best interest of said-defined parties. I know > everyone hates to hear it that way, yet let's not future push away by > such newer terminology. > > Documents exist that define partitions to region/agent protocols, so why > can't we start there? Are they too drafty? > If we can get agreement amongst a set of folks that want to work from that perspective (I do) then I agree that starting with existing "service" definitions and the partitioning of work into services and protocols is the appropriate place to (re)start. Mike From dzonatas@gmail.com Wed Mar 30 10:44:34 2011 Return-Path: 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 1D2093A6BA9 for ; Wed, 30 Mar 2011 10:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 aeT05WuVsxsY for ; Wed, 30 Mar 2011 10:44:33 -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 1931B3A6BA7 for ; Wed, 30 Mar 2011 10:44:33 -0700 (PDT) Received: by iye19 with SMTP id 19so1705891iye.31 for ; Wed, 30 Mar 2011 10:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1U0yx/hZuM3V4DkRLvFOj95Un68x+mRG+meQRigKRpY=; b=K+GuAcE/T5WIRiJSxi2eHHTMhDz9r6dq6U3Jk53Wi5qYS6IIyphTofj8HZmUP+ZpMb uyF6fHLLx4ncXdq0MMCfLW8X8T+F3nx62HDrTH9mwLhiepatjv/vrwfI0h8E0zzfMph6 MZxJJHH7WyT+KMoB1fkSM3HSaxyk1yqs0dkQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=XYTYCeaARXTEgdVrE+DYBj9zB6irmQan4w2zkB/qn7ge332jWpkjOxJ7lFe1tI4hpY G5jV/R/T3EQoLaUo/YRUcXlOaQGTZvsGYmFJKQCsCUGeu/pQeyhMeueUnHJWoQZAMS+L xXYaSL4oK7YtEiBJn+65SxFfC+aKC4gdC5Xlw= Received: by 10.231.159.203 with SMTP id k11mr1627057ibx.15.1301507172043; Wed, 30 Mar 2011 10:46:12 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id g16sm162277ibb.54.2011.03.30.10.45.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 10:46:11 -0700 (PDT) Message-ID: <4D936C33.2020602@gmail.com> Date: Wed, 30 Mar 2011 10:45:23 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 17:44:34 -0000 Morgaine wrote: > In contrast, interop between worlds serves *individuals* and *user > communities* wonderfully in numerous ways: I wouldn't doubt that some of this can be address in the same theme COLLADA has done with conditioners and refineries. The only reason to make sure the protocols work abroad would be for the most optimal network usage. The mere effort, otherwise, to get data from one system to another can be in various formats. As for VW to VW... I don't see the need for consistent optimal protocol that is custom to VWRAP. The only need (maybe illusionary) here is that being the monolithic client can connect to any of these VWs. We could, however, just pass COLLADA data to the client and that would do the same justice. Of course, this is a bit rough. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 11:06:10 2011 Return-Path: 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 069F33A6BAB for ; Wed, 30 Mar 2011 11:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 jXGo5+B4E3NC for ; Wed, 30 Mar 2011 11:06:08 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 454D83A6A83 for ; Wed, 30 Mar 2011 11:06:08 -0700 (PDT) Received: by qyk29 with SMTP id 29so2811403qyk.10 for ; Wed, 30 Mar 2011 11:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=eiDD13PWav0YYPb7jlb8beLJr/HNTTx359CpMEHOkN0=; b=sqKv48hfPWr3Sk0Fn7metl12c3F/Y4d91gbwHuRk5SNggorUpCRNp+GuMnAE6eXTxV BjcNKoTbGVor678JN/vFZZBdT9RT6Wy1v1Q4SwakjT+ZQUHFFjzaa/5tscUXMAU1vLVS dQ3vuGVn+nG5CPu9AQILD6c340yqLsQlWPTP4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tpfJIN1Bo1l59BSoqZcRo+aRMeOoiQUv3etFLQUK5l2bVRuawbfBGMWrd7wG1I7d6t 5UK1mM5YwOFSyE9611BzdU48rAMHCeGB5vWiftVNEkZtNsPvQ9BCw7TT9NGYbGS2q94C 7y+8OL9IUCroMSDUYRYCG949IvHdbWwO+DfVU= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr1394178qcr.71.1301508467010; Wed, 30 Mar 2011 11:07:47 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 11:07:46 -0700 (PDT) In-Reply-To: <4D936C33.2020602@gmail.com> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D936C33.2020602@gmail.com> Date: Wed, 30 Mar 2011 19:07:46 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caed934d0049fb70d6a Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:06:10 -0000 --000e0cd25caed934d0049fb70d6a Content-Type: text/plain; charset=ISO-8859-1 No Dzonatas, that's not enough to handle the requirement. When I TP from world X to world Y (which I may never have visited before), my identity, avatar and clothing need to persist across the teleport, and the elements that I carry with me (such as clothing) may come from many different worlds which I have visited previously, and be served from their individual asset services while I'm away touring in world Y. What's more, visiting thousands of worlds and having to make accounts at each of them is untenable, and will stop virtual worlds from flourishing. It creates a major stumbling block for user acceptance. What's needed cannot be accomplished with client-side trickery. It needs regions to understand multiple non-local asset services, and portable avatars, and single sign on, and it needs many of the protocols that we use in our region-proxied worlds to change, not only to cater for this required flexibility, but also for scalability and robustness in a distributed architecture which we've discussed here before. Morgaine. =========================== On Wed, Mar 30, 2011 at 6:45 PM, Dzonatas Sol wrote: > Morgaine wrote: > >> In contrast, interop between worlds serves *individuals* and *user >> communities* wonderfully in numerous ways: >> > > I wouldn't doubt that some of this can be address in the same theme COLLADA > has done with conditioners and refineries. The only reason to make sure the > protocols work abroad would be for the most optimal network usage. The mere > effort, otherwise, to get data from one system to another can be in various > formats. > > As for VW to VW... I don't see the need for consistent optimal protocol > that is custom to VWRAP. The only need (maybe illusionary) here is that > being the monolithic client can connect to any of these VWs. We could, > however, just pass COLLADA data to the client and that would do the same > justice. Of course, this is a bit rough. > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --000e0cd25caed934d0049fb70d6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No Dzonatas, that's not enough to handle the requirement.

When I= TP from world X to world Y (which I may never have visited before), my ide= ntity, avatar and clothing need to persist across the teleport, and the ele= ments that I carry with me (such as clothing) may come from many different = worlds which I have visited previously, and be served from their individual= asset services while I'm away touring in world Y.

What's more, visiting thousands of worlds and having to make accoun= ts at each of them is untenable, and will stop virtual worlds from flourish= ing.=A0 It creates a major stumbling block for user acceptance.

What= 's needed cannot be accomplished with client-side trickery.=A0 It needs= regions to understand multiple non-local asset services, and portable avat= ars, and single sign on, and it needs many of the protocols that we use in = our region-proxied worlds to change, not only to cater for this required fl= exibility, but also for scalability and robustness in a distributed archite= cture which we've discussed here before.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 30, 2011 at 6:45 PM, Dzonatas Sol <= ;dzonatas@gmail.com> wr= ote:
Morgaine wrote:
In contrast, interop between worlds serves *individuals* and *user communit= ies* wonderfully in numerous ways:

I wouldn't doubt that some of this can be address in the same theme COL= LADA has done with conditioners and refineries. The only reason to make sur= e the protocols work abroad would be for the most optimal network usage. Th= e mere effort, otherwise, to get data from one system to another can be in = various formats.

As for VW to VW... I don't see the need for consistent optimal protocol= that is custom to VWRAP. The only need (maybe illusionary) here is that be= ing the monolithic client can connect to any of these VWs. We could, howeve= r, just pass COLLADA data to the client and that would do the same justice.= Of course, this is a bit rough.


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--000e0cd25caed934d0049fb70d6a-- From dzonatas@gmail.com Wed Mar 30 11:22:44 2011 Return-Path: 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 11B7628C195 for ; Wed, 30 Mar 2011 11:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 Xcp0YqW8Se3k for ; Wed, 30 Mar 2011 11:22:42 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 936E33A6BB0 for ; Wed, 30 Mar 2011 11:22:42 -0700 (PDT) Received: by iwn39 with SMTP id 39so1746101iwn.31 for ; Wed, 30 Mar 2011 11:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=acs20uUgmLqL2l1xud0dHRyfQBdf9xbUHfrKCsUY4bo=; b=kTIL15tNkA1qvZanPsrLxATisQdgyimNpoZdIX8cdtYiYauJwMyS7Ari9bF38000O7 b5fB3KER52bOcZqbcijsg1eSW0XTb6gPqby33aIuJerPG7PkMnH5oxnsAg2KzJRYan2c 7EBzLvn6gQ+O9NFbJ+brX8E8POpLJn+7uax7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Sx0ThWxm4kno3czwsveD58j7CfUvi2fLmmX44mzYDLUKCHdPHddawtAGI3Z8ZBOAxU uFp9D07zDFVIgEXmal0jZLyoVocv8s34BEgUnOYftYNJZh6DZheuwmtPgtBrXnvPOzD8 mbb648nIkz/ZbFAo1KWbL9fw9o+xEQTnyuytM= Received: by 10.42.117.5 with SMTP id r5mr1454219icq.509.1301509461496; Wed, 30 Mar 2011 11:24:21 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id va4sm89041icb.15.2011.03.30.11.24.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 11:24:20 -0700 (PDT) Message-ID: <4D937539.1000001@gmail.com> Date: Wed, 30 Mar 2011 11:23:53 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D936C33.2020602@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:22:44 -0000 Morgaine wrote: > No Dzonatas, that's not enough to handle the requirement. > > When I TP from world X to world Y (which I may never have visited > before), my identity, avatar and clothing need to persist across the > teleport, and the elements that I carry with me (such as clothing) may > come from many different worlds which I have visited previously, and > be served from their individual asset services while I'm away touring > in world Y. Of course, like I said, it is rough, so there is no need to assume that it will not be handled by even less optimal formats. That point being that even the COLLADA format has conditioners/refineries that document how to do such above. The difference only being doing it LIVE and doing it through asset servers, which still are not separated from the region. > > What's more, visiting thousands of worlds and having to make accounts > at each of them is untenable, and will stop virtual worlds from > flourishing.� It creates a major stumbling block for user acceptance. > > What's needed cannot be accomplished with client-side trickery.� It > needs regions to understand multiple non-local asset services, and > portable avatars, and single sign on, and it needs many of the > protocols that we use in our region-proxied worlds to change, not only > to cater for this required flexibility, but also for scalability and > robustness in a distributed architecture which we've discussed here > before. > > Please be sure to read up on COLLADA format and notice that it is a digital asset exchange format for doing much of the above. We just need to make sure we do not reinvent the wheel (its "rough"). I think what "client-side trickery" is the pretense that there will be no need for "manufactured" objects. You stated above, however, the "manufactured" case of which assets may come from different non-local areas. No need to spin this or make such assumption as you did. Please do your homework. -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Mar 30 11:44:04 2011 Return-Path: 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 495713A6A7D for ; Wed, 30 Mar 2011 11:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 ZSOTQBYEDYoh for ; Wed, 30 Mar 2011 11:44:03 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 487333A691E for ; Wed, 30 Mar 2011 11:44:03 -0700 (PDT) Received: by iwn39 with SMTP id 39so1766368iwn.31 for ; Wed, 30 Mar 2011 11:45:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=i36nquxfwtmWOo4ypXAb1Rzk3l/EpadcBuiNt5Pnlww=; b=UeREkPcHqd0854/1GmQgtCPhH2Y1vdfMg/SJVYyMqX2NTqaCTSK3BhmvMfIlZAZwXI WkPcvRB+R/wDwdpn7X2pJAIA9qY5YFZ9XATSszohnJqqVPvsMJR4uhlpgZ2mKuAULByv pYKG9m3yRFpZ4EW+KNvV8u/gRS6TG2Qa//e1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=O9tR20bh0JwAgKbR5JnImdfCZgWIJVMSbsSLI9zcpRQQwl7TLTi2TiCcn1ol3rkb/S g3iLhZzDnzfjS1llZndmw0cu6vI+xHx/5CezawQoWuWcL6SEpKTvDOwkSYT9tmNnMT7k Wc8IB+JB5eVErp5OcorJ/RuaqMb5ALNJBQ2EY= Received: by 10.43.49.67 with SMTP id uz3mr1359989icb.526.1301510742334; Wed, 30 Mar 2011 11:45:42 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id xi12sm96729icb.18.2011.03.30.11.45.25 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 11:45:41 -0700 (PDT) Message-ID: <4D937A2D.1090505@gmail.com> Date: Wed, 30 Mar 2011 11:45:01 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Mike Dickson References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D93620C.3000505@gmail.com> <1301502034.12359.19.camel@mdickson-hplinux> <4D936430.4090401@gmail.com> <1301507163.12359.21.camel@mdickson-hplinux> In-Reply-To: <1301507163.12359.21.camel@mdickson-hplinux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 18:44:04 -0000 I hope authentication with optional PGP/GPG signed assets are part of the first level of service definitions/partitions. This may be as simple as the optional sign-on authentication debated about half-year or so ago on this list. Mike Dickson wrote: > If we can get agreement amongst a set of folks that want to work from > that perspective (I do) then I agree that starting with existing > "service" definitions and the partitioning of work into services and > protocols is the appropriate place to (re)start. > > Mike > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mike.dickson@hp.com Wed Mar 30 13:50:13 2011 Return-Path: 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 E54073A6A88 for ; Wed, 30 Mar 2011 13:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 qAYZJqm4SQR5 for ; Wed, 30 Mar 2011 13:50:12 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.123]) by core3.amsl.com (Postfix) with ESMTP id E3CA63A68F4 for ; Wed, 30 Mar 2011 13:50:11 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=2pE2Kh9Ye2ywHyyFZnC5ZQ1FvuPrdOtuPO5uN4ysVDU= c=1 sm=0 a=SNAFxGGoWQUA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=LeL_1veySWJvqq29JRgA:9 a=WO51YaM9RJ7fwHycNDwo2kyaWqcA:4 a=QEXdDO2ut3YA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:59137] helo=[192.168.0.101]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 03/F5-05159-6E7939D4; Wed, 30 Mar 2011 20:51:50 +0000 From: Mike Dickson To: Morgaine In-Reply-To: References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D936C33.2020602@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 30 Mar 2011 16:51:42 -0400 Message-ID: <1301518302.12359.27.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 20:50:14 -0000 On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote: > No Dzonatas, that's not enough to handle the requirement. > > When I TP from world X to world Y (which I may never have visited > before), my identity, avatar and clothing need to persist across the > teleport, and the elements that I carry with me (such as clothing) may > come from many different worlds which I have visited previously, and > be served from their individual asset services while I'm away touring > in world Y. And the content you carry with you may be scripted with state that needs to be propogated. And physical objects (if there is such a thing on teh target, may behave differently,... etc...). Oh yeah, and some content providers may not permit content on certain grids. The problem you want to solve is, at present, intractable. There are solvable ones that moves us in the right direction. If we take those steps just maybe we can solve the harder problems. If you make the problem impossible then we never make progress. This is BTW the different IMO between VW interop and service level interop. To do the latter I don't need to insure exactly the same behavior across platforms. Just that I can share some service definitions and therefore identity, content, etc. And that to me is a good start. Mike From vaughn.deluca@gmail.com Wed Mar 30 14:05:46 2011 Return-Path: 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 AE3553A6B97; Wed, 30 Mar 2011 14:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 77qC6DlSp6CY; Wed, 30 Mar 2011 14:05:44 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D8A163A68F4; Wed, 30 Mar 2011 14:05:43 -0700 (PDT) Received: by ewy19 with SMTP id 19so613462ewy.31 for ; Wed, 30 Mar 2011 14:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=inKTtd8NwNoT4B3gFd28JO9z29RY4PZSFZsV1EbnTIk=; b=e9qKJZGcl8bAbZNJkMTTJuprSD9m19w/mOkpzd/zGnY9mrGnsC3k6kOH1jjo5hZUrB gJrcLYvnwRSzKcqCvFjZlLfwIOR8LQq2DWRLEi0GqCKuEzzGlr4orjbAGzE/grzBAOHE sCvLX5pNqVQi4GaAOkrkx2PKgT5TNSX90sVv8= 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 :cc:content-type; b=JT591ctKvKL8pUzeQbTBOHGmnjWlPEQSvfI6wipO9C++3JcNETtYHHXdVOfpB9jwCI c+kYVYIv2HySBcvcudmY1KYZJVSgb3JdPBa+f/vY+4ugjXGIYD+r/pM3g8vWzF/E7+gw A4t/Zc9bHY+0BZkjmYKIWEyKeD3JuoorIE2Tg= MIME-Version: 1.0 Received: by 10.213.104.103 with SMTP id n39mr1221494ebo.144.1301519241819; Wed, 30 Mar 2011 14:07:21 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Wed, 30 Mar 2011 14:07:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 23:07:21 +0200 Message-ID: From: Vaughn Deluca To: kmancuso@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org, vwrap-request@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:05:46 -0000 Katherine wrote: >It seems to me that accomodating "full" interop only would reduce the >number of possible implementers and use cases for our work I am sure that nobody suggested to we restrict ourselves to "full" interop only. "Service level interop" is clearly subset of VW interoperability. You can't have VW interoperability without service level interoperability! However, If i understand Morgaine right, she is worried that the VWRAP specs will be *restricted* to service level interop only. It has been argued (sorry, I forgot by whom) that proper specifications of service level interop will give us virtual world interop for free. I think we need a bit more, but i really have a hard time envisioning how service level interop can be specified in such a way that it *prevents* VW interop, at least not if we pay attention to this aspect, and clearly we do. So in conclusion i do not see much of a problem. Izzy wrote in another tread "This whole argument between service level interop and 'full' interop eludes me." At first it eluded me to, but now i think that what is actually expressed in these discussions is the question of the scope of our effort as well as design approach. Some prefer to work bottom up, following their primary interests in getting the low level protocols working, especially since that will already be good enough for (all?) of their use cases . Some prefer a more top-down approach, first sketching the high level picture of the users perception of VW interop, and from there working downwards, obviously also because that approach optimises the realisation of *their* use cases. I think we need both, and above all, i do feel that the two approaches are not al all incompatible and both are without any doubt square within the current charter. Formally splitting our effort in two working parties along the current visible fissures and getting each to work on their own interest is a recipe for disaster. It will only strengthen the animosity that is already slowing us down tremendously, and will sustain the infighting. Rather than spitting efforts off, we need to address the causes for the current disagreement and found common ground. In my view that is not all all hard. I have been reviewing the discussion we had in September and i am actually amazed at the level of consensus that is expressed in those email exchanges. Unfortuanately we have been very bad at consolidating that consensus. As a result we recycle the same problems time and time again. The archives make very depressing reading from that point of view. We need to do more documentation for sure. I am currently going over the September discussion and looking up the places were we all agreed on the way forward. Much of that is still undocumented, and my aim is to get those points written down in the wiki. As i final point i want to make clear how I understand the term "Service Level Interop". I used the term, and since the glosary entry is still emtpy, i feel obliged to add at least my personal reading. If somebody disagrees, please add an improved version. Service level interoperability: A subset of "Virtual World Interoperability" as defined by the VWRAP protocol. Service level interoperabity loosely describes specific interactions between VWRAP endpoints. These inteactions form the glue that hold a particular virtual world together, but might just as well be used for communication between different VWRAP compatible virtual worlds (i.e. crossing trust domains). I intend to put this up in the glossary, but first will see how it flies here :) On 3/29/11, Katherine Mancuso wrote: > 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 > ---------------------------------------------------------------------------------------------- > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Wed Mar 30 14:05:57 2011 Return-Path: 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 B926F3A6B8F for ; Wed, 30 Mar 2011 14:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.522 X-Spam-Level: X-Spam-Status: No, score=-3.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 mFQPded2QhiL for ; Wed, 30 Mar 2011 14:05:55 -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 91BFE3A68F4 for ; Wed, 30 Mar 2011 14:05:55 -0700 (PDT) Received: by iye19 with SMTP id 19so1900771iye.31 for ; Wed, 30 Mar 2011 14:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oIuBi5IrG5kWlI1cOKUssWf8128cWAl4aO79f3xNHE4=; b=W/zyWr2D7Nb5gd06MHGXLB8vJa893J10MtjquLwcXm9jY7Ro3r8WkAeO31vC+nDyka Ahe1xXso4Hdn0wsACewbc3hA4QiiANsg0U7Ii1LrNvXlDi1ckp1wC89xgajK69KnoNsv sDNX944kkXv8+7UMV4/0h4AgYyk/2wsgC4Qx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Y5pOKbPHB1t2SVcCUi1JmJ7zZCIylxHwK7zs9boJzQJ4IsJXPehIGy8HQJoFtn3Hh+ 77cAQm2BwrY+D9VIGnFpc6Z/gMSFttUOMdMmoiySftnh1bNG9U14yLUPwTgPoXkmHAi1 dWwHWlsRAi2ktQq4S/Y0s/yfzWldN93QtY6G4= Received: by 10.42.136.8 with SMTP id r8mr1775419ict.151.1301519254577; Wed, 30 Mar 2011 14:07:34 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo11sm162769icb.8.2011.03.30.14.07.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 14:07:33 -0700 (PDT) Message-ID: <4D939B90.3000201@gmail.com> Date: Wed, 30 Mar 2011 14:07:28 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Mike Dickson References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D936C33.2020602@gmail.com> <1301518302.12359.27.camel@mdickson-hplinux> In-Reply-To: <1301518302.12359.27.camel@mdickson-hplinux> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:05:57 -0000 Yes, this has all been taken into consideration (state, script state, omegas, targets, etc)... and even considered what scripts run client-side and which will run region-domain. With the monolithic design, we know it's still mainly region-side, which has been also called server-side (and quite backwards in concepts to X11). Right now, if you just want to share content, there are various export and import means. I think people would want to upgrade that level with authentication, however. In the end, the region-side need not to know anything except physics and presence, as the client does most of the graphic work already. That means most of the information in the files can persist at the client-to-client level and never really needs to reach across the region-domain. This is nothing new and has been discussed before. Mike Dickson wrote: > On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote: > >> No Dzonatas, that's not enough to handle the requirement. >> >> When I TP from world X to world Y (which I may never have visited >> before), my identity, avatar and clothing need to persist across the >> teleport, and the elements that I carry with me (such as clothing) may >> come from many different worlds which I have visited previously, and >> be served from their individual asset services while I'm away touring >> in world Y. >> > > And the content you carry with you may be scripted with state that needs > to be propogated. And physical objects (if there is such a thing on teh > target, may behave differently,... etc...). Oh yeah, and some content > providers may not permit content on certain grids. > > The problem you want to solve is, at present, intractable. There are > solvable ones that moves us in the right direction. If we take those > steps just maybe we can solve the harder problems. If you make the > problem impossible then we never make progress. This is BTW the > different IMO between VW interop and service level interop. To do the > latter I don't need to insure exactly the same behavior across > platforms. Just that I can share some service definitions and therefore > identity, content, etc. And that to me is a good start. > > Mike > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 14:20:18 2011 Return-Path: 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 0F2AF28C15A for ; Wed, 30 Mar 2011 14:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.882 X-Spam-Level: X-Spam-Status: No, score=-2.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 KZViGSw0Fmac for ; Wed, 30 Mar 2011 14:20:16 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 5434928C144 for ; Wed, 30 Mar 2011 14:20:16 -0700 (PDT) Received: by qwg5 with SMTP id 5so1281444qwg.31 for ; Wed, 30 Mar 2011 14:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=wpqIvemJOI8rueiShkSGLonoj+elqL6yuYGX5cDUgNg=; b=mhrfpUFhRbY4dpknMqb/fhsX/5dQLBxPg9mK53cvANoWyM6omf7bxjYbH0Dj0i85iv kWkKOg7lg6BYZWD3wMkKULQDT+lJ11jAFa5SIlTQz9uNu7IFSYrMvlXNzNOIOdMiOzcL /RsX4Ba9guWeDT5Sngn4ZtnoD2OqwqKerhqGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=H1CQ1g0bZ3bPTZ9shDugNPlViBqq8d9buVQpq2TNMVA1wgzxsydQt6DpP397nLrkRV hdSMy84SHQ7ebbJz3dXIOhvxO1wdZbA65GxXfPs4Y7TYX6ETL5vRDxwvjixJv4IbvQHF 4J7UC965WDf0xOllhnIcZ5+1/QL5ilkaPU1Ok= MIME-Version: 1.0 Received: by 10.229.62.8 with SMTP id v8mr1620612qch.33.1301520114794; Wed, 30 Mar 2011 14:21:54 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 14:21:54 -0700 (PDT) In-Reply-To: <1301518302.12359.27.camel@mdickson-hplinux> References: <20110330011458.GB8908@alinoe.com> <4D931434.2030206@boroon.dasgupta.ch> <4646639E08F58B42836FAC24C94624DD92FDE22F3F@GVW0433EXB.americas.hpqcorp.net> <1301499645.12359.10.camel@mdickson-hplinux> <4D936C33.2020602@gmail.com> <1301518302.12359.27.camel@mdickson-hplinux> Date: Wed, 30 Mar 2011 22:21:54 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180db21c4129049fb9c4d8 Subject: Re: [vwrap] Statements of Consensus. Flexibity First. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:20:18 -0000 --90e6ba180db21c4129049fb9c4d8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 30, 2011 at 9:51 PM, Mike Dickson wrote: > On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote: > > > When I TP from world X to world Y (which I may never have visited > > before), my identity, avatar and clothing need to persist across the > > teleport, and the elements that I carry with me (such as clothing) may > > come from many different worlds which I have visited previously, and > > be served from their individual asset services while I'm away touring > > in world Y. > > And the content you carry with you may be scripted with state that needs > to be propogated. And physical objects (if there is such a thing on teh > target, may behave differently,... etc...). Oh yeah, and some content > providers may not permit content on certain grids. > > The problem you want to solve is, at present, intractable. Wrong, Mike. It's you who added two "intractable" problems just now (scripting and simulation), not me. Every piece that I mentioned is easily tractable, and indeed we have been discussing elements of how to do it here all along. It's not a hard problem at all. It mostly just requires avoiding singletons for services. Of course if you wanted to replicate Second Life portably as a standard, that is a highly intractable problem, but we have never had that as a goal here, and I in particular have never suggested that any such thing is needed for VW tourism. Not only is it not needed, but nobody would implement those things as Linden Lab has done them anyway if they were doing it afresh for a spec. (They would undoubtedly be using an industry standard scripting language, for starters.) So no, you've just raised a straw man of your own invention and then knocked it down. Your response is incorrect for the requirement given. Morgaine. =================== On Wed, Mar 30, 2011 at 9:51 PM, Mike Dickson wrote: > On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote: > > No Dzonatas, that's not enough to handle the requirement. > > > > When I TP from world X to world Y (which I may never have visited > > before), my identity, avatar and clothing need to persist across the > > teleport, and the elements that I carry with me (such as clothing) may > > come from many different worlds which I have visited previously, and > > be served from their individual asset services while I'm away touring > > in world Y. > > And the content you carry with you may be scripted with state that needs > to be propogated. And physical objects (if there is such a thing on teh > target, may behave differently,... etc...). Oh yeah, and some content > providers may not permit content on certain grids. > > The problem you want to solve is, at present, intractable. There are > solvable ones that moves us in the right direction. If we take those > steps just maybe we can solve the harder problems. If you make the > problem impossible then we never make progress. This is BTW the > different IMO between VW interop and service level interop. To do the > latter I don't need to insure exactly the same behavior across > platforms. Just that I can share some service definitions and therefore > identity, content, etc. And that to me is a good start. > > Mike > > > > --90e6ba180db21c4129049fb9c4d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2011 at 9:51 PM, Mike Dickson <mike.dickson@hp.com> wrote:
On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote:

> When I TP from world X to world Y (which I may never have visited
> before), my identity, avatar and clothing need to persist across the > teleport, and the elements that I carry with me (such as clothing) may=
> come from many different worlds which I have visited previously, and > be served from their individual asset services while I'm away tour= ing
> in world Y.

And the content you carry with you may be scripted with state that ne= eds
to be propogated. And physical objects (if there is such a thing on teh
target, may behave differently,... etc...). =A0 Oh yeah, and some content providers may not permit content on certain grids.

The problem you want to solve is, at present, intractable.


Wrong, Mike.

It's you who added two "intractable&q= uot; problems just now (scripting and simulation), not me. Every piece that= I mentioned is easily tractable, and indeed we have been discussing elemen= ts of how to do it here all along.=A0 It's not a hard problem at all.= =A0 It mostly just requires avoiding singletons for services.

Of course if you wanted to replicate Second Life portably as a st= andard, that is a highly intractable problem, but we have never had that as= a goal here, and I in particular have never suggested that any such thing = is needed for VW tourism.=A0 Not only is it not needed, but nobody would im= plement those things as Linden Lab has done them anyway if they were doing = it afresh for a spec.=A0 (They would undoubtedly be using an industry stand= ard scripting language, for starters.)

So no, you've just raised a straw man of your own invention and the= n knocked it down.=A0 Your response is incorrect for the requirement given.=


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 30, 2011 at 9:51 PM, Mike Dickson <mike.dickson@hp.com> wrote:
On Wed, 2011-03-30 at 18:07 +0000, Morgaine wrote:
> No Dzonatas, that's not enough to handle the requirement.
>
> When I TP from world X to world Y (which I may never have visited
> before), my identity, avatar and clothing need to persist across the > teleport, and the elements that I carry with me (such as clothing) may=
> come from many different worlds which I have visited previously, and > be served from their individual asset services while I'm away tour= ing
> in world Y.

And the content you carry with you may be scripted with state that ne= eds
to be propogated. And physical objects (if there is such a thing on teh
target, may behave differently,... etc...). =A0 Oh yeah, and some content providers may not permit content on certain grids.

The problem you want to solve is, at present, intractable. =A0There are
solvable ones that moves us in the right direction. If we take those
steps just maybe we can solve the harder problems. =A0If you make the
problem impossible then we never make progress. =A0This is BTW the
different IMO between VW interop and service level interop. =A0To do the latter I don't need to insure exactly the same behavior across
platforms. Just that I can share some service definitions and therefore
identity, content, etc. =A0And that to me is a good start.

Mike




--90e6ba180db21c4129049fb9c4d8-- From kmancuso@gmail.com Wed Mar 30 14:25:20 2011 Return-Path: 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 3AF983A6BD0; Wed, 30 Mar 2011 14:25:20 -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 tuxa5emSg63e; Wed, 30 Mar 2011 14:25:19 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 4012E3A6BCE; Wed, 30 Mar 2011 14:25:19 -0700 (PDT) Received: by iwn39 with SMTP id 39so1920782iwn.31 for ; Wed, 30 Mar 2011 14:26:58 -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=QgZt/fNafhsx76xcNkLAG8Pgcs7L4M4kg62h3F1deTQ=; b=Eds93b2SavK7lfrLbMudYKSXv5Eg9OrgZRq9FUaoTr9YiZ0m2FvE/IdeciTk5+6hah eewQxm21uwCfkSqBDBlcp+GMWeloTA4ZQj0rVW/Q3nfb3SA9KlLIjxFBQW1u+ZyK/XPY PJ3za2w+5QvoysCvOMgp536ReN3uT/P78Tcxo= 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=AtqIQvishfyta4uXBIrdrHMwvnzqIiBJQ4tY+2T1AQowiOjyO3iogMhy6VWlcoYLYs G3DswezzeHkpICAoZ6F9G80iTS9/rTwBpcj5+Ww9PTdPGqaKEQoh/7WXIGaJ9rHTR4Fp Jwu+dT//tVfNK/F5UhGVcbZnTukGs4XCP8bbE= Received: by 10.231.142.103 with SMTP id p39mr606072ibu.178.1301520418078; Wed, 30 Mar 2011 14:26:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.143.131 with HTTP; Wed, 30 Mar 2011 14:26:37 -0700 (PDT) In-Reply-To: References: From: Katherine Mancuso Date: Wed, 30 Mar 2011 14:26:37 -0700 Message-ID: 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 29 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:25:20 -0000 Hey Dzonatas, I've seen you raise the server-client distinction issue a couple times. I actually raised this, particularly with respect to Mark Lentzcner's draft, at the last WG F2F (which, wow, was a whole year ago now). I'd like to note that these words are being used inconsistently and unclearly in some of our existing drafts and we need to push to use more precise language and if we're going to use these words (which are fairly weak because they have a lot of existing meanings) make sure we define them consistently in the glossary. There's a big problem in particular between distinguishing region & server. 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 ---------------------------------------------------------------------------------------------- From dzonatas@gmail.com Wed Mar 30 14:44:37 2011 Return-Path: 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 3855B3A6BD3; Wed, 30 Mar 2011 14:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 0Q9hP9KgV7di; Wed, 30 Mar 2011 14:44:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 55A293A693D; Wed, 30 Mar 2011 14:44:36 -0700 (PDT) Received: by iwn39 with SMTP id 39so1938688iwn.31 for ; Wed, 30 Mar 2011 14:46:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/D3HkVhcagzJ2CIVB4vi+nV6vGHsqeMdmgZfZ1HClrY=; b=aQmwB+Q/N3gnENQ74X7/hgUEAyLedd4qf+Q8rTJTMabBSGTVpw9JdR0vjhX/vdFdLZ jr8pc39RmWCMrX21iv8EMuTBurKealkJld6tQkB1YZLKxtVD4j4yEwhVDeXpB70r5gN6 ZxJvZLIwZwHZexjeytzlv6N9ahxsc/T3ESRYk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SQN7bELDX+b5QrEjr2ZK3x16lrSuAG+mjirBY93zFoZI3ruOovfXidAFt/QXF7/bOa 2MO2ErPGPLsMwVEMhSe42JdkONNPsjNSzuJCIUBbQBl8BRDb2DDWQ0OqIhwp2N3Np9KY HfOTt0/3LzIShYK/UBfLJWBGwUk70b6HrofZo= Received: by 10.43.49.10 with SMTP id uy10mr1662649icb.407.1301521575349; Wed, 30 Mar 2011 14:46:15 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id 8sm278437iba.4.2011.03.30.14.46.11 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 14:46:14 -0700 (PDT) Message-ID: <4D93A4A3.9060608@gmail.com> Date: Wed, 30 Mar 2011 14:46:11 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: kmancuso@gmail.com References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, vwrap-request@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 29 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:44:37 -0000 Indeed, let me add the client/server at the source code level really only refers to who initiates the connection and who authenticates. That may create even more confusion when, in full duplex and multi-point, the client/server roles could switch any moment based on availability of protocols and capabilities. To use these transfer-level terminology at any higher-level definition is surely to continue to create such unclarity. From a provider level, they probably want to be known as the "server", where avatars can connect. That may seem simple, but it is backwards in the source level. To do such means that the implementations can not use such language, or suffer headaches to wrap one mindsets around non-implementor's dream. I think there was some vote to narrow some terminology to client/server on this list within the time you noted. Whatever happens, let us please keep in mind the diction at the source level. Katherine Mancuso wrote: > Hey Dzonatas, > > I've seen you raise the server-client distinction issue a couple > times. I actually raised this, particularly with respect to Mark > Lentzcner's draft, at the last WG F2F (which, wow, was a whole year > ago now). I'd like to note that these words are being used > inconsistently and unclearly in some of our existing drafts and we > need to push to use more precise language and if we're going to use > these words (which are fairly weak because they have a lot of existing > meanings) make sure we define them consistently in the glossary. > There's a big problem in particular between distinguishing region & > server. > > Katherine > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From dzonatas@gmail.com Wed Mar 30 14:54:34 2011 Return-Path: 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 3632C3A6AC8; Wed, 30 Mar 2011 14:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.232 X-Spam-Level: X-Spam-Status: No, score=-3.232 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 2r1gH0mEQKAp; Wed, 30 Mar 2011 14:54:32 -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 8DC093A6ABD; Wed, 30 Mar 2011 14:54:32 -0700 (PDT) Received: by iye19 with SMTP id 19so1945519iye.31 for ; Wed, 30 Mar 2011 14:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=wRJIRXk0baKb4kNEurdn5eKZrkViDU6p0/8BjB7J5B8=; b=cKLpenHVi3nE7iICj7CWaw5vtCEsveQVMx5uBroSypzghh4EBjYfSV7SGjr5VTgVu0 nK8b8ZSshBt5LPhLN0pKu0TW2okoLnJF8+7Cg1TVgaxG80pgpq8lcQ8uQu0Fas0BkvYP VPVqhheX8VVjoCpc5xMJL12M5gkPCp2Rm1jiM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tdWBSZPyIC2IQ4QiiM2aawbtQEO9iM84ycDuH/dSi50ItcWtA/YwjWrnWVZv7sx0IW sNiyRveqiCiIWBJz1sz1n2Eszy4nfeidd7RdyWvoox8HluNBxICilclWVWphoooMnhR5 J7J9hW88r7QwandRKs2gCPVPgEoVvMVBATQLM= Received: by 10.42.222.71 with SMTP id if7mr1808201icb.271.1301522171479; Wed, 30 Mar 2011 14:56:11 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id jv9sm188188icb.1.2011.03.30.14.56.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 14:56:10 -0700 (PDT) Message-ID: <4D93A6FC.2080401@gmail.com> Date: Wed, 30 Mar 2011 14:56:12 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Vaughn Deluca References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org, vwrap-request@ietf.org, kmancuso@gmail.com Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 21:54:34 -0000 Maybe some see "interop" the same and as seamless as "region-crossing" now does with such speed and nature. Perhaps that is where some would like to redefine VW interop and service level interop. For now, I'm mainly concerned about what has been said "agent-domain" in order to localize inventory such that it is not stuck in the said "region-domain." I'd imagine this will mean start a-new due to the many issues of licenses with current inventory design stuck on the said server/region-domain. Vaughn Deluca wrote: > Katherine wrote: > >> It seems to me that accomodating "full" interop only would reduce the >> number of possible implementers and use cases for our work >> > > I am sure that nobody suggested to we restrict ourselves to "full" > interop only. > "Service level interop" is clearly subset of VW interoperability. You > can't have VW interoperability without service level interoperability! > However, If i understand Morgaine right, she is worried that the VWRAP > specs will be *restricted* to service level interop only. > > It has been argued (sorry, I forgot by whom) that proper > specifications of service level interop will give us virtual world > interop for free. I think we need a bit more, but i really have a hard > time envisioning how service level interop can be specified in such a > way that it *prevents* VW interop, at least not if we pay attention to > this aspect, and clearly we do. So in conclusion i do not see much of > a problem. > > Izzy wrote in another tread "This whole argument between service level > interop and 'full' interop eludes me." At first it eluded me to, but > now i think that what is actually expressed in these discussions is > the question of the scope of our effort as well as design approach. > Some prefer to work bottom up, following their primary interests in > getting the low level protocols working, especially since that will > already be good enough for (all?) of their use cases . Some prefer a > more top-down approach, first sketching the high level picture of the > users perception of VW interop, and from there working downwards, > obviously also because that approach optimises the realisation of > *their* use cases. > > I think we need both, and above all, i do feel that the two approaches > are not al all incompatible and both are without any doubt square > within the current charter. > Formally splitting our effort in two working parties along the current > visible fissures and getting each to work on their own interest is a > recipe for disaster. It will only strengthen the animosity that is > already slowing us down tremendously, and will sustain the infighting. > Rather than spitting efforts off, we need to address the causes for > the current disagreement and found common ground. In my view that is > not all all hard. > > I have been reviewing the discussion we had in September and i am > actually amazed at the level of consensus that is expressed in those > email exchanges. Unfortuanately we have been very bad at consolidating > that consensus. As a result we recycle the same problems time and time > again. The archives make very depressing reading from that point of > view. We need to do more documentation for sure. > > I am currently going over the September discussion and looking up the > places were we all agreed on the way forward. Much of that is still > undocumented, and my aim is to get those points written down in the > wiki. > > As i final point i want to make clear how I understand the term > "Service Level Interop". I used the term, and since the glosary entry > is still emtpy, i feel obliged to add at least my personal reading. If > somebody disagrees, please add an improved version. > > Service level interoperability: > A subset of "Virtual World Interoperability" as defined by the VWRAP > protocol. Service level interoperabity loosely describes specific > interactions between VWRAP endpoints. These inteactions form the glue > that hold a particular virtual world together, but might just as well > be used for communication between different VWRAP compatible virtual > worlds (i.e. crossing trust domains). > > I intend to put this up in the glossary, but first will see how it > flies here :) > > On 3/29/11, Katherine Mancuso wrote: > >> 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 >> ---------------------------------------------------------------------------------------------- >> _______________________________________________ >> 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 > > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 15:39:02 2011 Return-Path: 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 796593A6B65 for ; Wed, 30 Mar 2011 15:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 JeDTgF9qKGV3 for ; Wed, 30 Mar 2011 15:39:00 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id E3F703A6ACF for ; Wed, 30 Mar 2011 15:38:59 -0700 (PDT) Received: by qyk7 with SMTP id 7so1222878qyk.10 for ; Wed, 30 Mar 2011 15:40:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IRMqTpA2/KUVLJu5Ncq4hx8I9Bg9SBYF/OadZ7NKGbI=; b=pJTONnAK+DOF2A+eyKK36nqpXbOE0GwQ42UfE9CSmdSxlsdqD8uxqINiuy9PcYCAhn natLGmIIy5UVZVPLBp+RCfTocyvp/Jx0qqf3llssyDLGxWq2Ezc7gq/z+g9cavKhhz+t YHkA77vTX00AMH84+83g+ARCDxp34+LLUssFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=tTGq5O3DK2FMP9Q3zAr4BcZJ2pIjPZ9GjKaU0QaCOMJNRXgjgHeXW0Qsc0UReEpQTg z2ZDvpgfLdfJjZBLe/8NoPZQOz00F+XVeR/fGMBHWmNZ6Sa8iBhiCgBdU53+V7qYGTQw XwFbCqGHjKmvN7VECmMAaybZK1nqQbOnXgcA8= MIME-Version: 1.0 Received: by 10.229.62.8 with SMTP id v8mr1676667qch.33.1301524838697; Wed, 30 Mar 2011 15:40:38 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 15:40:38 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 23:40:38 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba180db2ad4a4c049fbadd8f Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 22:39:02 -0000 --90e6ba180db2ad4a4c049fbadd8f Content-Type: text/plain; charset=ISO-8859-1 Very well put, Vaughn. Regarding "service level interoperability", it's not really a subset of VW interoperability at all, but lies orthogonal to it because it is a property of all multipart systems that implement services. I'll try to explain. Client-server systems for example have at least two distinct parts with distinct roles, server(s) and client(s). Service-level interoperability typically consists of designing and specifying the protocols or interfaces between them in such a way that any part of the system is interchangeable with another equivalent part that performs the same role, say from a different manufacturer, and the system as a whole still continues to work normally. This rarely needs to be honored with a fancy title such as "service level interoperability" in these days of IETF standards and highly cross-platform web applications. Historically however, applications did not behave quite so nicely, and vendors often sought to lock customers in with hidden proprietary interfaces, so there was a need for adding "service level interoperability" to the tendering documentation in days gone by, to avoid surprises later on. Today, the need for that has almost disappeared, and if your online service has a documented protocol interface then "service level interoperability" is virtually assured without doing anything at all, assuming normal commonsense has prevailed during development (and there is no deliberate obfuscation of course). There is only one other area of this topic where a little more needs to be said. Protocol messages can normally be validated syntactically to a strong degree, and whether a message is correct or not is normally known immediately upon syntactic validation. Unfortunately, that is not always the end of the story, because protocols can transport complex data items which are valid syntactically yet invalid semantically. This is the last vestige of where that term is commonly encountered, as *Service Level Semantic Interoperability*. Is it relevant to us? Yes, a little. For example, it would do us no good to transport Collada meshes from an asset service to a client that tries to render them as some other graphics format --- that would create a semantic mishap, because one party thinks that the items means one thing and another party applies a different semantic. So yes, there is a little more for us to consider here, but it's not a lot. In most part we have already stated the solution every time that we have mentioned MIME types for describing content. This is mostly a solved problem. There may be one or two other areas where we have to specify the required semantic alongside the simple matter of protocol syntax, but that's a standard part of defining protocols. There is nothing really new here. Lastly, service level interoperability focuses entirely on single services and their clients, so it's unrelated to interoperability between multiple services, such as a set of virtual world services. This means that, apart from defining type semantics, it doesn't get us even a step closer towards interop between virtual worlds. Morgaine. ========================== On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca wrote: > Katherine wrote: > >It seems to me that accomodating "full" interop only would reduce the > >number of possible implementers and use cases for our work > > I am sure that nobody suggested to we restrict ourselves to "full" > interop only. > "Service level interop" is clearly subset of VW interoperability. You > can't have VW interoperability without service level interoperability! > However, If i understand Morgaine right, she is worried that the VWRAP > specs will be *restricted* to service level interop only. > > It has been argued (sorry, I forgot by whom) that proper > specifications of service level interop will give us virtual world > interop for free. I think we need a bit more, but i really have a hard > time envisioning how service level interop can be specified in such a > way that it *prevents* VW interop, at least not if we pay attention to > this aspect, and clearly we do. So in conclusion i do not see much of > a problem. > > Izzy wrote in another tread "This whole argument between service level > interop and 'full' interop eludes me." At first it eluded me to, but > now i think that what is actually expressed in these discussions is > the question of the scope of our effort as well as design approach. > Some prefer to work bottom up, following their primary interests in > getting the low level protocols working, especially since that will > already be good enough for (all?) of their use cases . Some prefer a > more top-down approach, first sketching the high level picture of the > users perception of VW interop, and from there working downwards, > obviously also because that approach optimises the realisation of > *their* use cases. > > I think we need both, and above all, i do feel that the two approaches > are not al all incompatible and both are without any doubt square > within the current charter. > Formally splitting our effort in two working parties along the current > visible fissures and getting each to work on their own interest is a > recipe for disaster. It will only strengthen the animosity that is > already slowing us down tremendously, and will sustain the infighting. > Rather than spitting efforts off, we need to address the causes for > the current disagreement and found common ground. In my view that is > not all all hard. > > I have been reviewing the discussion we had in September and i am > actually amazed at the level of consensus that is expressed in those > email exchanges. Unfortuanately we have been very bad at consolidating > that consensus. As a result we recycle the same problems time and time > again. The archives make very depressing reading from that point of > view. We need to do more documentation for sure. > > I am currently going over the September discussion and looking up the > places were we all agreed on the way forward. Much of that is still > undocumented, and my aim is to get those points written down in the > wiki. > > As i final point i want to make clear how I understand the term > "Service Level Interop". I used the term, and since the glosary entry > is still emtpy, i feel obliged to add at least my personal reading. If > somebody disagrees, please add an improved version. > > Service level interoperability: > A subset of "Virtual World Interoperability" as defined by the VWRAP > protocol. Service level interoperabity loosely describes specific > interactions between VWRAP endpoints. These inteactions form the glue > that hold a particular virtual world together, but might just as well > be used for communication between different VWRAP compatible virtual > worlds (i.e. crossing trust domains). > > I intend to put this up in the glossary, but first will see how it > flies here :) > > On 3/29/11, Katherine Mancuso wrote: > > 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 > > > ---------------------------------------------------------------------------------------------- > > _______________________________________________ > > 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 > --90e6ba180db2ad4a4c049fbadd8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very well put, Vaughn.

Regarding "service level interoperabilit= y", it's not really a subset of VW interoperability at all, but li= es orthogonal to it because it is a property of all multipart systems that = implement services.=A0 I'll try to explain.

Client-server systems for example have at least two distinct parts with= distinct roles, server(s) and client(s).=A0 Service-level interoperability= typically consists of designing and specifying the protocols or interfaces= between them in such a way that any part of the system is interchangeable = with another equivalent part that performs the same role, say from a differ= ent manufacturer, and the system as a whole still continues to work normall= y.

This rarely needs to be honored with a fancy title such as "servic= e level interoperability" in these days of IETF standards and highly c= ross-platform web applications.=A0 Historically however, applications did n= ot behave quite so nicely, and vendors often sought to lock customers in wi= th hidden proprietary interfaces, so there was a need for adding "serv= ice level interoperability" to the tendering documentation in days gon= e by, to avoid surprises later on.

Today, the need for that has almost disappeared, and if your online ser= vice has a documented protocol interface then "service level interoper= ability" is virtually assured without doing anything at all, assuming = normal commonsense has prevailed during development (and there is no delibe= rate obfuscation of course).=A0 There is only one other area of this topic = where a little more needs to be said.

Protocol messages can normally be validated syntactically to a strong d= egree, and whether a message is correct or not is normally known immediatel= y upon syntactic validation.=A0 Unfortunately, that is not always the end o= f the story, because protocols can transport complex data items which are v= alid syntactically yet invalid semantically.

This is the last vestige of where that term is commonly encountered, as= Service Level Semantic Interoperability.=A0 Is it relevant to us?= =A0 Yes, a little.=A0 For example, it would do us no good to transport Coll= ada meshes from an asset service to a client that tries to render them as s= ome other graphics format --- that would create a semantic mishap, because = one party thinks that the items means one thing and another party applies a= different semantic.=A0 So yes, there is a little more for us to consider h= ere, but it's not a lot.=A0 In most part we have already stated the sol= ution every time that we have mentioned MIME types for describing content.= =A0 This is mostly a solved problem.

There may be one or two other areas where we have to specify the requir= ed semantic alongside the simple matter of protocol syntax, but that's = a standard part of defining protocols.=A0 There is nothing really new here.=

Lastly, service level interoperability focuses entirely on single servi= ces and their clients, so it's unrelated to interoperability between mu= ltiple services, such as a set of virtual world services.=A0 This means tha= t, apart from defining type semantics, it doesn't get us even a step cl= oser towards interop between virtual worlds.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca &= lt;vaughn.deluca@gmail.com&g= t; wrote:
Katherine wrote:
>It seems to me that accomodating "full" interop only would re= duce the
>number of possible implementers and use cases for our work

I am sure that nobody =A0suggested to we restrict ourselves to "= full"
interop only.
"Service level interop" is clearly subset of VW interoperability.= You
can't have VW interoperability without service level interoperability!<= br> However, If i understand Morgaine right, she is worried that the VWRAP
specs will be *restricted* to service level interop only.

It has been argued (sorry, I forgot by whom) that proper
specifications of service level interop will give us virtual world
interop for free. I think we need a bit more, but i really have a hard
time envisioning how service level interop can be specified in such a
way that it *prevents* VW interop, at least not if we pay attention to
this aspect, and clearly we do. So in conclusion i do not see much of
a problem.

Izzy wrote in another tread "This whole argument between service level=
interop and 'full' interop eludes me." At first it eluded me t= o, but
now i think that what is actually expressed in these discussions is
the question of the scope of our effort as well as design approach.
Some prefer to work bottom up, following their primary interests in
getting the low level protocols working, especially since that will
already be good enough for (all?) of their use cases . Some prefer a
more top-down approach, first sketching the high level picture of the
users perception of VW interop, =A0and from there working downwards,
obviously also because that approach optimises the realisation of
*their* use cases.

I think we need both, and above all, i do feel that the two approaches
are not al all incompatible and both are without any doubt square
within the current charter.
Formally splitting our effort in two working parties along the current
visible fissures and getting each to work on their own interest is a
recipe for disaster. It will only strengthen the animosity that is
already slowing us down tremendously, and will sustain the infighting.
Rather than spitting efforts off, we need to address the causes for
the current disagreement and found common ground. =A0In my view that is
not all all hard.

I have been reviewing the discussion we had in September and i am
actually amazed at the level of consensus that is expressed in those
email exchanges. Unfortuanately we have been very bad at consolidating
that consensus. As a result we recycle the same problems time and time
again. The archives make very depressing reading from that point of
view. We need to do more documentation for sure.

I am currently going over the September discussion and looking up the
places were we all agreed on the way forward. =A0Much of that is still
undocumented, and my aim is to get those points written down in the
wiki.

As i final point i want to make clear how I understand the term
"Service Level Interop". I used the term, and since the glosary e= ntry
is still emtpy, i feel obliged to add at least my personal reading. If
somebody disagrees, please add an improved version.

Service level interoperability:
=A0 =A0 =A0 =A0A subset of "Virtual World Interoperability" as d= efined by the VWRAP
protocol. Service level interoperabity loosely describes specific
interactions between VWRAP endpoints. These inteactions form the glue
that hold a particular virtual world together, but might just as well
be used for communication between different VWRAP compatible virtual
worlds (i.e. crossing trust domains).

I intend to put this up in the glossary, but first will see how it
flies here =A0:)

On 3/29/11, Katherine Mancuso <kma= ncuso@gmail.com> wrote:
> Hi everyone,
>
> I want to speak up for agreeing with Meadhbh & Mike about keeping = a
> role for service level interop in this group. =A0We'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. =A0I'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 to= gether on
> a draft specification that is something like the intro or David's<= br> > piece in scope that lays out which specific capacities would need to > be supported at a minimum to allow for "full" interop, perha= ps getting
> input from implementers such as the Hypergrid folks and the folks who<= br> > coordinated the teleport test at Linden? =A0Citing 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 tha= t 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. =A0Im= plementers
> could then choose their path based on their use cases: implement the > "full" interop specification including all the specification= s called
> for, or implement individual services. =A0I 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<= br> > 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 r= educe 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<= br> > 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. =A0However, a shared asset server that contains a<= br> > 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. =A0This 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. =A0Sharing an asset server might be of interest to > them, but so too might "full" interop. =A0They'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 allo= w
> 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 Apr= il,
> 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://face= book.com/kmancuso
> = http://www.linkedin.com/in/kathymancuso
> Second Life: Muse Carmona
> ----------------------------------------------------------------------= ------------------------
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--90e6ba180db2ad4a4c049fbadd8f-- From dzonatas@gmail.com Wed Mar 30 15:47:55 2011 Return-Path: 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 BE6F928C0F7 for ; Wed, 30 Mar 2011 15:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.518 X-Spam-Level: X-Spam-Status: No, score=-3.518 tagged_above=-999 required=5 tests=[AWL=0.081, 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 q0fj6QGXSR1H for ; Wed, 30 Mar 2011 15:47:55 -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 E69F828C0F1 for ; Wed, 30 Mar 2011 15:47:54 -0700 (PDT) Received: by iye19 with SMTP id 19so1990997iye.31 for ; Wed, 30 Mar 2011 15:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oqD01kU1z3dGpx6w/9RBdW2WLtmtnd5TVdtEHWzu+IA=; b=ZSqcYghH2RTxs2+1qmWmhgsZZaZU2G61uMcKz/N5AaF3ASW11qwgl+4pkG4kN441m0 fvcqQrJ9M2LIqSgu9rp1P5wrpsSrNeP4PO1ZvUcrVFtaHYx7ncTThP6sbe/Oe8szmHOZ MRXxk/x6C2iqXTonUwF4BUj3SJHd8c6tCo0nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hXNBfT5ATHWY31TDk0fBrvgKNivATWcCuHCHCZ5kIGRFNxVMR3glq3WARuJz6ZNBh8 lJchTfreq2tJ6YuLgjdhIz1exmAo7oPLOr5rW8KJIR5D7GabmnUjlhWkrZvxj/ny7BJ2 6h27xHfbH7WfGDbzZ3bx84U2qfuAv1BoTkfBE= Received: by 10.42.155.194 with SMTP id v2mr1934220icw.491.1301525373744; Wed, 30 Mar 2011 15:49:33 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id y10sm299087iba.63.2011.03.30.15.49.28 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 15:49:32 -0700 (PDT) Message-ID: <4D93B378.8030302@gmail.com> Date: Wed, 30 Mar 2011 15:49:28 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 22:47:55 -0000 Remember, that COLLADA is only an exchange format, not the format for which something is being rendered from or to. Please make sure your semantic usage of such at least complies when you try to argue with it. Morgaine wrote: > This is the last vestige of where that term is commonly encountered, > as *Service Level Semantic Interoperability*.� Is it relevant to us?� > Yes, a little.� For example, it would do us no good to transport > Collada meshes from an asset service to a client that tries to render > them as some other graphics format --- that would create a semantic > mishap, because one party thinks that the items means one thing and > another party applies a different semantic.� So yes, there is a little > more for us to consider here, but it's not a lot.� In most part we > have already stated the solution every time that we have mentioned > MIME types for describing content.� This is mostly a solved problem. > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 16:07:25 2011 Return-Path: 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 8F25528C0E8 for ; Wed, 30 Mar 2011 16:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.876 X-Spam-Level: X-Spam-Status: No, score=-2.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 AKI6mXlU+5px for ; Wed, 30 Mar 2011 16:07:24 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9960428C0F1 for ; Wed, 30 Mar 2011 16:07:23 -0700 (PDT) Received: by qwg5 with SMTP id 5so1333076qwg.31 for ; Wed, 30 Mar 2011 16:09:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2qDPEayPjDvHQh/r6q1UR38GX0gXlPohy62E7YiryhY=; b=E1iCFuHVUeWTaXIZKz1XLMI4nD2QyrpBNvvC4gOuNfBQA3fAzETw8tL6jjksmGV6i+ sy3X7DmiFvPcG9J/ettL+berZsFrCFLwZdwwReADONRHxbBScTHGW+bBJwu1kbOvutk5 gajHtqhwQYFtLRxUMSqMFPDfLKRqyvbwl9530= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=hH19gHeTByLrP8quUPha8JergrfQg74LVa8jL4mnPcsqUC/YjzTnhU0b2OEIvER7cc wOLtMlX56kNZoD4/LEReD5mWjk9U2HcOxw/2qk/Znv0AA3Kv1JT2ZB5kn4kRkSEZWoya hWRZVlKhQ1pCVTMTwlqXpJD/ahTgOa1YYq8c0= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr1636580qck.109.1301526542552; Wed, 30 Mar 2011 16:09:02 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 16:09:02 -0700 (PDT) In-Reply-To: <4D93B378.8030302@gmail.com> References: <4D93B378.8030302@gmail.com> Date: Thu, 31 Mar 2011 00:09:02 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d3563c114c049fbb4325 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:07:25 -0000 --00235429d3563c114c049fbb4325 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable COLLADA is not *only* an interchange format, despite being defined for that purpose originally. Many applications now use it as their native graphics file format, the archetypal case being Google Earth. I expect such use to become ever more common in the future. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Wed, Mar 30, 2011 at 11:49 PM, Dzonatas Sol wrote: > Remember, that COLLADA is only an exchange format, not the format for whi= ch > something is being rendered from or to. Please make sure your semantic us= age > of such at least complies when you try to argue with it. > > > Morgaine wrote: > >> This is the last vestige of where that term is commonly encountered, as >> *Service Level Semantic Interoperability*.=EF=BF=BD Is it relevant to us= ?=EF=BF=BD Yes, a >> little.=EF=BF=BD For example, it would do us no good to transport Collad= a meshes >> from an asset service to a client that tries to render them as some othe= r >> graphics format --- that would create a semantic mishap, because one par= ty >> thinks that the items means one thing and another party applies a differ= ent >> semantic.=EF=BF=BD So yes, there is a little more for us to consider her= e, but it's >> not a lot.=EF=BF=BD In most part we have already stated the solution eve= ry time that >> we have mentioned MIME types for describing content.=EF=BF=BD This is mo= stly a >> solved problem. >> >> > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00235429d3563c114c049fbb4325 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable COLLADA is not only an interchange format, despite being defined for= that purpose originally.=C2=A0 Many applications now use it as their nativ= e graphics file format, the archetypal case being Google Earth.=C2=A0 I exp= ect such use to become ever more common in the future.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On W= ed, Mar 30, 2011 at 11:49 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
Remember, that CO= LLADA is only an exchange format, not the format for which something is bei= ng rendered from or to. Please make sure your semantic usage of such at lea= st complies when you try to argue with it.


Morgaine wrote:
This is the last vestige of where that term is commonly encountered, as *Se= rvice Level Semantic Interoperability*.=EF=BF=BD Is it relevant to us?=EF= =BF=BD Yes, a little.=EF=BF=BD For example, it would do us no good to trans= port Collada meshes from an asset service to a client that tries to render = them as some other graphics format --- that would create a semantic mishap,= because one party thinks that the items means one thing and another party = applies a different semantic.=EF=BF=BD So yes, there is a little more for u= s to consider here, but it's not a lot.=EF=BF=BD In most part we have a= lready stated the solution every time that we have mentioned MIME types for= describing content.=EF=BF=BD This is mostly a solved problem.



--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--00235429d3563c114c049fbb4325-- From dzonatas@gmail.com Wed Mar 30 16:12:41 2011 Return-Path: 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 4E68F28C144 for ; Wed, 30 Mar 2011 16:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 i+Bx2D+pI12d for ; Wed, 30 Mar 2011 16:12:40 -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 1E85F3A6BD7 for ; Wed, 30 Mar 2011 16:12:40 -0700 (PDT) Received: by iye19 with SMTP id 19so2010476iye.31 for ; Wed, 30 Mar 2011 16:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=/KbzXSFhKCEEGK/IBI71kIaZUEzFU+1gve1BVCjTV6s=; b=gUH91ozyLVjDzo47vqad4sdH4KHlXlVVaB6Tg40a7ywyUVF+B5Yb+FGs+MZAdfh2Wz 5SJp8nMFFGm8CYPLPYJSKpDeXeYi7JFKDXzgsF+DHOd0hk+TgFkcCS+CCyRr7lT7bP9Z DJQvKlWKFHPyKwZot84Euwn5ML+WQgO6uZ+Zw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VmHdgdu0G++NM6Oxq2iU98/LpTACTkz80uMNsP7zr1vFAy3J8ls12US00eBsC1WFYU OSF+7G3E8DXDEZ87m3/VMFz/KpZapJsLC0YvKn/LBedEwPxxWAM8z11uUhAAqyaEsmYy PvdcS8tXdUKTtGVlCE+cVGy/BhCY3GbXdNUL0= Received: by 10.42.175.68 with SMTP id az4mr1963783icb.205.1301526859170; Wed, 30 Mar 2011 16:14:19 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id jv9sm222818icb.1.2011.03.30.16.14.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 16:14:18 -0700 (PDT) Message-ID: <4D93B94F.9000203@gmail.com> Date: Wed, 30 Mar 2011 16:14:23 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D93B378.8030302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:12:41 -0000 That would be assume that COLLADA would get rid of all conditioners and refineries and the purpose of such to exist. That doesn't make any sense. Morgaine wrote: > COLLADA is not /only/ an interchange format, despite being defined for > that purpose originally. Many applications now use it as their native > graphics file format, the archetypal case being Google Earth. I > expect such use to become ever more common in the future. > > > Morgaine. > > > > > > ======================= > > On Wed, Mar 30, 2011 at 11:49 PM, Dzonatas Sol > wrote: > > Remember, that COLLADA is only an exchange format, not the format > for which something is being rendered from or to. Please make sure > your semantic usage of such at least complies when you try to > argue with it. > > > Morgaine wrote: > > This is the last vestige of where that term is commonly > encountered, as *Service Level Semantic Interoperability*.� Is > it relevant to us?� Yes, a little.� For example, it would do > us no good to transport Collada meshes from an asset service > to a client that tries to render them as some other graphics > format --- that would create a semantic mishap, because one > party thinks that the items means one thing and another party > applies a different semantic.� So yes, there is a little more > for us to consider here, but it's not a lot.� In most part we > have already stated the solution every time that we have > mentioned MIME types for describing content.� This is mostly a > solved problem. > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From sean@uci.edu Wed Mar 30 16:19:22 2011 Return-Path: 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 6F07D3A69AE for ; Wed, 30 Mar 2011 16:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] 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 wtmsYFYcjtJj for ; Wed, 30 Mar 2011 16:19:20 -0700 (PDT) Received: from smtp1.es.uci.edu (smtp1.es.uci.edu [128.200.80.31]) by core3.amsl.com (Postfix) with ESMTP id D94403A6967 for ; Wed, 30 Mar 2011 16:19:20 -0700 (PDT) Received: from sean-3.nac.uci.edu (sean-3.nac.uci.edu [128.200.62.129]) (authenticated bits=0) by smtp1.es.uci.edu (8.13.8/8.13.8) with ESMTP id p2UNKxaT011072 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 16:21:00 -0700 X-UCInetID: sean Message-ID: <4D93BADB.1010202@uci.edu> Date: Wed, 30 Mar 2011 16:20:59 -0700 From: Sean Hennessee User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.38.b3pre.fc13 Thunderbird/3.1.9 ThunderBrowse/3.3.5 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:19:22 -0000 So, for example, one protocol we would like to define, in the name of VW interoperability, is how a client, (a viewer and it's user in this case), communicates, to a specific grid X authentication server, that it wants to connect to that grid using grid Y authentication server, which could be another grid or facebook, etc. The communication that happens there needs to have some way to determine if that grid Y authentication service is allowed or known, and if it was successful in authenticating you, among other things. So, this is, in a way, service level interop, but like you said, a bit orthogonal. Also, in addition to the communication between the above service and client, there would have to be communication between grid X authentication service and grid Y authentication service. More protocol this group would likely specify, I assume. Peace, Sean On 03/30/2011 03:40 PM, Morgaine wrote: > Very well put, Vaughn. > > Regarding "service level interoperability", it's not really a subset of > VW interoperability at all, but lies orthogonal to it because it is a > property of all multipart systems that implement services. I'll try to > explain. > > Client-server systems for example have at least two distinct parts with > distinct roles, server(s) and client(s). Service-level interoperability > typically consists of designing and specifying the protocols or > interfaces between them in such a way that any part of the system is > interchangeable with another equivalent part that performs the same > role, say from a different manufacturer, and the system as a whole still > continues to work normally. > > This rarely needs to be honored with a fancy title such as "service > level interoperability" in these days of IETF standards and highly > cross-platform web applications. Historically however, applications did > not behave quite so nicely, and vendors often sought to lock customers > in with hidden proprietary interfaces, so there was a need for adding > "service level interoperability" to the tendering documentation in days > gone by, to avoid surprises later on. > > Today, the need for that has almost disappeared, and if your online > service has a documented protocol interface then "service level > interoperability" is virtually assured without doing anything at all, > assuming normal commonsense has prevailed during development (and there > is no deliberate obfuscation of course). There is only one other area > of this topic where a little more needs to be said. > > Protocol messages can normally be validated syntactically to a strong > degree, and whether a message is correct or not is normally known > immediately upon syntactic validation. Unfortunately, that is not > always the end of the story, because protocols can transport complex > data items which are valid syntactically yet invalid semantically. > > This is the last vestige of where that term is commonly encountered, as > *Service Level Semantic Interoperability*. Is it relevant to us? Yes, > a little. For example, it would do us no good to transport Collada > meshes from an asset service to a client that tries to render them as > some other graphics format --- that would create a semantic mishap, > because one party thinks that the items means one thing and another > party applies a different semantic. So yes, there is a little more for > us to consider here, but it's not a lot. In most part we have already > stated the solution every time that we have mentioned MIME types for > describing content. This is mostly a solved problem. > > There may be one or two other areas where we have to specify the > required semantic alongside the simple matter of protocol syntax, but > that's a standard part of defining protocols. There is nothing really > new here. > > Lastly, service level interoperability focuses entirely on single > services and their clients, so it's unrelated to interoperability > between multiple services, such as a set of virtual world services. > This means that, apart from defining type semantics, it doesn't get us > even a step closer towards interop between virtual worlds. > > > Morgaine. > > > > > > > ========================== > > On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > wrote: > > Katherine wrote: > >It seems to me that accomodating "full" interop only would reduce the > >number of possible implementers and use cases for our work > > I am sure that nobody suggested to we restrict ourselves to "full" > interop only. > "Service level interop" is clearly subset of VW interoperability. You > can't have VW interoperability without service level interoperability! > However, If i understand Morgaine right, she is worried that the VWRAP > specs will be *restricted* to service level interop only. > > It has been argued (sorry, I forgot by whom) that proper > specifications of service level interop will give us virtual world > interop for free. I think we need a bit more, but i really have a hard > time envisioning how service level interop can be specified in such a > way that it *prevents* VW interop, at least not if we pay attention to > this aspect, and clearly we do. So in conclusion i do not see much of > a problem. > > Izzy wrote in another tread "This whole argument between service level > interop and 'full' interop eludes me." At first it eluded me to, but > now i think that what is actually expressed in these discussions is > the question of the scope of our effort as well as design approach. > Some prefer to work bottom up, following their primary interests in > getting the low level protocols working, especially since that will > already be good enough for (all?) of their use cases . Some prefer a > more top-down approach, first sketching the high level picture of the > users perception of VW interop, and from there working downwards, > obviously also because that approach optimises the realisation of > *their* use cases. > > I think we need both, and above all, i do feel that the two approaches > are not al all incompatible and both are without any doubt square > within the current charter. > Formally splitting our effort in two working parties along the current > visible fissures and getting each to work on their own interest is a > recipe for disaster. It will only strengthen the animosity that is > already slowing us down tremendously, and will sustain the infighting. > Rather than spitting efforts off, we need to address the causes for > the current disagreement and found common ground. In my view that is > not all all hard. > > I have been reviewing the discussion we had in September and i am > actually amazed at the level of consensus that is expressed in those > email exchanges. Unfortuanately we have been very bad at consolidating > that consensus. As a result we recycle the same problems time and time > again. The archives make very depressing reading from that point of > view. We need to do more documentation for sure. > > I am currently going over the September discussion and looking up the > places were we all agreed on the way forward. Much of that is still > undocumented, and my aim is to get those points written down in the > wiki. > > As i final point i want to make clear how I understand the term > "Service Level Interop". I used the term, and since the glosary entry > is still emtpy, i feel obliged to add at least my personal reading. If > somebody disagrees, please add an improved version. > > Service level interoperability: > A subset of "Virtual World Interoperability" as defined by > the VWRAP > protocol. Service level interoperabity loosely describes specific > interactions between VWRAP endpoints. These inteactions form the glue > that hold a particular virtual world together, but might just as well > be used for communication between different VWRAP compatible virtual > worlds (i.e. crossing trust domains). > > I intend to put this up in the glossary, but first will see how it > flies here :) > > On 3/29/11, Katherine Mancuso > wrote: > > 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 > > > ---------------------------------------------------------------------------------------------- > > _______________________________________________ > > 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap -- Sean Hennessee Central Computing Support Office of Information Technology UC Irvine ... . .- -. / .... . -. -. . ... ... . . From kmancuso@gmail.com Wed Mar 30 16:26:09 2011 Return-Path: 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 BDAD428C0F5 for ; Wed, 30 Mar 2011 16:26:09 -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 dSCGIzdweibH for ; Wed, 30 Mar 2011 16:26:09 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E081F28C0E8 for ; Wed, 30 Mar 2011 16:26:08 -0700 (PDT) Received: by iwn39 with SMTP id 39so2023378iwn.31 for ; Wed, 30 Mar 2011 16:27:48 -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:content-type; bh=dJzHRV90EFyJpFbqgRrwdBTxXiTQ8S5LEcb5P+M7E4M=; b=dfNFlzS5RQRCnIDQ0Ji+yL9V91YWw/ZF7d2Id8DQV7UjGdq2f3rLE3uLUBMPXTzdzV d9LgMIC7IbP+6AEYWAxN23HVbzi8lw4Im9nbRMu1Tm76pEJzyeMfXArKcBjdTC5dhNMW ylRox+/Gil5c49JYVSM+6Z8lByE6dMUnLZeME= 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:content-type; b=Sr7v/ez4rPIl/8j4TB7zl5T82oGZrJt1csmVEVFOQCHwGIsot4vcLdpOauvsox/nh6 chLkdVC2A8eoaVb3Mr2RF+KfJpfEhtNPRYOvIdh2J0rDlvhXDkXNT9z3//1g9e9GL4NC zbSnhu4rUIr8eOLSpt3K2jhRk8NigfdqsKVhc= Received: by 10.231.92.15 with SMTP id p15mr1903260ibm.153.1301527668085; Wed, 30 Mar 2011 16:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.143.131 with HTTP; Wed, 30 Mar 2011 16:27:28 -0700 (PDT) In-Reply-To: References: From: Katherine Mancuso Date: Wed, 30 Mar 2011 16:27:28 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 31 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 23:26:09 -0000 Historically speaking, Sean, you might want to look at the old VWRAP launch draft. In fact, this is a service, not full interop, and doesn't do everything you're describing, but some of the specification work may be useful if you wish to sketch out your example more deeply. 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 ---------------------------------------------------------------------------------------------- From morgaine.dinova@googlemail.com Wed Mar 30 17:15:25 2011 Return-Path: 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 D061428C1B7 for ; Wed, 30 Mar 2011 17:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=-0.205, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 UpZyh5KDlljd for ; Wed, 30 Mar 2011 17:15:23 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id C467F3A69AF for ; Wed, 30 Mar 2011 17:15:22 -0700 (PDT) Received: by qyk7 with SMTP id 7so1257700qyk.10 for ; Wed, 30 Mar 2011 17:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0RrNi6pc5QX5nQ8QjZDvQnM02rMOqav/M+m/Yd2bDY4=; b=aHWJhJESv7rABzmhMnWZtY1J/jjjJxC7RngTueifmERbviWpd3Sgelr4L+oQLuboR8 EBdhhye+ohjpUFA95br8xDJqfPjr6xeN/f9SkU+eGqIYsVF+2Aa27bRzgLYJ4hrXSL2m J8gVPqkdh5OZ0XE1ufgmphGJMdJV6nLn6Xzc4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=N+oyONDTaies0AJxzDlg8lFX27EOAdqGf8cnhd8H8r1MxLB5vGY3jrpPy+GAPmfDXk Z5LnUiMOnmTsugPVQYUDX70UFWfVhguwku/rbdeilTwnVfJ1TnZu83sbxZ939JDaUVaV 7XycwhznQHkGLAoKwUjFr7QsggL/J3B1IORFM= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr1674739qck.109.1301530621649; Wed, 30 Mar 2011 17:17:01 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 17:17:01 -0700 (PDT) In-Reply-To: <4D93BADB.1010202@uci.edu> References: <4D93BADB.1010202@uci.edu> Date: Thu, 31 Mar 2011 01:17:01 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d3565e2342049fbc366e Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 00:15:25 -0000 --00235429d3565e2342049fbc366e Content-Type: text/plain; charset=ISO-8859-1 That's a good requirement, Sean. However, you're suggesting a rather inflexible way of achieving it, because it would rely on one world giving you access to another world. This doesn't scale at all when you consider thousands, let alone millions, of destination worlds. Also, it would result in balkanization of the metaverse, as restrictive world operators seek to prevent you from travelling to worlds they don't like. We'd end up with prison enclaves in which the only way for inmates to "escape" to visit friends in non-permitted worlds would be to log out from this prison and log in to a different one, which defeats most of the benefits of VW interop. It's a poor approach. Fortunately there is a much better way to achieve this, and David hinted at it when he wrote about the near impossibility of one world forcing local policy onto services run by somebody else. If your assets are not held by a world operator but in an independent external asset service (which could even be on your local system), then you don't need to ask the current world for "permission" to teleport to some other world, since you (or your external asset service) can supply all of the resources needed by the destination world directly. No more prison planet. The Web doesn't usually provide a good analogy with virtual worlds because its architecture is substantially different in several areas. However, in respect of teleports the analogy is a direct one. One world should not limit your ability to teleport to another world any more than one website should have a say on which website you visit next. In summary, the inter-world teleport requirement that you describe is a good one, but it should not be implemented as a cooperative agreement between worlds because that has very negative repercussions for residents, turning them into hapless inmates and splitting communities apart. Instead, VWRAP provides the excellent concept of independent external shared asset services which can serve content to multiple worlds. Using them we can design a teleport protocol that empowers users and helps the open metaverse bloom, instead of enslaving them and balkanizing worlds into non-communicating factions. Morgaine. ====================== On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee wrote: > So, for example, one protocol we would like to define, in the name of VW > interoperability, is how a client, (a viewer and it's user in this case), > communicates, to a specific grid X authentication server, that it wants to > connect to that grid using grid Y authentication server, which could be > another grid or facebook, etc. The communication that happens there needs to > have some way to determine if that grid Y authentication service is allowed > or known, and if it was successful in authenticating you, among other > things. So, this is, in a way, service level interop, but like you said, a > bit orthogonal. Also, in addition to the communication between the above > service and client, there would have to be communication between grid X > authentication service and grid Y authentication service. More protocol this > group would likely specify, I assume. > > Peace, > Sean > > > On 03/30/2011 03:40 PM, Morgaine wrote: > >> Very well put, Vaughn. >> >> Regarding "service level interoperability", it's not really a subset of >> VW interoperability at all, but lies orthogonal to it because it is a >> property of all multipart systems that implement services. I'll try to >> explain. >> >> Client-server systems for example have at least two distinct parts with >> distinct roles, server(s) and client(s). Service-level interoperability >> typically consists of designing and specifying the protocols or >> interfaces between them in such a way that any part of the system is >> interchangeable with another equivalent part that performs the same >> role, say from a different manufacturer, and the system as a whole still >> continues to work normally. >> >> This rarely needs to be honored with a fancy title such as "service >> level interoperability" in these days of IETF standards and highly >> cross-platform web applications. Historically however, applications did >> not behave quite so nicely, and vendors often sought to lock customers >> in with hidden proprietary interfaces, so there was a need for adding >> "service level interoperability" to the tendering documentation in days >> gone by, to avoid surprises later on. >> >> Today, the need for that has almost disappeared, and if your online >> service has a documented protocol interface then "service level >> interoperability" is virtually assured without doing anything at all, >> assuming normal commonsense has prevailed during development (and there >> is no deliberate obfuscation of course). There is only one other area >> of this topic where a little more needs to be said. >> >> Protocol messages can normally be validated syntactically to a strong >> degree, and whether a message is correct or not is normally known >> immediately upon syntactic validation. Unfortunately, that is not >> always the end of the story, because protocols can transport complex >> data items which are valid syntactically yet invalid semantically. >> >> This is the last vestige of where that term is commonly encountered, as >> *Service Level Semantic Interoperability*. Is it relevant to us? Yes, >> a little. For example, it would do us no good to transport Collada >> meshes from an asset service to a client that tries to render them as >> some other graphics format --- that would create a semantic mishap, >> because one party thinks that the items means one thing and another >> party applies a different semantic. So yes, there is a little more for >> us to consider here, but it's not a lot. In most part we have already >> stated the solution every time that we have mentioned MIME types for >> describing content. This is mostly a solved problem. >> >> There may be one or two other areas where we have to specify the >> required semantic alongside the simple matter of protocol syntax, but >> that's a standard part of defining protocols. There is nothing really >> new here. >> >> Lastly, service level interoperability focuses entirely on single >> services and their clients, so it's unrelated to interoperability >> between multiple services, such as a set of virtual world services. >> This means that, apart from defining type semantics, it doesn't get us >> even a step closer towards interop between virtual worlds. >> >> >> Morgaine. >> >> >> >> >> >> >> ========================== >> >> On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > > wrote: >> >> Katherine wrote: >> >It seems to me that accomodating "full" interop only would reduce the >> >number of possible implementers and use cases for our work >> >> I am sure that nobody suggested to we restrict ourselves to "full" >> interop only. >> "Service level interop" is clearly subset of VW interoperability. You >> can't have VW interoperability without service level interoperability! >> However, If i understand Morgaine right, she is worried that the VWRAP >> specs will be *restricted* to service level interop only. >> >> It has been argued (sorry, I forgot by whom) that proper >> specifications of service level interop will give us virtual world >> interop for free. I think we need a bit more, but i really have a hard >> time envisioning how service level interop can be specified in such a >> way that it *prevents* VW interop, at least not if we pay attention to >> this aspect, and clearly we do. So in conclusion i do not see much of >> a problem. >> >> Izzy wrote in another tread "This whole argument between service level >> interop and 'full' interop eludes me." At first it eluded me to, but >> now i think that what is actually expressed in these discussions is >> the question of the scope of our effort as well as design approach. >> Some prefer to work bottom up, following their primary interests in >> getting the low level protocols working, especially since that will >> already be good enough for (all?) of their use cases . Some prefer a >> more top-down approach, first sketching the high level picture of the >> users perception of VW interop, and from there working downwards, >> obviously also because that approach optimises the realisation of >> *their* use cases. >> >> I think we need both, and above all, i do feel that the two approaches >> are not al all incompatible and both are without any doubt square >> within the current charter. >> Formally splitting our effort in two working parties along the current >> visible fissures and getting each to work on their own interest is a >> recipe for disaster. It will only strengthen the animosity that is >> already slowing us down tremendously, and will sustain the infighting. >> Rather than spitting efforts off, we need to address the causes for >> the current disagreement and found common ground. In my view that is >> not all all hard. >> >> I have been reviewing the discussion we had in September and i am >> actually amazed at the level of consensus that is expressed in those >> email exchanges. Unfortuanately we have been very bad at consolidating >> that consensus. As a result we recycle the same problems time and time >> again. The archives make very depressing reading from that point of >> view. We need to do more documentation for sure. >> >> I am currently going over the September discussion and looking up the >> places were we all agreed on the way forward. Much of that is still >> undocumented, and my aim is to get those points written down in the >> wiki. >> >> As i final point i want to make clear how I understand the term >> "Service Level Interop". I used the term, and since the glosary entry >> is still emtpy, i feel obliged to add at least my personal reading. If >> somebody disagrees, please add an improved version. >> >> Service level interoperability: >> A subset of "Virtual World Interoperability" as defined by >> the VWRAP >> protocol. Service level interoperabity loosely describes specific >> interactions between VWRAP endpoints. These inteactions form the glue >> that hold a particular virtual world together, but might just as well >> be used for communication between different VWRAP compatible virtual >> worlds (i.e. crossing trust domains). >> >> I intend to put this up in the glossary, but first will see how it >> flies here :) >> >> On 3/29/11, Katherine Mancuso > > wrote: >> > 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 >> > >> >> ---------------------------------------------------------------------------------------------- >> > _______________________________________________ >> > 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 mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > -- > > Sean Hennessee > Central Computing Support > Office of Information Technology > UC Irvine > > > ... . .- -. / .... . -. -. . ... ... . . > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d3565e2342049fbc366e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's a good requirement, Sean.

However, you're suggesting = a rather inflexible way of achieving it, because it would rely on one world= giving you access to another world.=A0 This doesn't scale at all when = you consider thousands, let alone millions, of destination worlds.

Also, it would result in balkanization of the metaverse, as restrictive= world operators seek to prevent you from travelling to worlds they don'= ;t like.=A0 We'd end up with prison enclaves in which the only way for = inmates to "escape" to visit friends in non-permitted worlds woul= d be to log out from this prison and log in to a different one, which defea= ts most of the benefits of VW interop.=A0 It's a poor approach.

Fortunately there is a much better way to achieve this, and David hinte= d at it when he wrote about the near impossibility of one world forcing loc= al policy onto services run by somebody else.=A0 If your assets are not hel= d by a world operator but in an independent external asset service (which c= ould even be on your local system), then you don't need to ask the curr= ent world for "permission" to teleport to some other world, since= you (or your external asset service) can supply all of the resources neede= d by the destination world directly.=A0 No more prison planet.

The Web doesn't usually provide a good analogy with virtual worlds = because its architecture is substantially different in several areas.=A0 Ho= wever, in respect of teleports the analogy is a direct one.=A0 One world sh= ould not limit your ability to teleport to another world any more than one = website should have a say on which website you visit next.

In summary, the inter-world teleport requirement that you describe is a= good one, but it should not be implemented as a cooperative agreement betw= een worlds because that has very negative repercussions for residents, turn= ing them into hapless inmates and splitting communities apart.

Instead, VWRAP provides the excellent concept of independent external s= hared asset services which can serve content to multiple worlds.=A0 Using t= hem we can design a teleport protocol that empowers users and helps the ope= n metaverse bloom, instead of enslaving them and balkanizing worlds into no= n-communicating factions.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu,= Mar 31, 2011 at 12:20 AM, Sean Hennessee <sean@uci.edu> wrote:
So, for example, = one protocol we would like to define, in the name of VW interoperability, i= s how a client, (a viewer and it's user in this case), communicates, to= a specific grid X authentication server, that it wants to connect to that = grid using grid Y authentication server, which could be another grid or fac= ebook, etc. The communication that happens there needs to have some way to = determine if that grid Y authentication service is allowed or known, and if= it was successful in authenticating you, among other things. So, this is, = in a way, service level interop, but like you said, a bit orthogonal. Also,= in addition to the communication between the above service and client, the= re would have to be communication between grid X authentication service and= grid Y authentication service. More protocol this group would likely speci= fy, I assume.

Peace,
Sean


On 03/30/2011 03:40 PM, Morgaine wrote:
=
Very well put, Vaughn.

Regarding "service level interoperability", it's not really a= subset of
VW interoperability at all, but lies orthogonal to it because it is a
property of all multipart systems that implement services. =A0I'll try = to
explain.

Client-server systems for example have at least two distinct parts with
distinct roles, server(s) and client(s). =A0Service-level interoperability<= br> typically consists of designing and specifying the protocols or
interfaces between them in such a way that any part of the system is
interchangeable with another equivalent part that performs the same
role, say from a different manufacturer, and the system as a whole still continues to work normally.

This rarely needs to be honored with a fancy title such as "service level interoperability" in these days of IETF standards and highly
cross-platform web applications. =A0Historically however, applications did<= br> not behave quite so nicely, and vendors often sought to lock customers
in with hidden proprietary interfaces, so there was a need for adding
"service level interoperability" to the tendering documentation i= n days
gone by, to avoid surprises later on.

Today, the need for that has almost disappeared, and if your online
service has a documented protocol interface then "service level
interoperability" is virtually assured without doing anything at all,<= br> assuming normal commonsense has prevailed during development (and there
is no deliberate obfuscation of course). =A0There is only one other area of this topic where a little more needs to be said.

Protocol messages can normally be validated syntactically to a strong
degree, and whether a message is correct or not is normally known
immediately upon syntactic validation. =A0Unfortunately, that is not
always the end of the story, because protocols can transport complex
data items which are valid syntactically yet invalid semantically.

This is the last vestige of where that term is commonly encountered, as
*Service Level Semantic Interoperability*. =A0Is it relevant to us? =A0Yes,=
a little. =A0For example, it would do us no good to transport Collada
meshes from an asset service to a client that tries to render them as
some other graphics format --- that would create a semantic mishap,
because one party thinks that the items means one thing and another
party applies a different semantic. =A0So yes, there is a little more for us to consider here, but it's not a lot. =A0In most part we have alread= y
stated the solution every time that we have mentioned MIME types for
describing content. =A0This is mostly a solved problem.

There may be one or two other areas where we have to specify the
required semantic alongside the simple matter of protocol syntax, but
that's a standard part of defining protocols. =A0There is nothing reall= y
new here.

Lastly, service level interoperability focuses entirely on single
services and their clients, so it's unrelated to interoperability
between multiple services, such as a set of virtual world services.
This means that, apart from defining type semantics, it doesn't get us<= br> even a step closer towards interop between virtual worlds.


Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca <vaughn.deluca@gmail.com
=
<mailto:vau= ghn.deluca@gmail.com>> wrote:

=A0 =A0Katherine wrote:
=A0 =A0 >It seems to me that accomodating "full" interop only= would reduce the
=A0 =A0 >number of possible implementers and use cases for our work

=A0 =A0I am sure that nobody =A0suggested to we restrict ourselves to &quo= t;full"
=A0 =A0interop only.
=A0 =A0"Service level interop" is clearly subset of VW interoper= ability. You
=A0 =A0can't have VW interoperability without service level interopera= bility!
=A0 =A0However, If i understand Morgaine right, she is worried that the VW= RAP
=A0 =A0specs will be *restricted* to service level interop only.

=A0 =A0It has been argued (sorry, I forgot by whom) that proper
=A0 =A0specifications of service level interop will give us virtual world<= br> =A0 =A0interop for free. I think we need a bit more, but i really have a h= ard
=A0 =A0time envisioning how service level interop can be specified in such= a
=A0 =A0way that it *prevents* VW interop, at least not if we pay attention= to
=A0 =A0this aspect, and clearly we do. So in conclusion i do not see much = of
=A0 =A0a problem.

=A0 =A0Izzy wrote in another tread "This whole argument between servi= ce level
=A0 =A0interop and 'full' interop eludes me." At first it elu= ded me to, but
=A0 =A0now i think that what is actually expressed in these discussions is=
=A0 =A0the question of the scope of our effort as well as design approach.=
=A0 =A0Some prefer to work bottom up, following their primary interests in=
=A0 =A0getting the low level protocols working, especially since that will=
=A0 =A0already be good enough for (all?) of their use cases . Some prefer = a
=A0 =A0more top-down approach, first sketching the high level picture of t= he
=A0 =A0users perception of VW interop, =A0and from there working downwards= ,
=A0 =A0obviously also because that approach optimises the realisation of =A0 =A0*their* use cases.

=A0 =A0I think we need both, and above all, i do feel that the two approac= hes
=A0 =A0are not al all incompatible and both are without any doubt square =A0 =A0within the current charter.
=A0 =A0Formally splitting our effort in two working parties along the curr= ent
=A0 =A0visible fissures and getting each to work on their own interest is = a
=A0 =A0recipe for disaster. It will only strengthen the animosity that is<= br> =A0 =A0already slowing us down tremendously, and will sustain the infighti= ng.
=A0 =A0Rather than spitting efforts off, we need to address the causes for=
=A0 =A0the current disagreement and found common ground. =A0In my view tha= t is
=A0 =A0not all all hard.

=A0 =A0I have been reviewing the discussion we had in September and i am =A0 =A0actually amazed at the level of consensus that is expressed in thos= e
=A0 =A0email exchanges. Unfortuanately we have been very bad at consolidat= ing
=A0 =A0that consensus. As a result we recycle the same problems time and t= ime
=A0 =A0again. The archives make very depressing reading from that point of=
=A0 =A0view. We need to do more documentation for sure.

=A0 =A0I am currently going over the September discussion and looking up t= he
=A0 =A0places were we all agreed on the way forward. =A0Much of that is st= ill
=A0 =A0undocumented, and my aim is to get those points written down in the=
=A0 =A0wiki.

=A0 =A0As i final point i want to make clear how I understand the term
=A0 =A0"Service Level Interop". I used the term, and since the g= losary entry
=A0 =A0is still emtpy, i feel obliged to add at least my personal reading.= If
=A0 =A0somebody disagrees, please add an improved version.

=A0 =A0Service level interoperability:
=A0 =A0 =A0 =A0 =A0 =A0A subset of "Virtual World Interoperability&qu= ot; as defined by
=A0 =A0the VWRAP
=A0 =A0protocol. Service level interoperabity loosely describes specific =A0 =A0interactions between VWRAP endpoints. These inteactions form the gl= ue
=A0 =A0that hold a particular virtual world together, but might just as we= ll
=A0 =A0be used for communication between different VWRAP compatible virtua= l
=A0 =A0worlds (i.e. crossing trust domains).

=A0 =A0I intend to put this up in the glossary, but first will see how it<= br> =A0 =A0flies here =A0:)

=A0 =A0On 3/29/11, Katherine Mancuso <kmancuso@gmail.com
=A0 =A0<mailto:= kmancuso@gmail.com>> wrote:
=A0 =A0 > Hi everyone,
=A0 =A0 >
=A0 =A0 > I want to speak up for agreeing with Meadhbh & Mike about= keeping a
=A0 =A0 > role for service level interop in this group. =A0We've ma= de good
=A0 =A0 > progress towards this goal and can continue to work on it. =A0 =A0 >
=A0 =A0 > Here is an alternative proposal to any which has been brought= up so
=A0 =A0 > far. =A0I'm aware this may not be fully correct in its te= chnical
=A0 =A0 > details, as I am not a software architect:
=A0 =A0 >
=A0 =A0 > Could the partisans of "full" VW interop consider w= orking together on
=A0 =A0 > a draft specification that is something like the intro or Dav= id's
=A0 =A0 > piece in scope that lays out which specific capacities would = need to
=A0 =A0 > be supported at a minimum to allow for "full" inter= op, perhaps
=A0 =A0getting
=A0 =A0 > input from implementers such as the Hypergrid folks and the f= olks who
=A0 =A0 > coordinated the teleport test at Linden? =A0Citing existing s= ervice
=A0 =A0 > specifications (either ones developed within this WG, or outs= ide
=A0 =A0 > specifications like XML, Collada, etc) is preferred, and for<= br> =A0 =A0 > capabilities for which there are not existing service specifi= cations
=A0 =A0 > or the existing specifications don't work well enough, ad= dress
=A0 =A0that to
=A0 =A0 > lay out a clear roadmap of what must be developed.
=A0 =A0 >
=A0 =A0 > My vision here is that folks who are doing service-level work= could
=A0 =A0 > continue developing and implementing their individual service= s, and
=A0 =A0 > the folks who wish to do "full" interop could defin= e a menu of
=A0 =A0 > services which must be implemented for "full" inter= op. =A0Implementers
=A0 =A0 > could then choose their path based on their use cases: implem= ent the
=A0 =A0 > "full" interop specification including all the spec= ifications called
=A0 =A0 > for, or implement individual services. =A0I believe that both= of these
=A0 =A0 > concepts can exist under our existing charter or with limited=
=A0 =A0 > amendment to the charter and intro, which is much easier for = everyone
=A0 =A0 > to agree to than entirely rewriting both, and does not requir= e
=A0 =A0 > trashing years of work.
=A0 =A0 >
=A0 =A0 > It seems to me that accomodating "full" interop onl= y would reduce the
=A0 =A0 > number of possible implementers and use cases for our work =A0 =A0 > dramatically, not to mention cut out a productive body of fol= ks in
=A0 =A0 > this group who have been contributing an awful lot of documen= ts and
=A0 =A0 > implementing.
=A0 =A0 >
=A0 =A0 > For example, to illustrate my point:
=A0 =A0 >
=A0 =A0 > From my work as a SL developer focusing in education, I know<= br> =A0 =A0there's a
=A0 =A0 > substantial use case in K-12 education in the US for walled g= ardens,
=A0 =A0 > because schools have big legal liability problems with lettin= g minors
=A0 =A0 > wander unwalled virtual worlds (most school libraries in the = US have
=A0 =A0 > internet filters for the same reasons) and have fairly intens= e
=A0 =A0 > supervision requirements which require substantial moderation= &
=A0 =A0 > surveillance tools. =A0However, a shared asset server that co= ntains a
=A0 =A0 > core of "safe" content might be of interest to thes= e folks, since
=A0 =A0 > educators don't necessarily need to reinvent the wheel fo= r their
=A0 =A0 > classrooms every year. =A0This is a really good case for serv= ice level
=A0 =A0 > interop ... implement the asset server specification only, no= t the
=A0 =A0 > "full" one that allows you to teleport to other wor= lds.
=A0 =A0 >
=A0 =A0 > On the other hand, universities have far greater interest in = letting
=A0 =A0 > students and professors teleport among university spaces (whi= ch
=A0 =A0 > happens metaphorically in the real world all the time), and f= ewer
=A0 =A0 > liability issues. =A0Sharing an asset server might be of inte= rest to
=A0 =A0 > them, but so too might "full" interop. =A0They'= d want to implement the
=A0 =A0 > "full" interop specification.
=A0 =A0 >
=A0 =A0 > (Paging Fleep Tuque, are you here to make this case better fo= r me?)
=A0 =A0 >
=A0 =A0 > TL;DR - Proposal is to amend the charter & intro so that = they allow
=A0 =A0 > the "full" interop people to work in one community = on their ideas and
=A0 =A0 > the service level interop people to work in parallel on their= ideas,
=A0 =A0 > rather than assuming that one model has to exclusively domina= te the
=A0 =A0 > group.
=A0 =A0 >
=A0 =A0 > I will be unavailable to post anything else much lengthy thro= ugh
=A0 =A03 April,
=A0 =A0 > FYI.
=A0 =A0 >
=A0 =A0 > Katherine
=A0 =A0 >
=A0 =A0 > --
=A0 =A0 >
=A0 =A0-------------------------------------------------------------------= --------------------------
=A0 =A0 > Katherine Mancuso
=A0 =A0 >
=A0 =A0 > ISIS Inc, Community Manager (http://www.isis-inc.org)
=A0 =A0 > Sex::Tech Conference, Social Media Chair (http://www.sextech.org)
=A0 =A0 > The Vesuvius Group: metaverse community builders
=A0 =A0 > (http://www.thevesuviusgroup.com)
=A0 =A0 > GimpGirl Community Liaison (http://www.gimpgirl.com)
=A0 =A0 >
=A0 =A0 > http://twitter.com/musingvirtual
=A0 =A0 > ht= tp://facebook.com/kmancuso
=A0 =A0 > http://www.linkedin.com/in/kathymancuso
=A0 =A0 > Second Life: Muse Carmona
=A0 =A0 >
=A0 =A0-------------------------------------------------------------------= ---------------------------
=A0 =A0 > _______________________________________________
=A0 =A0 > vwrap mailing list
=A0 =A0 > vwrap@iet= f.org <mailto:vw= rap@ietf.org>

=A0 =A0 > https://www.ietf.org/mailman/listinfo/vwrap
=A0 =A0 >
=A0 =A0_______________________________________________
=A0 =A0vwrap mailing list
=A0 =A0vwrap@ietf.org<= /a> <mailto:vwrap@ie= tf.org>

=A0 =A0https://www.ietf.org/mailman/listinfo/vwrap




_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--

Sean Hennessee
Central Computing Support
Office of Information Technology
UC Irvine


... . .- -. / =A0.... . -. -. . ... ... . .

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d3565e2342049fbc366e-- From dzonatas@gmail.com Wed Mar 30 19:32:41 2011 Return-Path: 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 477803A6BF4 for ; Wed, 30 Mar 2011 19:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 XyxWvt-ezoFj for ; Wed, 30 Mar 2011 19:32:40 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 1E6F23A6BF1 for ; Wed, 30 Mar 2011 19:32:40 -0700 (PDT) Received: by iwn39 with SMTP id 39so2166736iwn.31 for ; Wed, 30 Mar 2011 19:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=v2mxqHJHAK69IxPnm1yhmbQ6wg93gahvUqhpYBtbqgA=; b=nsat6hx3fQER23dEy7C5zCR1U00y7WmzY//ENi4Dl10hLg5GwoYsXT2VI/GKoljMBs qi1bZ3UqVpMpual21YmmGSH4xdyFN0XJZU9ANoJPqJzlNQJhvwoOiu6EFCBkxrX/nVlH TucGvh3Sc1HLdI4TTR+JAvVnTh5B2zJh8oCrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=pRC2S7ACahLw7Wdklj4wML5GXTqR8rO3M6mmAStiskUhjtq9I1rrb68ItlUDP1kz8y zZshXg2ZFWjN/igox+gtR6WXURkketqzajWHSUFgenhrzpx+55CYcoYVy03CK09mkm4k yrNt/551ESI3Y3Vxhl0z8vL/I4m28qxhjZNVs= Received: by 10.231.187.229 with SMTP id cx37mr2068822ibb.99.1301538858455; Wed, 30 Mar 2011 19:34:18 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id gy41sm409137ibb.39.2011.03.30.19.34.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 19:34:17 -0700 (PDT) Message-ID: <4D93E82C.7060503@gmail.com> Date: Wed, 30 Mar 2011 19:34:20 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 02:32:41 -0000 If we say the conditioner basically authenticates or re-signs an asset from grid X to grid Y, and the refinery would make sure the physics of the object described by the asset is translated from the topology of grid X to the topology of grid Y, then this is basically what COLLADA expects in exchange. This exchange is this different from the usual import/export process. It doesn't have to be this exact process, as this is only an example to us be more familiar. It seems a complete waste to not realize that LL has implemented the import process and physics refinery into their browser, and this very feature, though not fully automated as such, could be used to help move assets in-between grids/v-worlds. Since the import is from local basis, the authentication is not implemented. What's to stop to basically export to DAE format on the local storage, from one world, and continue to import that DAE into another grid. Note that the refineries may be proprietary. They may produce non-COLLADA formats (from DAE files) that are for optimal render/display capability of the software "client" (i.e. that the end-user has to view graphics). As with Google Earth and Sony HOME, they already have their assets conditioned and refined for those virtual worlds such that they can optimally display them. The key note is not the optimal display, as it is about being able to exchange and use in other virtual worlds. The DAE format does have extensive abilities, yet the goal of COLLADA is still to define the basic material, scripts, model, etc in the most portable format. The DAE may contain hybrid or specific formats that is stored in the extensions, so that custom objects are retained/transferred. If virtual worlds start to not agree upon how they store objects, I see COLLADA as the default format for digital asset exchange. https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F (Yes, we can put all inventory items in DAE format through the user-data and asset extensions, despite the format mainly being for 3D... just sayin') -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From morgaine.dinova@googlemail.com Wed Mar 30 20:41:00 2011 Return-Path: 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 9EF333A6965 for ; Wed, 30 Mar 2011 20:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.872 X-Spam-Level: X-Spam-Status: No, score=-2.872 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 IhcAY2iwBJ4M for ; Wed, 30 Mar 2011 20:40:59 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id F18373A68DC for ; Wed, 30 Mar 2011 20:40:58 -0700 (PDT) Received: by qwg5 with SMTP id 5so1427312qwg.31 for ; Wed, 30 Mar 2011 20:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YQwzwmxtt0YtAWuSnc5zT3imzmZb2bGicUb4jEx5CtI=; b=OFYo4GciGHyM9Yb4Poy8CXgOH8GWhp+f3Mx7w6w07MHzbtZ4ONieRkS51fEtrsLimb 3uwDvK+/YnFtH0ardowrmyehKrJ32mbPgW0yCiishE8bFqUBpPAbBlUXxKdtZptyfJbm Orw9jpYoDnSkFyZJOaFdUk9Mf/Oa0xnW+/cGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=eqbHIx+vWni0OPpL8H335xQEfvo3IM4L/tlJtXvEzGUvoW0vwoAMZwUOmVQhQTOJDM TK7YRn3r7UG7QAq03hqi6sRQm1ZoPpRYpjCPudd+E4inlD+XWevz0ESztE2Aq8WjR9rt X1IlJgYTGNS+9kjkZlY9joMUc2Q9uqsOCppdg= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr1788944qck.109.1301542956695; Wed, 30 Mar 2011 20:42:36 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 20:42:36 -0700 (PDT) In-Reply-To: <4D93E82C.7060503@gmail.com> References: <4D93E82C.7060503@gmail.com> Date: Thu, 31 Mar 2011 04:42:36 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d35697ff87049fbf1563 Subject: Re: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 03:41:00 -0000 --00235429d35697ff87049fbf1563 Content-Type: text/plain; charset=ISO-8859-1 We've maintained throughout that our protocols would be extensible with regard to data formats, allowing worlds and user expectations to evolve without requiring protocol redefinition. In the area of meshes, it is very much to be expected that COLLADA will figure strongly among the graphic formats used (particularly since it was chosen for the iED initiative), but it's not of any special interest to the VWRAP protocols other than as a potential content type. All we have to do is to make sure that we label each transfer with its appropriate type, and possibly also include other metadata that may be needed. We're certainly not standardizing what graphics are used in virtual worlds, beyond assigning types where they might not yet exist. Hardwiring them would be a recipe not for extensibility but for stagnation. Other bodies may be standardizing which graphics formats are used, whereas we're trying to define useful deployment architectures and standardizing the protocols through which they are accessed. Morgaine. =================== On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol wrote: > If we say the conditioner basically authenticates or re-signs an asset from > grid X to grid Y, and the refinery would make sure the physics of the object > described by the asset is translated from the topology of grid X to the > topology of grid Y, then this is basically what COLLADA expects in exchange. > This exchange is this different from the usual import/export process. It > doesn't have to be this exact process, as this is only an example to us be > more familiar. > > It seems a complete waste to not realize that LL has implemented the import > process and physics refinery into their browser, and this very feature, > though not fully automated as such, could be used to help move assets > in-between grids/v-worlds. Since the import is from local basis, the > authentication is not implemented. What's to stop to basically export to DAE > format on the local storage, from one world, and continue to import that DAE > into another grid. > > Note that the refineries may be proprietary. They may produce non-COLLADA > formats (from DAE files) that are for optimal render/display capability of > the software "client" (i.e. that the end-user has to view graphics). > > As with Google Earth and Sony HOME, they already have their assets > conditioned and refined for those virtual worlds such that they can > optimally display them. The key note is not the optimal display, as it is > about being able to exchange and use in other virtual worlds. > > The DAE format does have extensive abilities, yet the goal of COLLADA is > still to define the basic material, scripts, model, etc in the most portable > format. The DAE may contain hybrid or specific formats that is stored in the > extensions, so that custom objects are retained/transferred. > > If virtual worlds start to not agree upon how they store objects, I see > COLLADA as the default format for digital asset exchange. > > > https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F > > (Yes, we can put all inventory items in DAE format through the user-data > and asset extensions, despite the format mainly being for 3D... just sayin') > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --00235429d35697ff87049fbf1563 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've maintained throughout that our protocols would be extensible with= regard to data formats, allowing worlds and user expectations to evolve wi= thout requiring protocol redefinition.

In the area of meshes, it is = very much to be expected that COLLADA will figure strongly among the graphi= c formats used (particularly since it was chosen for the iED initiative), b= ut it's not of any special interest to the VWRAP protocols other than a= s a potential content type.=A0 All we have to do is to make sure that we la= bel each transfer with its appropriate type, and possibly also include othe= r metadata that may be needed.

We're certainly not standardizing what graphics are used in virtual= worlds, beyond assigning types where they might not yet exist.=A0 Hardwiri= ng them would be a recipe not for extensibility but for stagnation.=A0 Othe= r bodies may be standardizing which graphics formats are used, whereas we&#= 39;re trying to define useful deployment architectures and standardizing th= e protocols through which they are accessed.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 201= 1 at 3:34 AM, Dzonatas Sol <dzonatas@gmail.com> wrote:
If we say the con= ditioner basically authenticates or re-signs an asset from grid X to grid Y= , and the refinery would make sure the physics of the object described by t= he asset is translated from the topology of grid X to the topology of grid = Y, then this is basically what COLLADA expects in exchange. This exchange i= s this different from the usual import/export process. It doesn't have = to be this exact process, as this is only an example to us be more familiar= .

It seems a complete waste to not realize that LL has implemented the import= process and physics refinery into their browser, and this very feature, th= ough not fully automated as such, could be used to help move assets in-betw= een grids/v-worlds. Since the import is from local basis, the authenticatio= n is not implemented. What's to stop to basically export to DAE format = on the local storage, from one world, and continue to import that DAE into = another grid.

Note that the refineries may be proprietary. They may produce non-COLLADA f= ormats (from DAE files) that are for optimal render/display capability of t= he software "client" (i.e. that the end-user has to view graphics= ).

As with Google Earth and Sony HOME, they already have their assets conditio= ned and refined for those virtual worlds such that they can optimally displ= ay them. The key note is not the optimal display, as it is about being able= to exchange and use in other virtual worlds.

The DAE format does have extensive abilities, yet the goal of COLLADA is st= ill to define the basic material, scripts, model, etc in the most portable = format. The DAE may contain hybrid or specific formats that is stored in th= e extensions, so that custom objects are retained/transferred.

If virtual worlds start to not agree upon how they store objects, I see COL= LADA as the default format for digital asset exchange.

https://collada.org/me= diawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F=

(Yes, we can put all inventory items in DAE format through the user-data an= d asset extensions, despite the format mainly being for 3D... just sayin= 9;)

--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--00235429d35697ff87049fbf1563-- From sean@uci.edu Wed Mar 30 21:43:07 2011 Return-Path: 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 2B0D03A6999 for ; Wed, 30 Mar 2011 21:43:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6] 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 1T4OuvnnjNd4 for ; Wed, 30 Mar 2011 21:43:04 -0700 (PDT) Received: from xsmtp1.es.uci.edu (xsmtp1.es.uci.edu [128.200.80.131]) by core3.amsl.com (Postfix) with ESMTP id E370F3A6996 for ; Wed, 30 Mar 2011 21:43:02 -0700 (PDT) Received: from sean-hennessees-imac.local (ip68-5-188-64.oc.oc.cox.net [68.5.188.64]) (authenticated bits=0) by xsmtp1.es.uci.edu (8.13.8/8.13.8) with ESMTP id p2V4icQx001727 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 30 Mar 2011 21:44:40 -0700 X-UCInetID: sean Message-ID: <4D9406B6.20308@uci.edu> Date: Wed, 30 Mar 2011 21:44:38 -0700 From: Sean Hennessee User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: vwrap@ietf.org References: <4D93BADB.1010202@uci.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 04:43:07 -0000 On 3/30/11 5:17 PM, Morgaine wrote: > That's a good requirement, Sean. > > However, you're suggesting a rather inflexible way of achieving it, > because it would rely on one world giving you access to another > world. This doesn't scale at all when you consider thousands, let > alone millions, of destination worlds. I think you misunderstand my example. The 'Grid Y' authentication service that was used in the example is the one that the end user _chose_ to use, not forced by a restriction of it's current grid or poor protocol definition. They would have the option to choose any authentication service they want, like OpenID, Facebook, Google, their home grid's authentication service, or their own home grown authentication service they are running for themselves. They could even have the option to connect to a grid that does not require authentication. Some grids will allow only a few authentication methods/services; some grids won't allow any except their own, and some grids won't care. An additional thought would be having the ability to have a list of authentication services that you, the end user, are willing to use, (via some preferences in the client viewer application), leaving the negotiation process to determine which one to use, (or none at all), for that particular destination grid. Other options that could be negotiated during the authentication phase could be asset services used, IM services used, voice services used, etc. These would not necessarily be options set by the end users current grid, but by the end user herself, (through the viewer client program likely). As above, some grids may accept any asset service, or only a limited list of trusted asset services, or none at all except it's own. This should not be limited to only one of each service, either. I commonly login to Yahoo and AIM at the same time to connect with friends that are only connect to one service or the other. There really has to be some kind of negotiations, otherwise you could be doing the equivalent of telling Google that you planned to login to their webmail service using AOL's Instant Messenger authentication services, whether they allow it or not. Peace, Sean > Also, it would result in balkanization of the metaverse, as > restrictive world operators seek to prevent you from travelling to > worlds they don't like. We'd end up with prison enclaves in which the > only way for inmates to "escape" to visit friends in non-permitted > worlds would be to log out from this prison and log in to a different > one, which defeats most of the benefits of VW interop. It's a poor > approach. > > Fortunately there is a much better way to achieve this, and David > hinted at it when he wrote about the near impossibility of one world > forcing local policy onto services run by somebody else. If your > assets are not held by a world operator but in an independent external > asset service (which could even be on your local system), then you > don't need to ask the current world for "permission" to teleport to > some other world, since you (or your external asset service) can > supply all of the resources needed by the destination world directly. > No more prison planet. > > The Web doesn't usually provide a good analogy with virtual worlds > because its architecture is substantially different in several areas. > However, in respect of teleports the analogy is a direct one. One > world should not limit your ability to teleport to another world any > more than one website should have a say on which website you visit next. > > In summary, the inter-world teleport requirement that you describe is > a good one, but it should not be implemented as a cooperative > agreement between worlds because that has very negative repercussions > for residents, turning them into hapless inmates and splitting > communities apart. > > Instead, VWRAP provides the excellent concept of independent external > shared asset services which can serve content to multiple worlds. > Using them we can design a teleport protocol that empowers users and > helps the open metaverse bloom, instead of enslaving them and > balkanizing worlds into non-communicating factions. > > > Morgaine. > > > > > > ====================== > > On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee > wrote: > > So, for example, one protocol we would like to define, in the name > of VW interoperability, is how a client, (a viewer and it's user > in this case), communicates, to a specific grid X authentication > server, that it wants to connect to that grid using grid Y > authentication server, which could be another grid or facebook, > etc. The communication that happens there needs to have some way > to determine if that grid Y authentication service is allowed or > known, and if it was successful in authenticating you, among other > things. So, this is, in a way, service level interop, but like you > said, a bit orthogonal. Also, in addition to the communication > between the above service and client, there would have to be > communication between grid X authentication service and grid Y > authentication service. More protocol this group would likely > specify, I assume. > > Peace, > Sean > > > On 03/30/2011 03:40 PM, Morgaine wrote: > > Very well put, Vaughn. > > Regarding "service level interoperability", it's not really a > subset of > VW interoperability at all, but lies orthogonal to it because > it is a > property of all multipart systems that implement services. > I'll try to > explain. > > Client-server systems for example have at least two distinct > parts with > distinct roles, server(s) and client(s). Service-level > interoperability > typically consists of designing and specifying the protocols or > interfaces between them in such a way that any part of the > system is > interchangeable with another equivalent part that performs the > same > role, say from a different manufacturer, and the system as a > whole still > continues to work normally. > > This rarely needs to be honored with a fancy title such as > "service > level interoperability" in these days of IETF standards and highly > cross-platform web applications. Historically however, > applications did > not behave quite so nicely, and vendors often sought to lock > customers > in with hidden proprietary interfaces, so there was a need for > adding > "service level interoperability" to the tendering > documentation in days > gone by, to avoid surprises later on. > > Today, the need for that has almost disappeared, and if your > online > service has a documented protocol interface then "service level > interoperability" is virtually assured without doing anything > at all, > assuming normal commonsense has prevailed during development > (and there > is no deliberate obfuscation of course). There is only one > other area > of this topic where a little more needs to be said. > > Protocol messages can normally be validated syntactically to a > strong > degree, and whether a message is correct or not is normally known > immediately upon syntactic validation. Unfortunately, that is not > always the end of the story, because protocols can transport > complex > data items which are valid syntactically yet invalid semantically. > > This is the last vestige of where that term is commonly > encountered, as > *Service Level Semantic Interoperability*. Is it relevant to > us? Yes, > a little. For example, it would do us no good to transport > Collada > meshes from an asset service to a client that tries to render > them as > some other graphics format --- that would create a semantic > mishap, > because one party thinks that the items means one thing and > another > party applies a different semantic. So yes, there is a little > more for > us to consider here, but it's not a lot. In most part we have > already > stated the solution every time that we have mentioned MIME > types for > describing content. This is mostly a solved problem. > > There may be one or two other areas where we have to specify the > required semantic alongside the simple matter of protocol > syntax, but > that's a standard part of defining protocols. There is > nothing really > new here. > > Lastly, service level interoperability focuses entirely on single > services and their clients, so it's unrelated to interoperability > between multiple services, such as a set of virtual world > services. > This means that, apart from defining type semantics, it > doesn't get us > even a step closer towards interop between virtual worlds. > > > Morgaine. > > > > > > > ========================== > > On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > > >> wrote: > > Katherine wrote: > >It seems to me that accomodating "full" interop only would > reduce the > >number of possible implementers and use cases for our work > > I am sure that nobody suggested to we restrict ourselves > to "full" > interop only. > "Service level interop" is clearly subset of VW > interoperability. You > can't have VW interoperability without service level > interoperability! > However, If i understand Morgaine right, she is worried > that the VWRAP > specs will be *restricted* to service level interop only. > > It has been argued (sorry, I forgot by whom) that proper > specifications of service level interop will give us > virtual world > interop for free. I think we need a bit more, but i really > have a hard > time envisioning how service level interop can be specified > in such a > way that it *prevents* VW interop, at least not if we pay > attention to > this aspect, and clearly we do. So in conclusion i do not > see much of > a problem. > > Izzy wrote in another tread "This whole argument between > service level > interop and 'full' interop eludes me." At first it eluded > me to, but > now i think that what is actually expressed in these > discussions is > the question of the scope of our effort as well as design > approach. > Some prefer to work bottom up, following their primary > interests in > getting the low level protocols working, especially since > that will > already be good enough for (all?) of their use cases . Some > prefer a > more top-down approach, first sketching the high level > picture of the > users perception of VW interop, and from there working > downwards, > obviously also because that approach optimises the > realisation of > *their* use cases. > > I think we need both, and above all, i do feel that the two > approaches > are not al all incompatible and both are without any doubt > square > within the current charter. > Formally splitting our effort in two working parties along > the current > visible fissures and getting each to work on their own > interest is a > recipe for disaster. It will only strengthen the animosity > that is > already slowing us down tremendously, and will sustain the > infighting. > Rather than spitting efforts off, we need to address the > causes for > the current disagreement and found common ground. In my > view that is > not all all hard. > > I have been reviewing the discussion we had in September > and i am > actually amazed at the level of consensus that is expressed > in those > email exchanges. Unfortuanately we have been very bad at > consolidating > that consensus. As a result we recycle the same problems > time and time > again. The archives make very depressing reading from that > point of > view. We need to do more documentation for sure. > > I am currently going over the September discussion and > looking up the > places were we all agreed on the way forward. Much of that > is still > undocumented, and my aim is to get those points written > down in the > wiki. > > As i final point i want to make clear how I understand the term > "Service Level Interop". I used the term, and since the > glosary entry > is still emtpy, i feel obliged to add at least my personal > reading. If > somebody disagrees, please add an improved version. > > Service level interoperability: > A subset of "Virtual World Interoperability" as > defined by > the VWRAP > protocol. Service level interoperabity loosely describes > specific > interactions between VWRAP endpoints. These inteactions > form the glue > that hold a particular virtual world together, but might > just as well > be used for communication between different VWRAP > compatible virtual > worlds (i.e. crossing trust domains). > > I intend to put this up in the glossary, but first will see > how it > flies here :) > > On 3/29/11, Katherine Mancuso > >> wrote: > > 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 > > > > ---------------------------------------------------------------------------------------------- > > _______________________________________________ > > 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > > -- > > Sean Hennessee > Central Computing Support > Office of Information Technology > UC Irvine > > > ... . .- -. / .... . -. -. . ... ... . . > > _______________________________________________ > 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 From morgaine.dinova@googlemail.com Wed Mar 30 23:34:56 2011 Return-Path: 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 397893A6B04 for ; Wed, 30 Mar 2011 23:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 AB3I85QOURcX for ; Wed, 30 Mar 2011 23:34:53 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 97AB93A6B00 for ; Wed, 30 Mar 2011 23:34:52 -0700 (PDT) Received: by qwg5 with SMTP id 5so1485686qwg.31 for ; Wed, 30 Mar 2011 23:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=32EFSafzPIXPUx2SBEVngXpkzFgd9CvJnBFwbkvigcY=; b=WdD1OgG/DGs5zJbYL/JV+khDfu/lqK3554fe5Qlrmn817sRiSRaohioo5RblkJkZGQ jU8ptE26V9MFx6J3ik6Ms+cPj7gUhrFMFe71yADrTM108PbNx7I3D8ejNzb2RS7d/dSn M+HxVPk4yiWwU1tM/moNjSm4QqaV/69X+cYI4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=PiDK2AcfSlTHY4SZOINhABEw61gMYS3cWzDFGQAyOz8K2cFq76CI+DOBRh68NqV43m lxHmI/njJHAWK8wlYDM8wuAomRbc/ZM9SurirmM4WG8JjNGXdTdNhDsSdzY0lbpcidB4 1FcruaSbnIqPEM+2KmSM07dNTkPZAjNPPkug8= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr1881778qcd.147.1301553312709; Wed, 30 Mar 2011 23:35:12 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Wed, 30 Mar 2011 23:35:12 -0700 (PDT) In-Reply-To: <4D9406B6.20308@uci.edu> References: <4D93BADB.1010202@uci.edu> <4D9406B6.20308@uci.edu> Date: Thu, 31 Mar 2011 07:35:12 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c0dc3c67049fc17e6a Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 06:34:56 -0000 --0016368340c0dc3c67049fc17e6a Content-Type: text/plain; charset=ISO-8859-1 Oh, that sounds fine then, Sean. (It was only your final part concerning grid-to-grid authentication that gave it all the bad properties and dangers that I highlighted.) Your suggestion about multiple authentication services seems to be very much in line with our avoidance of singletons. No matter how much one might like a universal single sign on, worlds are going to employ a diversity of authentication systems and we will need to adapt to that, otherwise users will be unnecessarily restricted in the worlds to which they can travel. Morgaine. =========================== On Thu, Mar 31, 2011 at 5:44 AM, Sean Hennessee wrote: > On 3/30/11 5:17 PM, Morgaine wrote: > >> That's a good requirement, Sean. >> >> However, you're suggesting a rather inflexible way of achieving it, >> because it would rely on one world giving you access to another world. This >> doesn't scale at all when you consider thousands, let alone millions, of >> destination worlds. >> > I think you misunderstand my example. > > The 'Grid Y' authentication service that was used in the example is the one > that the end user _chose_ to use, not forced by a restriction of it's > current grid or poor protocol definition. They would have the option to > choose any authentication service they want, like OpenID, Facebook, Google, > their home grid's authentication service, or their own home grown > authentication service they are running for themselves. They could even have > the option to connect to a grid that does not require authentication. Some > grids will allow only a few authentication methods/services; some grids > won't allow any except their own, and some grids won't care. > > An additional thought would be having the ability to have a list of > authentication services that you, the end user, are willing to use, (via > some preferences in the client viewer application), leaving the negotiation > process to determine which one to use, (or none at all), for that particular > destination grid. > > Other options that could be negotiated during the authentication phase > could be asset services used, IM services used, voice services used, etc. > These would not necessarily be options set by the end users current grid, > but by the end user herself, (through the viewer client program likely). As > above, some grids may accept any asset service, or only a limited list of > trusted asset services, or none at all except it's own. This should not be > limited to only one of each service, either. I commonly login to Yahoo and > AIM at the same time to connect with friends that are only connect to one > service or the other. > > There really has to be some kind of negotiations, otherwise you could be > doing the equivalent of telling Google that you planned to login to their > webmail service using AOL's Instant Messenger authentication services, > whether they allow it or not. > > Peace, > Sean > >> Also, it would result in balkanization of the metaverse, as restrictive >> world operators seek to prevent you from travelling to worlds they don't >> like. We'd end up with prison enclaves in which the only way for inmates to >> "escape" to visit friends in non-permitted worlds would be to log out from >> this prison and log in to a different one, which defeats most of the >> benefits of VW interop. It's a poor approach. >> >> Fortunately there is a much better way to achieve this, and David hinted >> at it when he wrote about the near impossibility of one world forcing local >> policy onto services run by somebody else. If your assets are not held by a >> world operator but in an independent external asset service (which could >> even be on your local system), then you don't need to ask the current world >> for "permission" to teleport to some other world, since you (or your >> external asset service) can supply all of the resources needed by the >> destination world directly. No more prison planet. >> >> The Web doesn't usually provide a good analogy with virtual worlds because >> its architecture is substantially different in several areas. However, in >> respect of teleports the analogy is a direct one. One world should not >> limit your ability to teleport to another world any more than one website >> should have a say on which website you visit next. >> >> In summary, the inter-world teleport requirement that you describe is a >> good one, but it should not be implemented as a cooperative agreement >> between worlds because that has very negative repercussions for residents, >> turning them into hapless inmates and splitting communities apart. >> >> Instead, VWRAP provides the excellent concept of independent external >> shared asset services which can serve content to multiple worlds. Using >> them we can design a teleport protocol that empowers users and helps the >> open metaverse bloom, instead of enslaving them and balkanizing worlds into >> non-communicating factions. >> >> >> Morgaine. >> >> >> >> >> >> ====================== >> >> On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee > sean@uci.edu>> wrote: >> >> So, for example, one protocol we would like to define, in the name >> of VW interoperability, is how a client, (a viewer and it's user >> in this case), communicates, to a specific grid X authentication >> server, that it wants to connect to that grid using grid Y >> authentication server, which could be another grid or facebook, >> etc. The communication that happens there needs to have some way >> to determine if that grid Y authentication service is allowed or >> known, and if it was successful in authenticating you, among other >> things. So, this is, in a way, service level interop, but like you >> said, a bit orthogonal. Also, in addition to the communication >> between the above service and client, there would have to be >> communication between grid X authentication service and grid Y >> authentication service. More protocol this group would likely >> specify, I assume. >> >> Peace, >> Sean >> >> >> On 03/30/2011 03:40 PM, Morgaine wrote: >> >> Very well put, Vaughn. >> >> Regarding "service level interoperability", it's not really a >> subset of >> VW interoperability at all, but lies orthogonal to it because >> it is a >> property of all multipart systems that implement services. >> I'll try to >> explain. >> >> Client-server systems for example have at least two distinct >> parts with >> distinct roles, server(s) and client(s). Service-level >> interoperability >> typically consists of designing and specifying the protocols or >> interfaces between them in such a way that any part of the >> system is >> interchangeable with another equivalent part that performs the >> same >> role, say from a different manufacturer, and the system as a >> whole still >> continues to work normally. >> >> This rarely needs to be honored with a fancy title such as >> "service >> level interoperability" in these days of IETF standards and highly >> cross-platform web applications. Historically however, >> applications did >> not behave quite so nicely, and vendors often sought to lock >> customers >> in with hidden proprietary interfaces, so there was a need for >> adding >> "service level interoperability" to the tendering >> documentation in days >> gone by, to avoid surprises later on. >> >> Today, the need for that has almost disappeared, and if your >> online >> service has a documented protocol interface then "service level >> interoperability" is virtually assured without doing anything >> at all, >> assuming normal commonsense has prevailed during development >> (and there >> is no deliberate obfuscation of course). There is only one >> other area >> of this topic where a little more needs to be said. >> >> Protocol messages can normally be validated syntactically to a >> strong >> degree, and whether a message is correct or not is normally known >> immediately upon syntactic validation. Unfortunately, that is not >> always the end of the story, because protocols can transport >> complex >> data items which are valid syntactically yet invalid semantically. >> >> This is the last vestige of where that term is commonly >> encountered, as >> *Service Level Semantic Interoperability*. Is it relevant to >> us? Yes, >> a little. For example, it would do us no good to transport >> Collada >> meshes from an asset service to a client that tries to render >> them as >> some other graphics format --- that would create a semantic >> mishap, >> because one party thinks that the items means one thing and >> another >> party applies a different semantic. So yes, there is a little >> more for >> us to consider here, but it's not a lot. In most part we have >> already >> stated the solution every time that we have mentioned MIME >> types for >> describing content. This is mostly a solved problem. >> >> There may be one or two other areas where we have to specify the >> required semantic alongside the simple matter of protocol >> syntax, but >> that's a standard part of defining protocols. There is >> nothing really >> new here. >> >> Lastly, service level interoperability focuses entirely on single >> services and their clients, so it's unrelated to interoperability >> between multiple services, such as a set of virtual world >> services. >> This means that, apart from defining type semantics, it >> doesn't get us >> even a step closer towards interop between virtual worlds. >> >> >> Morgaine. >> >> >> >> >> >> >> ========================== >> >> On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca >> >> > >> wrote: >> >> Katherine wrote: >> >It seems to me that accomodating "full" interop only would >> reduce the >> >number of possible implementers and use cases for our work >> >> I am sure that nobody suggested to we restrict ourselves >> to "full" >> interop only. >> "Service level interop" is clearly subset of VW >> interoperability. You >> can't have VW interoperability without service level >> interoperability! >> However, If i understand Morgaine right, she is worried >> that the VWRAP >> specs will be *restricted* to service level interop only. >> >> It has been argued (sorry, I forgot by whom) that proper >> specifications of service level interop will give us >> virtual world >> interop for free. I think we need a bit more, but i really >> have a hard >> time envisioning how service level interop can be specified >> in such a >> way that it *prevents* VW interop, at least not if we pay >> attention to >> this aspect, and clearly we do. So in conclusion i do not >> see much of >> a problem. >> >> Izzy wrote in another tread "This whole argument between >> service level >> interop and 'full' interop eludes me." At first it eluded >> me to, but >> now i think that what is actually expressed in these >> discussions is >> the question of the scope of our effort as well as design >> approach. >> Some prefer to work bottom up, following their primary >> interests in >> getting the low level protocols working, especially since >> that will >> already be good enough for (all?) of their use cases . Some >> prefer a >> more top-down approach, first sketching the high level >> picture of the >> users perception of VW interop, and from there working >> downwards, >> obviously also because that approach optimises the >> realisation of >> *their* use cases. >> >> I think we need both, and above all, i do feel that the two >> approaches >> are not al all incompatible and both are without any doubt >> square >> within the current charter. >> Formally splitting our effort in two working parties along >> the current >> visible fissures and getting each to work on their own >> interest is a >> recipe for disaster. It will only strengthen the animosity >> that is >> already slowing us down tremendously, and will sustain the >> infighting. >> Rather than spitting efforts off, we need to address the >> causes for >> the current disagreement and found common ground. In my >> view that is >> not all all hard. >> >> I have been reviewing the discussion we had in September >> and i am >> actually amazed at the level of consensus that is expressed >> in those >> email exchanges. Unfortuanately we have been very bad at >> consolidating >> that consensus. As a result we recycle the same problems >> time and time >> again. The archives make very depressing reading from that >> point of >> view. We need to do more documentation for sure. >> >> I am currently going over the September discussion and >> looking up the >> places were we all agreed on the way forward. Much of that >> is still >> undocumented, and my aim is to get those points written >> down in the >> wiki. >> >> As i final point i want to make clear how I understand the term >> "Service Level Interop". I used the term, and since the >> glosary entry >> is still emtpy, i feel obliged to add at least my personal >> reading. If >> somebody disagrees, please add an improved version. >> >> Service level interoperability: >> A subset of "Virtual World Interoperability" as >> defined by >> the VWRAP >> protocol. Service level interoperabity loosely describes >> specific >> interactions between VWRAP endpoints. These inteactions >> form the glue >> that hold a particular virtual world together, but might >> just as well >> be used for communication between different VWRAP >> compatible virtual >> worlds (i.e. crossing trust domains). >> >> I intend to put this up in the glossary, but first will see >> how it >> flies here :) >> >> On 3/29/11, Katherine Mancuso > >> >> wrote: >> > 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 >> > >> >> ---------------------------------------------------------------------------------------------- >> > _______________________________________________ >> > 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 mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> -- >> Sean Hennessee >> Central Computing Support >> Office of Information Technology >> UC Irvine >> >> >> ... . .- -. / .... . -. -. . ... ... . . >> >> _______________________________________________ >> 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016368340c0dc3c67049fc17e6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Oh, that sounds fine then, Sean.

(It was only your final part concer= ning grid-to-grid authentication that gave it all the bad properties and da= ngers that I highlighted.)

Your suggestion about multiple authentica= tion services seems to be very much in line with our avoidance of singleton= s.=A0 No matter how much one might like a universal single sign on, worlds = are going to employ a diversity of authentication systems and we will need = to adapt to that, otherwise users will be unnecessarily restricted in the w= orlds to which they can travel.

Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Thu, Mar 31, 2011 at 5:44 AM, Sean Hennessee = <sean@uci.edu> wrote:
On 3/30/11 5:17 PM, Morgaine wrote:
That's a good requirement, Sean.

However, you're suggesting a rather inflexible way of achieving it, bec= ause it would rely on one world giving you access to another world. =A0This= doesn't scale at all when you consider thousands, let alone millions, = of destination worlds.
I think you misunderstand my example.

The 'Grid Y' authentication service that was used in the example is= the one that the end user _chose_ to use, not forced by a restriction of i= t's current grid or poor protocol definition. They would have the optio= n to choose any authentication service they want, like OpenID, Facebook, Go= ogle, their home grid's authentication service, or their own home grown= authentication service they are running for themselves. They could even ha= ve the option to connect to a grid that does not require authentication. So= me grids will allow only a few authentication methods/services; some grids = won't allow any except their own, and some grids won't care.

An additional thought would be having the ability to have a list of authent= ication services that you, the end user, are willing to use, (via some pref= erences in the client viewer application), leaving the negotiation process = to determine which one to use, (or none at all), for that particular destin= ation grid.

Other options that could be negotiated during the authentication phase coul= d be asset services used, IM services used, voice services used, etc. These= would not necessarily be options set by the end users current grid, but by= the end user herself, (through the viewer client program likely). As above= , some grids may accept any asset service, or only a limited list of truste= d asset services, or none at all except it's own. This should not be li= mited to only one of each service, either. I commonly login to Yahoo and AI= M at the same time to connect with friends that are only connect to one ser= vice or the other.

There really has to be some kind of negotiations, otherwise you could be do= ing the equivalent of telling Google that you planned to login to their web= mail service using AOL's Instant Messenger authentication services, whe= ther they allow it or not.

Peace,
Sean
Also, it would result in balkanization of the metaverse, as restrictive wor= ld operators seek to prevent you from travelling to worlds they don't l= ike. =A0We'd end up with prison enclaves in which the only way for inma= tes to "escape" to visit friends in non-permitted worlds would be= to log out from this prison and log in to a different one, which defeats m= ost of the benefits of VW interop. =A0It's a poor approach.

Fortunately there is a much better way to achieve this, and David hinted at= it when he wrote about the near impossibility of one world forcing local p= olicy onto services run by somebody else. =A0If your assets are not held by= a world operator but in an independent external asset service (which could= even be on your local system), then you don't need to ask the current = world for "permission" to teleport to some other world, since you= (or your external asset service) can supply all of the resources needed by= the destination world directly. =A0No more prison planet.

The Web doesn't usually provide a good analogy with virtual worlds beca= use its architecture is substantially different in several areas. =A0Howeve= r, in respect of teleports the analogy is a direct one. =A0One world should= not limit your ability to teleport to another world any more than one webs= ite should have a say on which website you visit next.

In summary, the inter-world teleport requirement that you describe is a goo= d one, but it should not be implemented as a cooperative agreement between = worlds because that has very negative repercussions for residents, turning = them into hapless inmates and splitting communities apart.

Instead, VWRAP provides the excellent concept of independent external share= d asset services which can serve content to multiple worlds. =A0Using them = we can design a teleport protocol that empowers users and helps the open me= taverse bloom, instead of enslaving them and balkanizing worlds into non-co= mmunicating factions.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee <sean@uci.edu <mailto:sean@uci.edu>> wrote:

=A0 =A0So, for example, one protocol we would like to define, in the name<= br> =A0 =A0of VW interoperability, is how a client, (a viewer and it's use= r
=A0 =A0in this case), communicates, to a specific grid X authentication =A0 =A0server, that it wants to connect to that grid using grid Y
=A0 =A0authentication server, which could be another grid or facebook,
=A0 =A0etc. The communication that happens there needs to have some way =A0 =A0to determine if that grid Y authentication service is allowed or =A0 =A0known, and if it was successful in authenticating you, among other<= br> =A0 =A0things. So, this is, in a way, service level interop, but like you<= br> =A0 =A0said, a bit orthogonal. Also, in addition to the communication
=A0 =A0between the above service and client, there would have to be
=A0 =A0communication between grid X authentication service and grid Y
=A0 =A0authentication service. More protocol this group would likely
=A0 =A0specify, I assume.

=A0 =A0Peace,
=A0 =A0Sean


=A0 =A0On 03/30/2011 03:40 PM, Morgaine wrote:

=A0 =A0 =A0 =A0Very well put, Vaughn.

=A0 =A0 =A0 =A0Regarding "service level interoperability", it= 9;s not really a
=A0 =A0 =A0 =A0subset of
=A0 =A0 =A0 =A0VW interoperability at all, but lies orthogonal to it becau= se
=A0 =A0 =A0 =A0it is a
=A0 =A0 =A0 =A0property of all multipart systems that implement services.<= br> =A0 =A0 =A0 =A0 I'll try to
=A0 =A0 =A0 =A0explain.

=A0 =A0 =A0 =A0Client-server systems for example have at least two distinc= t
=A0 =A0 =A0 =A0parts with
=A0 =A0 =A0 =A0distinct roles, server(s) and client(s). =A0Service-level =A0 =A0 =A0 =A0interoperability
=A0 =A0 =A0 =A0typically consists of designing and specifying the protocol= s or
=A0 =A0 =A0 =A0interfaces between them in such a way that any part of the<= br> =A0 =A0 =A0 =A0system is
=A0 =A0 =A0 =A0interchangeable with another equivalent part that performs = the
=A0 =A0 =A0 =A0same
=A0 =A0 =A0 =A0role, say from a different manufacturer, and the system as = a
=A0 =A0 =A0 =A0whole still
=A0 =A0 =A0 =A0continues to work normally.

=A0 =A0 =A0 =A0This rarely needs to be honored with a fancy title such as<= br> =A0 =A0 =A0 =A0"service
=A0 =A0 =A0 =A0level interoperability" in these days of IETF standard= s and highly
=A0 =A0 =A0 =A0cross-platform web applications. =A0Historically however, =A0 =A0 =A0 =A0applications did
=A0 =A0 =A0 =A0not behave quite so nicely, and vendors often sought to loc= k
=A0 =A0 =A0 =A0customers
=A0 =A0 =A0 =A0in with hidden proprietary interfaces, so there was a need = for
=A0 =A0 =A0 =A0adding
=A0 =A0 =A0 =A0"service level interoperability" to the tendering=
=A0 =A0 =A0 =A0documentation in days
=A0 =A0 =A0 =A0gone by, to avoid surprises later on.

=A0 =A0 =A0 =A0Today, the need for that has almost disappeared, and if you= r
=A0 =A0 =A0 =A0online
=A0 =A0 =A0 =A0service has a documented protocol interface then "serv= ice level
=A0 =A0 =A0 =A0interoperability" is virtually assured without doing a= nything
=A0 =A0 =A0 =A0at all,
=A0 =A0 =A0 =A0assuming normal commonsense has prevailed during developmen= t
=A0 =A0 =A0 =A0(and there
=A0 =A0 =A0 =A0is no deliberate obfuscation of course). =A0There is only o= ne
=A0 =A0 =A0 =A0other area
=A0 =A0 =A0 =A0of this topic where a little more needs to be said.

=A0 =A0 =A0 =A0Protocol messages can normally be validated syntactically t= o a
=A0 =A0 =A0 =A0strong
=A0 =A0 =A0 =A0degree, and whether a message is correct or not is normally= known
=A0 =A0 =A0 =A0immediately upon syntactic validation. =A0Unfortunately, th= at is not
=A0 =A0 =A0 =A0always the end of the story, because protocols can transpor= t
=A0 =A0 =A0 =A0complex
=A0 =A0 =A0 =A0data items which are valid syntactically yet invalid semant= ically.

=A0 =A0 =A0 =A0This is the last vestige of where that term is commonly
=A0 =A0 =A0 =A0encountered, as
=A0 =A0 =A0 =A0*Service Level Semantic Interoperability*. =A0Is it relevan= t to
=A0 =A0 =A0 =A0us? =A0Yes,
=A0 =A0 =A0 =A0a little. =A0For example, it would do us no good to transpo= rt
=A0 =A0 =A0 =A0Collada
=A0 =A0 =A0 =A0meshes from an asset service to a client that tries to rend= er
=A0 =A0 =A0 =A0them as
=A0 =A0 =A0 =A0some other graphics format --- that would create a semantic=
=A0 =A0 =A0 =A0mishap,
=A0 =A0 =A0 =A0because one party thinks that the items means one thing and=
=A0 =A0 =A0 =A0another
=A0 =A0 =A0 =A0party applies a different semantic. =A0So yes, there is a l= ittle
=A0 =A0 =A0 =A0more for
=A0 =A0 =A0 =A0us to consider here, but it's not a lot. =A0In most par= t we have
=A0 =A0 =A0 =A0already
=A0 =A0 =A0 =A0stated the solution every time that we have mentioned MIME<= br> =A0 =A0 =A0 =A0types for
=A0 =A0 =A0 =A0describing content. =A0This is mostly a solved problem.

=A0 =A0 =A0 =A0There may be one or two other areas where we have to specif= y the
=A0 =A0 =A0 =A0required semantic alongside the simple matter of protocol =A0 =A0 =A0 =A0syntax, but
=A0 =A0 =A0 =A0that's a standard part of defining protocols. =A0There = is
=A0 =A0 =A0 =A0nothing really
=A0 =A0 =A0 =A0new here.

=A0 =A0 =A0 =A0Lastly, service level interoperability focuses entirely on = single
=A0 =A0 =A0 =A0services and their clients, so it's unrelated to intero= perability
=A0 =A0 =A0 =A0between multiple services, such as a set of virtual world =A0 =A0 =A0 =A0services.
=A0 =A0 =A0 =A0This means that, apart from defining type semantics, it
=A0 =A0 =A0 =A0doesn't get us
=A0 =A0 =A0 =A0even a step closer towards interop between virtual worlds.<= br>

=A0 =A0 =A0 =A0Morgaine.






=A0 =A0 =A0 =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

=A0 =A0 =A0 =A0On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca
=A0 =A0 =A0 =A0<vaughn.deluca@gmail.com <mailto:vaughn.deluca@gmail.com>
=A0 =A0 =A0 =A0<mailto:vaughn.deluca@gmail.com
=A0 =A0 =A0 =A0<mailto:vaughn.deluca@gmail.com>>> wrote:

=A0 =A0 =A0 =A0 =A0 Katherine wrote:
=A0 =A0 =A0 =A0>It seems to me that accomodating "full" inter= op only would
=A0 =A0 =A0 =A0reduce the
=A0 =A0 =A0 =A0>number of possible implementers and use cases for our w= ork

=A0 =A0 =A0 =A0 =A0 I am sure that nobody =A0suggested to we restrict ours= elves
=A0 =A0 =A0 =A0to "full"
=A0 =A0 =A0 =A0 =A0 interop only.
=A0 =A0 =A0 =A0 =A0 "Service level interop" is clearly subset of= VW
=A0 =A0 =A0 =A0interoperability. You
=A0 =A0 =A0 =A0 =A0 can't have VW interoperability without service lev= el
=A0 =A0 =A0 =A0interoperability!
=A0 =A0 =A0 =A0 =A0 However, If i understand Morgaine right, she is worrie= d
=A0 =A0 =A0 =A0that the VWRAP
=A0 =A0 =A0 =A0 =A0 specs will be *restricted* to service level interop on= ly.

=A0 =A0 =A0 =A0 =A0 It has been argued (sorry, I forgot by whom) that prop= er
=A0 =A0 =A0 =A0 =A0 specifications of service level interop will give us =A0 =A0 =A0 =A0virtual world
=A0 =A0 =A0 =A0 =A0 interop for free. I think we need a bit more, but i re= ally
=A0 =A0 =A0 =A0have a hard
=A0 =A0 =A0 =A0 =A0 time envisioning how service level interop can be spec= ified
=A0 =A0 =A0 =A0in such a
=A0 =A0 =A0 =A0 =A0 way that it *prevents* VW interop, at least not if we = pay
=A0 =A0 =A0 =A0attention to
=A0 =A0 =A0 =A0 =A0 this aspect, and clearly we do. So in conclusion i do = not
=A0 =A0 =A0 =A0see much of
=A0 =A0 =A0 =A0 =A0 a problem.

=A0 =A0 =A0 =A0 =A0 Izzy wrote in another tread "This whole argument = between
=A0 =A0 =A0 =A0service level
=A0 =A0 =A0 =A0 =A0 interop and 'full' interop eludes me." At= first it eluded
=A0 =A0 =A0 =A0me to, but
=A0 =A0 =A0 =A0 =A0 now i think that what is actually expressed in these =A0 =A0 =A0 =A0discussions is
=A0 =A0 =A0 =A0 =A0 the question of the scope of our effort as well as des= ign
=A0 =A0 =A0 =A0approach.
=A0 =A0 =A0 =A0 =A0 Some prefer to work bottom up, following their primary=
=A0 =A0 =A0 =A0interests in
=A0 =A0 =A0 =A0 =A0 getting the low level protocols working, especially si= nce
=A0 =A0 =A0 =A0that will
=A0 =A0 =A0 =A0 =A0 already be good enough for (all?) of their use cases .= Some
=A0 =A0 =A0 =A0prefer a
=A0 =A0 =A0 =A0 =A0 more top-down approach, first sketching the high level=
=A0 =A0 =A0 =A0picture of the
=A0 =A0 =A0 =A0 =A0 users perception of VW interop, =A0and from there work= ing
=A0 =A0 =A0 =A0downwards,
=A0 =A0 =A0 =A0 =A0 obviously also because that approach optimises the
=A0 =A0 =A0 =A0realisation of
=A0 =A0 =A0 =A0 =A0 *their* use cases.

=A0 =A0 =A0 =A0 =A0 I think we need both, and above all, i do feel that th= e two
=A0 =A0 =A0 =A0approaches
=A0 =A0 =A0 =A0 =A0 are not al all incompatible and both are without any d= oubt
=A0 =A0 =A0 =A0square
=A0 =A0 =A0 =A0 =A0 within the current charter.
=A0 =A0 =A0 =A0 =A0 Formally splitting our effort in two working parties a= long
=A0 =A0 =A0 =A0the current
=A0 =A0 =A0 =A0 =A0 visible fissures and getting each to work on their own=
=A0 =A0 =A0 =A0interest is a
=A0 =A0 =A0 =A0 =A0 recipe for disaster. It will only strengthen the animo= sity
=A0 =A0 =A0 =A0that is
=A0 =A0 =A0 =A0 =A0 already slowing us down tremendously, and will sustain= the
=A0 =A0 =A0 =A0infighting.
=A0 =A0 =A0 =A0 =A0 Rather than spitting efforts off, we need to address t= he
=A0 =A0 =A0 =A0causes for
=A0 =A0 =A0 =A0 =A0 the current disagreement and found common ground. =A0I= n my
=A0 =A0 =A0 =A0view that is
=A0 =A0 =A0 =A0 =A0 not all all hard.

=A0 =A0 =A0 =A0 =A0 I have been reviewing the discussion we had in Septemb= er
=A0 =A0 =A0 =A0and i am
=A0 =A0 =A0 =A0 =A0 actually amazed at the level of consensus that is expr= essed
=A0 =A0 =A0 =A0in those
=A0 =A0 =A0 =A0 =A0 email exchanges. Unfortuanately we have been very bad = at
=A0 =A0 =A0 =A0consolidating
=A0 =A0 =A0 =A0 =A0 that consensus. As a result we recycle the same proble= ms
=A0 =A0 =A0 =A0time and time
=A0 =A0 =A0 =A0 =A0 again. The archives make very depressing reading from = that
=A0 =A0 =A0 =A0point of
=A0 =A0 =A0 =A0 =A0 view. We need to do more documentation for sure.

=A0 =A0 =A0 =A0 =A0 I am currently going over the September discussion and=
=A0 =A0 =A0 =A0looking up the
=A0 =A0 =A0 =A0 =A0 places were we all agreed on the way forward. =A0Much = of that
=A0 =A0 =A0 =A0is still
=A0 =A0 =A0 =A0 =A0 undocumented, and my aim is to get those points writte= n
=A0 =A0 =A0 =A0down in the
=A0 =A0 =A0 =A0 =A0 wiki.

=A0 =A0 =A0 =A0 =A0 As i final point i want to make clear how I understand= the term
=A0 =A0 =A0 =A0 =A0 "Service Level Interop". I used the term, an= d since the
=A0 =A0 =A0 =A0glosary entry
=A0 =A0 =A0 =A0 =A0 is still emtpy, i feel obliged to add at least my pers= onal
=A0 =A0 =A0 =A0reading. If
=A0 =A0 =A0 =A0 =A0 somebody disagrees, please add an improved version.
=A0 =A0 =A0 =A0 =A0 Service level interoperability:
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A subset of "Virtual World Intero= perability" as
=A0 =A0 =A0 =A0defined by
=A0 =A0 =A0 =A0 =A0 the VWRAP
=A0 =A0 =A0 =A0 =A0 protocol. Service level interoperabity loosely describ= es
=A0 =A0 =A0 =A0specific
=A0 =A0 =A0 =A0 =A0 interactions between VWRAP endpoints. These inteaction= s
=A0 =A0 =A0 =A0form the glue
=A0 =A0 =A0 =A0 =A0 that hold a particular virtual world together, but mig= ht
=A0 =A0 =A0 =A0just as well
=A0 =A0 =A0 =A0 =A0 be used for communication between different VWRAP
=A0 =A0 =A0 =A0compatible virtual
=A0 =A0 =A0 =A0 =A0 worlds (i.e. crossing trust domains).

=A0 =A0 =A0 =A0 =A0 I intend to put this up in the glossary, but first wil= l see
=A0 =A0 =A0 =A0how it
=A0 =A0 =A0 =A0 =A0 flies here =A0:)

=A0 =A0 =A0 =A0 =A0 On 3/29/11, Katherine Mancuso <kmancuso@gmail.com
=A0 =A0 =A0 =A0<mailto:kmancuso@gmail.com>
=A0 =A0 =A0 =A0<mailto:kmancuso@gmail.com <mailto:kmancuso@gmail.com>>> wrote:
=A0 =A0 =A0 =A0> Hi everyone,
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> I want to speak up for agreeing with Meadhbh & Mik= e about
=A0 =A0 =A0 =A0keeping a
=A0 =A0 =A0 =A0> role for service level interop in this group. =A0We= 9;ve made good
=A0 =A0 =A0 =A0> progress towards this goal and can continue to work on= it.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> Here is an alternative proposal to any which has been<= br> =A0 =A0 =A0 =A0brought up so
=A0 =A0 =A0 =A0> far. =A0I'm aware this may not be fully correct in= its technical
=A0 =A0 =A0 =A0> details, as I am not a software architect:
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> Could the partisans of "full" VW interop con= sider working
=A0 =A0 =A0 =A0together on
=A0 =A0 =A0 =A0> a draft specification that is something like the intro= or
=A0 =A0 =A0 =A0David's
=A0 =A0 =A0 =A0> piece in scope that lays out which specific capacities= would
=A0 =A0 =A0 =A0need to
=A0 =A0 =A0 =A0> be supported at a minimum to allow for "full"= ; interop, perhaps
=A0 =A0 =A0 =A0 =A0 getting
=A0 =A0 =A0 =A0> input from implementers such as the Hypergrid folks an= d the
=A0 =A0 =A0 =A0folks who
=A0 =A0 =A0 =A0> coordinated the teleport test at Linden? =A0Citing exi= sting
=A0 =A0 =A0 =A0service
=A0 =A0 =A0 =A0> specifications (either ones developed within this WG, = or outside
=A0 =A0 =A0 =A0> specifications like XML, Collada, etc) is preferred, a= nd for
=A0 =A0 =A0 =A0> capabilities for which there are not existing service<= br> =A0 =A0 =A0 =A0specifications
=A0 =A0 =A0 =A0> or the existing specifications don't work well eno= ugh, address
=A0 =A0 =A0 =A0 =A0 that to
=A0 =A0 =A0 =A0> lay out a clear roadmap of what must be developed.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> My vision here is that folks who are doing service-lev= el
=A0 =A0 =A0 =A0work could
=A0 =A0 =A0 =A0> continue developing and implementing their individual<= br> =A0 =A0 =A0 =A0services, and
=A0 =A0 =A0 =A0> the folks who wish to do "full" interop coul= d define a menu of
=A0 =A0 =A0 =A0> services which must be implemented for "full"= ; interop.
=A0 =A0 =A0 =A0 Implementers
=A0 =A0 =A0 =A0> could then choose their path based on their use cases:=
=A0 =A0 =A0 =A0implement the
=A0 =A0 =A0 =A0> "full" interop specification including all t= he
=A0 =A0 =A0 =A0specifications called
=A0 =A0 =A0 =A0> for, or implement individual services. =A0I believe th= at both
=A0 =A0 =A0 =A0of these
=A0 =A0 =A0 =A0> concepts can exist under our existing charter or with = limited
=A0 =A0 =A0 =A0> amendment to the charter and intro, which is much easi= er for
=A0 =A0 =A0 =A0everyone
=A0 =A0 =A0 =A0> to agree to than entirely rewriting both, and does not= require
=A0 =A0 =A0 =A0> trashing years of work.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> It seems to me that accomodating "full" inte= rop only would
=A0 =A0 =A0 =A0reduce the
=A0 =A0 =A0 =A0> number of possible implementers and use cases for our = work
=A0 =A0 =A0 =A0> dramatically, not to mention cut out a productive body= of
=A0 =A0 =A0 =A0folks in
=A0 =A0 =A0 =A0> this group who have been contributing an awful lot of<= br> =A0 =A0 =A0 =A0documents and
=A0 =A0 =A0 =A0> implementing.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> For example, to illustrate my point:
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> From my work as a SL developer focusing in education, = I know
=A0 =A0 =A0 =A0 =A0 there's a
=A0 =A0 =A0 =A0> substantial use case in K-12 education in the US for w= alled
=A0 =A0 =A0 =A0gardens,
=A0 =A0 =A0 =A0> because schools have big legal liability problems with=
=A0 =A0 =A0 =A0letting minors
=A0 =A0 =A0 =A0> wander unwalled virtual worlds (most school libraries = in the
=A0 =A0 =A0 =A0US have
=A0 =A0 =A0 =A0> internet filters for the same reasons) and have fairly= intense
=A0 =A0 =A0 =A0> supervision requirements which require substantial mod= eration &
=A0 =A0 =A0 =A0> surveillance tools. =A0However, a shared asset server = that
=A0 =A0 =A0 =A0contains a
=A0 =A0 =A0 =A0> core of "safe" content might be of interest = to these folks,
=A0 =A0 =A0 =A0since
=A0 =A0 =A0 =A0> educators don't necessarily need to reinvent the w= heel for their
=A0 =A0 =A0 =A0> classrooms every year. =A0This is a really good case f= or
=A0 =A0 =A0 =A0service level
=A0 =A0 =A0 =A0> interop ... implement the asset server specification o= nly,
=A0 =A0 =A0 =A0not the
=A0 =A0 =A0 =A0> "full" one that allows you to teleport to ot= her worlds.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> On the other hand, universities have far greater inter= est in
=A0 =A0 =A0 =A0letting
=A0 =A0 =A0 =A0> students and professors teleport among university spac= es (which
=A0 =A0 =A0 =A0> happens metaphorically in the real world all the time)= , and
=A0 =A0 =A0 =A0fewer
=A0 =A0 =A0 =A0> liability issues. =A0Sharing an asset server might be = of
=A0 =A0 =A0 =A0interest to
=A0 =A0 =A0 =A0> them, but so too might "full" interop. =A0Th= ey'd want to
=A0 =A0 =A0 =A0implement the
=A0 =A0 =A0 =A0> "full" interop specification.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> (Paging Fleep Tuque, are you here to make this case be= tter
=A0 =A0 =A0 =A0for me?)
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> TL;DR - Proposal is to amend the charter & intro s= o that
=A0 =A0 =A0 =A0they allow
=A0 =A0 =A0 =A0> the "full" interop people to work in one com= munity on their
=A0 =A0 =A0 =A0ideas and
=A0 =A0 =A0 =A0> the service level interop people to work in parallel o= n
=A0 =A0 =A0 =A0their ideas,
=A0 =A0 =A0 =A0> rather than assuming that one model has to exclusively=
=A0 =A0 =A0 =A0dominate the
=A0 =A0 =A0 =A0> group.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> I will be unavailable to post anything else much lengt= hy through
=A0 =A0 =A0 =A0 =A0 3 April,
=A0 =A0 =A0 =A0> FYI.
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> Katherine
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> --
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0---------------------------------------= ------------------------------------------------------
=A0 =A0 =A0 =A0> Katherine Mancuso
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> ISIS Inc, Community Manager (http://www.isis-inc.org)
=A0 =A0 =A0 =A0> Sex::Tech Conference, Social Media Chair
=A0 =A0 =A0 =A0(http:= //www.sextech.org)
=A0 =A0 =A0 =A0> The Vesuvius Group: metaverse community builders
=A0 =A0 =A0 =A0> (http://www.thevesuviusgroup.com)
=A0 =A0 =A0 =A0> GimpGirl Community Liaison (http://www.gimpgirl.com)
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0> http://twitter.com/musingvirtual
=A0 =A0 =A0 =A0> http://facebook.com/kmancuso
=A0 =A0 =A0 =A0> http://www.linkedin.com/in/kathymancuso
=A0 =A0 =A0 =A0> Second Life: Muse Carmona
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0---------------------------------------= -------------------------------------------------------
=A0 =A0 =A0 =A0> _______________________________________________
=A0 =A0 =A0 =A0> vwrap mailing list
=A0 =A0 =A0 =A0> vw= rap@ietf.org <mailto:vwrap@ietf.org>
=A0 =A0 =A0 =A0<mailto:vwrap@ietf.org <mailto:vwrap@ietf.org>>


=A0 =A0 =A0 =A0> https://www.ietf.org/mailman/listinfo/vwrap
=A0 =A0 =A0 =A0>
=A0 =A0 =A0 =A0 =A0 _______________________________________________
=A0 =A0 =A0 =A0 =A0 vwrap mailing list
=A0 =A0 =A0 =A0vwrap@i= etf.org <mailto:= vwrap@ietf.org> <mailto:vwrap@ietf.org

=A0 =A0 =A0 =A0<mailto:vwrap@ietf.org>>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/vwrap




=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0vwrap mailing list
=A0 =A0 =A0 =A0vwrap@i= etf.org <mailto:= vwrap@ietf.org>
=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/vwrap


=A0 =A0--
=A0 =A0Sean Hennessee
=A0 =A0Central Computing Support
=A0 =A0Office of Information Technology
=A0 =A0UC Irvine


=A0 =A0... . .- -. / =A0.... . -. -. . ... ... . .

=A0 =A0_______________________________________________
=A0 =A0vwrap mailing list
=A0 =A0vwrap@ietf.org<= /a> <mailto:vwrap@ie= tf.org>
=A0 =A0https://www.ietf.org/mailman/listinfo/vwrap



_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016368340c0dc3c67049fc17e6a-- From vaughn.deluca@gmail.com Thu Mar 31 07:32:29 2011 Return-Path: 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 ED2D428C0EA for ; Thu, 31 Mar 2011 07:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 jrnWQZgieC9p for ; Thu, 31 Mar 2011 07:32:28 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8F11228C112 for ; Thu, 31 Mar 2011 07:32:27 -0700 (PDT) Received: by ewy19 with SMTP id 19so861850ewy.31 for ; Thu, 31 Mar 2011 07:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kE1mKcwzp0vobKourYcVv1U8EO4c6jNjr6mZOUvzxJ4=; b=w+JDTpL9SHl2OviNz9sdUgaK90dtnu8dQ/G4RBTE4i2sPb02CNP8RySmO60p+Ih+Fe dcqeWH+2BxPxh+o1yUMjd6HjS3gGLBsAxrQxQbGniWVToNUBppc/RsJbDQa8HVuQ0gYQ YFTja4x1l9eJfeKS4Mdi0Z5n15zrqfAf7aOr0= 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 :cc:content-type; b=izJCNPCxrcVIyAryGWy6iGpO8fc2O6uXK9L3ADykYq3U9Dz9zy8BAlPq5+ZX8+7q0q k9CZYB+zWVhpx4IvoaQKgQkCQx4E+++06RsgCMd8DHU9yeUVFTgyalSzDNItjDk86rn3 jfG+Q9mvZlEm1kJdJ0yVivIBC1z9ShmqDayzI= MIME-Version: 1.0 Received: by 10.213.2.147 with SMTP id 19mr1059779ebj.87.1301582045070; Thu, 31 Mar 2011 07:34:05 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Thu, 31 Mar 2011 07:34:04 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 16:34:04 +0200 Message-ID: From: Vaughn Deluca To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:32:30 -0000 Morgaine, Thanks a lot for the explanation, i now realise that "service level interoperability is an existing technical term, and not something that was manufactured on the fly here in the group...my bad. I will update my definition in the glossary a bit, (and use an existing source). In the process of doing my homework, and reading up on the topic, i stumbled over a very interesting piece on the web that i would like to bring up here for discussion. It is a powerpoint presentation with teaching material from the OGCII (Open Geospatial Consortium Interoperability Institute). Processing Geospatial data appears to have many problems in common with our virtual worlds. See: http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint download) The core idea is simple. A standard intermediate data format, that is used to match possibly very disparate datasets (like our assets from different virtual worlds) and some mechanisms to extend this. I might have missed this, but it seems to me that this concept has up till now not figured this explicitly in our thinking. It would be good if people on this list have a look at this material, if only to point out that it matches closely to stuff we *did*specify, or alternatively why it is *not* applicable to our case, and bad idea. However, I think it is very useful, and could easily be adapted for the VWRAP problem domain with its many disparate and distributed data sources. It anyhow nicely addresses the differences between working service level interoperability and the semantic mismatch you mentioned. --Vaughn On 3/31/11, Morgaine wrote: > Very well put, Vaughn. > > Regarding "service level interoperability", it's not really a subset of VW > interoperability at all, but lies orthogonal to it because it is a property > of all multipart systems that implement services. I'll try to explain. > > Client-server systems for example have at least two distinct parts with > distinct roles, server(s) and client(s). Service-level interoperability > typically consists of designing and specifying the protocols or interfaces > between them in such a way that any part of the system is interchangeable > with another equivalent part that performs the same role, say from a > different manufacturer, and the system as a whole still continues to work > normally. > > This rarely needs to be honored with a fancy title such as "service level > interoperability" in these days of IETF standards and highly cross-platform > web applications. Historically however, applications did not behave quite > so nicely, and vendors often sought to lock customers in with hidden > proprietary interfaces, so there was a need for adding "service level > interoperability" to the tendering documentation in days gone by, to avoid > surprises later on. > > Today, the need for that has almost disappeared, and if your online service > has a documented protocol interface then "service level interoperability" is > virtually assured without doing anything at all, assuming normal commonsense > has prevailed during development (and there is no deliberate obfuscation of > course). There is only one other area of this topic where a little more > needs to be said. > > Protocol messages can normally be validated syntactically to a strong > degree, and whether a message is correct or not is normally known > immediately upon syntactic validation. Unfortunately, that is not always > the end of the story, because protocols can transport complex data items > which are valid syntactically yet invalid semantically. > > This is the last vestige of where that term is commonly encountered, > as *Service > Level Semantic Interoperability*. Is it relevant to us? Yes, a little. > For example, it would do us no good to transport Collada meshes from an > asset service to a client that tries to render them as some other graphics > format --- that would create a semantic mishap, because one party thinks > that the items means one thing and another party applies a different > semantic. So yes, there is a little more for us to consider here, but it's > not a lot. In most part we have already stated the solution every time that > we have mentioned MIME types for describing content. This is mostly a > solved problem. > > There may be one or two other areas where we have to specify the required > semantic alongside the simple matter of protocol syntax, but that's a > standard part of defining protocols. There is nothing really new here. > > Lastly, service level interoperability focuses entirely on single services > and their clients, so it's unrelated to interoperability between multiple > services, such as a set of virtual world services. This means that, apart > from defining type semantics, it doesn't get us even a step closer towards > interop between virtual worlds. > > > Morgaine. > > > > > > > ========================== > > On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > wrote: > >> Katherine wrote: >> >It seems to me that accomodating "full" interop only would reduce the >> >number of possible implementers and use cases for our work >> >> I am sure that nobody suggested to we restrict ourselves to "full" >> interop only. >> "Service level interop" is clearly subset of VW interoperability. You >> can't have VW interoperability without service level interoperability! >> However, If i understand Morgaine right, she is worried that the VWRAP >> specs will be *restricted* to service level interop only. >> >> It has been argued (sorry, I forgot by whom) that proper >> specifications of service level interop will give us virtual world >> interop for free. I think we need a bit more, but i really have a hard >> time envisioning how service level interop can be specified in such a >> way that it *prevents* VW interop, at least not if we pay attention to >> this aspect, and clearly we do. So in conclusion i do not see much of >> a problem. >> >> Izzy wrote in another tread "This whole argument between service level >> interop and 'full' interop eludes me." At first it eluded me to, but >> now i think that what is actually expressed in these discussions is >> the question of the scope of our effort as well as design approach. >> Some prefer to work bottom up, following their primary interests in >> getting the low level protocols working, especially since that will >> already be good enough for (all?) of their use cases . Some prefer a >> more top-down approach, first sketching the high level picture of the >> users perception of VW interop, and from there working downwards, >> obviously also because that approach optimises the realisation of >> *their* use cases. >> >> I think we need both, and above all, i do feel that the two approaches >> are not al all incompatible and both are without any doubt square >> within the current charter. >> Formally splitting our effort in two working parties along the current >> visible fissures and getting each to work on their own interest is a >> recipe for disaster. It will only strengthen the animosity that is >> already slowing us down tremendously, and will sustain the infighting. >> Rather than spitting efforts off, we need to address the causes for >> the current disagreement and found common ground. In my view that is >> not all all hard. >> >> I have been reviewing the discussion we had in September and i am >> actually amazed at the level of consensus that is expressed in those >> email exchanges. Unfortuanately we have been very bad at consolidating >> that consensus. As a result we recycle the same problems time and time >> again. The archives make very depressing reading from that point of >> view. We need to do more documentation for sure. >> >> I am currently going over the September discussion and looking up the >> places were we all agreed on the way forward. Much of that is still >> undocumented, and my aim is to get those points written down in the >> wiki. >> >> As i final point i want to make clear how I understand the term >> "Service Level Interop". I used the term, and since the glosary entry >> is still emtpy, i feel obliged to add at least my personal reading. If >> somebody disagrees, please add an improved version. >> >> Service level interoperability: >> A subset of "Virtual World Interoperability" as defined by the >> VWRAP >> protocol. Service level interoperabity loosely describes specific >> interactions between VWRAP endpoints. These inteactions form the glue >> that hold a particular virtual world together, but might just as well >> be used for communication between different VWRAP compatible virtual >> worlds (i.e. crossing trust domains). >> >> I intend to put this up in the glossary, but first will see how it >> flies here :) >> >> On 3/29/11, Katherine Mancuso wrote: >> > 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 >> > >> ---------------------------------------------------------------------------------------------- >> > _______________________________________________ >> > 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 >> > From morgaine.dinova@googlemail.com Thu Mar 31 07:58:54 2011 Return-Path: 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 D1D163A67FC for ; Thu, 31 Mar 2011 07:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, 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 DODonowryMcy for ; Thu, 31 Mar 2011 07:58:51 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 936613A6B10 for ; Thu, 31 Mar 2011 07:58:50 -0700 (PDT) Received: by qyk29 with SMTP id 29so3413364qyk.10 for ; Thu, 31 Mar 2011 08:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=b0NpL+kSKCzH85ZUyJfbKJpetYWoCefuatwybSR8nIM=; b=tVLDk7Vwg0SDdKMahpKVaxE4dgvtFc3Mf7r0UdiVP4FjKvTqt5iCKuwGoA7FZRBqWl a2YTYgytx+McutRqepSoesLn2knUWlo4kONgPpneDbM+HGiNmelpSabFLSdWr4KfML0A qW3rU45PMFbLiF7cZP68jd2b6hp1YefUx1fpM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=VFi1RqR2no7BenXDeBf4VWjIwkF8MDeoBZ9umAgEfVAfw7U1nE09cOiElgz+40kgdv VGY33zhn7nDzfRJNwDPUGasL9lsVYvl6Irvnc0oqRU1mZQokhUG3TH60wgpKiMlC2sDW 3MBEpydez0ERzrialbopzFze21xqwGG7L8Qjo= MIME-Version: 1.0 Received: by 10.229.124.145 with SMTP id u17mr2343801qcr.71.1301583628806; Thu, 31 Mar 2011 08:00:28 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Thu, 31 Mar 2011 08:00:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 16:00:28 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd25caed72c8f049fc88db5 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:58:54 -0000 --000e0cd25caed72c8f049fc88db5 Content-Type: text/plain; charset=ISO-8859-1 That sounds interesting, Vaughn. Unfortunately my Firefox browser and Gmail on Linux appear to have a semantic problem with Powerpoint, despite the success of Service Level (Syntactic) Interoperability because it is a recognized type. Is the OGCII material available in any other format? :P Morgaine. ========================== On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca wrote: > Morgaine, > > Thanks a lot for the explanation, i now realise that "service level > interoperability is an existing technical term, and not something > that was manufactured on the fly here in the group...my bad. > > I will update my definition in the glossary a bit, (and use an existing > source). > In the process of doing my homework, and reading up on the topic, i > stumbled over a very interesting piece on the web that i would like > to bring up here for discussion. > > It is a powerpoint presentation with teaching material from the OGCII > (Open Geospatial Consortium Interoperability Institute). Processing > Geospatial data appears to have many problems in common with our > virtual worlds. See: > http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint > download) > > The core idea is simple. A standard intermediate data format, that is > used to match possibly very disparate datasets (like our assets from > different virtual worlds) and some mechanisms to extend this. > > I might have missed this, but it seems to me that this concept has up > till now not figured this explicitly in our thinking. It would be good > if people on this list have a look at this material, if only to point > out that it matches closely to stuff we *did*specify, or alternatively > why it is *not* applicable to our case, and bad idea. However, I > think it is very useful, and could easily be adapted for the VWRAP > problem domain with its many disparate and distributed data sources. > > It anyhow nicely addresses the differences between working service > level interoperability and the semantic mismatch you mentioned. > > --Vaughn > > On 3/31/11, Morgaine wrote: > > Very well put, Vaughn. > > > > Regarding "service level interoperability", it's not really a subset of > VW > > interoperability at all, but lies orthogonal to it because it is a > property > > of all multipart systems that implement services. I'll try to explain. > > > > Client-server systems for example have at least two distinct parts with > > distinct roles, server(s) and client(s). Service-level interoperability > > typically consists of designing and specifying the protocols or > interfaces > > between them in such a way that any part of the system is interchangeable > > with another equivalent part that performs the same role, say from a > > different manufacturer, and the system as a whole still continues to work > > normally. > > > > This rarely needs to be honored with a fancy title such as "service level > > interoperability" in these days of IETF standards and highly > cross-platform > > web applications. Historically however, applications did not behave > quite > > so nicely, and vendors often sought to lock customers in with hidden > > proprietary interfaces, so there was a need for adding "service level > > interoperability" to the tendering documentation in days gone by, to > avoid > > surprises later on. > > > > Today, the need for that has almost disappeared, and if your online > service > > has a documented protocol interface then "service level interoperability" > is > > virtually assured without doing anything at all, assuming normal > commonsense > > has prevailed during development (and there is no deliberate obfuscation > of > > course). There is only one other area of this topic where a little more > > needs to be said. > > > > Protocol messages can normally be validated syntactically to a strong > > degree, and whether a message is correct or not is normally known > > immediately upon syntactic validation. Unfortunately, that is not always > > the end of the story, because protocols can transport complex data items > > which are valid syntactically yet invalid semantically. > > > > This is the last vestige of where that term is commonly encountered, > > as *Service > > Level Semantic Interoperability*. Is it relevant to us? Yes, a little. > > For example, it would do us no good to transport Collada meshes from an > > asset service to a client that tries to render them as some other > graphics > > format --- that would create a semantic mishap, because one party thinks > > that the items means one thing and another party applies a different > > semantic. So yes, there is a little more for us to consider here, but > it's > > not a lot. In most part we have already stated the solution every time > that > > we have mentioned MIME types for describing content. This is mostly a > > solved problem. > > > > There may be one or two other areas where we have to specify the required > > semantic alongside the simple matter of protocol syntax, but that's a > > standard part of defining protocols. There is nothing really new here. > > > > Lastly, service level interoperability focuses entirely on single > services > > and their clients, so it's unrelated to interoperability between multiple > > services, such as a set of virtual world services. This means that, > apart > > from defining type semantics, it doesn't get us even a step closer > towards > > interop between virtual worlds. > > > > > > Morgaine. > > > > > > > > > > > > > > ========================== > > > > On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > > wrote: > > > >> Katherine wrote: > >> >It seems to me that accomodating "full" interop only would reduce the > >> >number of possible implementers and use cases for our work > >> > >> I am sure that nobody suggested to we restrict ourselves to "full" > >> interop only. > >> "Service level interop" is clearly subset of VW interoperability. You > >> can't have VW interoperability without service level interoperability! > >> However, If i understand Morgaine right, she is worried that the VWRAP > >> specs will be *restricted* to service level interop only. > >> > >> It has been argued (sorry, I forgot by whom) that proper > >> specifications of service level interop will give us virtual world > >> interop for free. I think we need a bit more, but i really have a hard > >> time envisioning how service level interop can be specified in such a > >> way that it *prevents* VW interop, at least not if we pay attention to > >> this aspect, and clearly we do. So in conclusion i do not see much of > >> a problem. > >> > >> Izzy wrote in another tread "This whole argument between service level > >> interop and 'full' interop eludes me." At first it eluded me to, but > >> now i think that what is actually expressed in these discussions is > >> the question of the scope of our effort as well as design approach. > >> Some prefer to work bottom up, following their primary interests in > >> getting the low level protocols working, especially since that will > >> already be good enough for (all?) of their use cases . Some prefer a > >> more top-down approach, first sketching the high level picture of the > >> users perception of VW interop, and from there working downwards, > >> obviously also because that approach optimises the realisation of > >> *their* use cases. > >> > >> I think we need both, and above all, i do feel that the two approaches > >> are not al all incompatible and both are without any doubt square > >> within the current charter. > >> Formally splitting our effort in two working parties along the current > >> visible fissures and getting each to work on their own interest is a > >> recipe for disaster. It will only strengthen the animosity that is > >> already slowing us down tremendously, and will sustain the infighting. > >> Rather than spitting efforts off, we need to address the causes for > >> the current disagreement and found common ground. In my view that is > >> not all all hard. > >> > >> I have been reviewing the discussion we had in September and i am > >> actually amazed at the level of consensus that is expressed in those > >> email exchanges. Unfortuanately we have been very bad at consolidating > >> that consensus. As a result we recycle the same problems time and time > >> again. The archives make very depressing reading from that point of > >> view. We need to do more documentation for sure. > >> > >> I am currently going over the September discussion and looking up the > >> places were we all agreed on the way forward. Much of that is still > >> undocumented, and my aim is to get those points written down in the > >> wiki. > >> > >> As i final point i want to make clear how I understand the term > >> "Service Level Interop". I used the term, and since the glosary entry > >> is still emtpy, i feel obliged to add at least my personal reading. If > >> somebody disagrees, please add an improved version. > >> > >> Service level interoperability: > >> A subset of "Virtual World Interoperability" as defined by the > >> VWRAP > >> protocol. Service level interoperabity loosely describes specific > >> interactions between VWRAP endpoints. These inteactions form the glue > >> that hold a particular virtual world together, but might just as well > >> be used for communication between different VWRAP compatible virtual > >> worlds (i.e. crossing trust domains). > >> > >> I intend to put this up in the glossary, but first will see how it > >> flies here :) > >> > >> On 3/29/11, Katherine Mancuso wrote: > >> > 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 > >> > > >> > ---------------------------------------------------------------------------------------------- > >> > _______________________________________________ > >> > 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 > >> > > > --000e0cd25caed72c8f049fc88db5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That sounds interesting, Vaughn.

Unfortunately my Firefox browser an= d Gmail on Linux appear to have a semantic problem with Powerpoint, despite= the success of Service Level (Syntactic) Interoperability because it is a = recognized type.=A0 Is the OGCII material available in any other format?
:P


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca <vaughn.deluca@gmail.com= > wrote:
Morgaine,

Thanks a lot for the explanation, i now realise that "service level interoperability is an existing technical term, and =A0not something
that was manufactured on the fly here in the group...my bad.

I will update my definition in the glossary a bit, (and use an existing sou= rce).
In the process of doing my homework, and reading up on the topic, i
stumbled over a very =A0interesting piece on the web that i would like
to bring up here for discussion.

It is a powerpoint presentation with teaching material from the OGCII
(Open Geospatial Consortium Interoperability Institute). =A0Processing
Geospatial data appears to have many problems in common with our
virtual worlds. See:
http://portal.ogcii.org/files/?artifact_id=3D168 =A0 (warning: powe= rpoint download)

The core idea is simple. A standard intermediate data format, that is
used to match possibly very disparate datasets (like our assets from
different virtual worlds) and some mechanisms to extend this.

I might have missed this, but it seems to me that this concept has up
till now not figured this explicitly in our thinking. It would be good
if people on this list have a look at this material, if only to point
out that it matches closely to stuff we *did*specify, or alternatively
why it is *not* applicable to our case, and bad idea. =A0However, =A0I
think it is very useful, and could easily be adapted for the VWRAP
problem domain with its many disparate and =A0distributed data sources.

It anyhow nicely addresses the differences between working service
level interoperability and the semantic mismatch you mentioned.

--Vaughn

On 3/31/11, Morgaine <= morgaine.dinova@googlemail.com> wrote:
> Very well put, Vaughn.
>
> Regarding "service level interoperability", it's not rea= lly a subset of VW
> interoperability at all, but lies orthogonal to it because it is a pro= perty
> of all multipart systems that implement services. =A0I'll try to e= xplain.
>
> Client-server systems for example have at least two distinct parts wit= h
> distinct roles, server(s) and client(s). =A0Service-level interoperabi= lity
> typically consists of designing and specifying the protocols or interf= aces
> between them in such a way that any part of the system is interchangea= ble
> with another equivalent part that performs the same role, say from a > different manufacturer, and the system as a whole still continues to w= ork
> normally.
>
> This rarely needs to be honored with a fancy title such as "servi= ce level
> interoperability" in these days of IETF standards and highly cros= s-platform
> web applications. =A0Historically however, applications did not behave= quite
> so nicely, and vendors often sought to lock customers in with hidden > proprietary interfaces, so there was a need for adding "service l= evel
> interoperability" to the tendering documentation in days gone by,= to avoid
> surprises later on.
>
> Today, the need for that has almost disappeared, and if your online se= rvice
> has a documented protocol interface then "service level interoper= ability" is
> virtually assured without doing anything at all, assuming normal commo= nsense
> has prevailed during development (and there is no deliberate obfuscati= on of
> course). =A0There is only one other area of this topic where a little = more
> needs to be said.
>
> Protocol messages can normally be validated syntactically to a strong<= br> > degree, and whether a message is correct or not is normally known
> immediately upon syntactic validation. =A0Unfortunately, that is not a= lways
> the end of the story, because protocols can transport complex data ite= ms
> which are valid syntactically yet invalid semantically.
>
> This is the last vestige of where that term is commonly encountered, > as *Service
> Level Semantic Interoperability*. =A0Is it relevant to us? =A0Yes, a l= ittle.
> For example, it would do us no good to transport Collada meshes from a= n
> asset service to a client that tries to render them as some other grap= hics
> format --- that would create a semantic mishap, because one party thin= ks
> that the items means one thing and another party applies a different > semantic. =A0So yes, there is a little more for us to consider here, b= ut it's
> not a lot. =A0In most part we have already stated the solution every t= ime that
> we have mentioned MIME types for describing content. =A0This is mostly= a
> solved problem.
>
> There may be one or two other areas where we have to specify the requi= red
> semantic alongside the simple matter of protocol syntax, but that'= s a
> standard part of defining protocols. =A0There is nothing really new he= re.
>
> Lastly, service level interoperability focuses entirely on single serv= ices
> and their clients, so it's unrelated to interoperability between m= ultiple
> services, such as a set of virtual world services. =A0This means that,= apart
> from defining type semantics, it doesn't get us even a step closer= towards
> interop between virtual worlds.
>
>
> Morgaine.
>
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca
> <vaughn.deluca@gmail.com= >wrote:
>
>> Katherine wrote:
>> >It seems to me that accomodating "full" interop only= would reduce the
>> >number of possible implementers and use cases for our work
>>
>> I am sure that nobody =A0suggested to we restrict ourselves to &qu= ot;full"
>> interop only.
>> "Service level interop" is clearly subset of VW interope= rability. You
>> can't have VW interoperability without service level interoper= ability!
>> However, If i understand Morgaine right, she is worried that the V= WRAP
>> specs will be *restricted* to service level interop only.
>>
>> It has been argued (sorry, I forgot by whom) that proper
>> specifications of service level interop will give us virtual world=
>> interop for free. I think we need a bit more, but i really have a = hard
>> time envisioning how service level interop can be specified in suc= h a
>> way that it *prevents* VW interop, at least not if we pay attentio= n to
>> this aspect, and clearly we do. So in conclusion i do not see much= of
>> a problem.
>>
>> Izzy wrote in another tread "This whole argument between serv= ice level
>> interop and 'full' interop eludes me." At first it el= uded me to, but
>> now i think that what is actually expressed in these discussions i= s
>> the question of the scope of our effort as well as design approach= .
>> Some prefer to work bottom up, following their primary interests i= n
>> getting the low level protocols working, especially since that wil= l
>> already be good enough for (all?) of their use cases . Some prefer= a
>> more top-down approach, first sketching the high level picture of = the
>> users perception of VW interop, =A0and from there working downward= s,
>> obviously also because that approach optimises the realisation of<= br> >> *their* use cases.
>>
>> I think we need both, and above all, i do feel that the two approa= ches
>> are not al all incompatible and both are without any doubt square<= br> >> within the current charter.
>> Formally splitting our effort in two working parties along the cur= rent
>> visible fissures and getting each to work on their own interest is= a
>> recipe for disaster. It will only strengthen the animosity that is=
>> already slowing us down tremendously, and will sustain the infight= ing.
>> Rather than spitting efforts off, we need to address the causes fo= r
>> the current disagreement and found common ground. =A0In my view th= at is
>> not all all hard.
>>
>> I have been reviewing the discussion we had in September and i am<= br> >> actually amazed at the level of consensus that is expressed in tho= se
>> email exchanges. Unfortuanately we have been very bad at consolida= ting
>> that consensus. As a result we recycle the same problems time and = time
>> again. The archives make very depressing reading from that point o= f
>> view. We need to do more documentation for sure.
>>
>> I am currently going over the September discussion and looking up = the
>> places were we all agreed on the way forward. =A0Much of that is s= till
>> undocumented, and my aim is to get those points written down in th= e
>> wiki.
>>
>> As i final point i want to make clear how I understand the term >> "Service Level Interop". I used the term, and since the = glosary entry
>> is still emtpy, i feel obliged to add at least my personal reading= . If
>> somebody disagrees, please add an improved version.
>>
>> Service level interoperability:
>> =A0 =A0 =A0 =A0A subset of "Virtual World Interoperability&qu= ot; as defined by the
>> VWRAP
>> protocol. Service level interoperabity loosely describes specific<= br> >> interactions between VWRAP endpoints. These inteactions form the g= lue
>> that hold a particular virtual world together, but might just as w= ell
>> be used for communication between different VWRAP compatible virtu= al
>> worlds (i.e. crossing trust domains).
>>
>> I intend to put this up in the glossary, but first will see how it=
>> flies here =A0:)
>>
>> On 3/29/11, Katherine Mancuso <kmancuso@gmail.com> wrote:
>> > Hi everyone,
>> >
>> > I want to speak up for agreeing with Meadhbh & Mike about= keeping a
>> > role for service level interop in this group. =A0We've ma= de 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. =A0I'm aware this may not be fully correct in its te= chnical
>> > details, as I am not a software architect:
>> >
>> > Could the partisans of "full" VW interop consider w= orking together on
>> > a draft specification that is something like the intro or Dav= id's
>> > piece in scope that lays out which specific capacities would = need to
>> > be supported at a minimum to allow for "full" inter= op, perhaps getting
>> > input from implementers such as the Hypergrid folks and the f= olks who
>> > coordinated the teleport test at Linden? =A0Citing existing s= ervice
>> > specifications (either ones developed within this WG, or outs= ide
>> > specifications like XML, Collada, etc) is preferred, and for<= br> >> > capabilities for which there are not existing service specifi= cations
>> > or the existing specifications don't work well enough, ad= dress 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 service= s, and
>> > the folks who wish to do "full" interop could defin= e a menu of
>> > services which must be implemented for "full" inter= op. =A0Implementers
>> > could then choose their path based on their use cases: implem= ent the
>> > "full" interop specification including all the spec= ifications called
>> > for, or implement individual services. =A0I 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 requir= e
>> > trashing years of work.
>> >
>> > It seems to me that accomodating "full" interop onl= y would reduce the
>> > number of possible implementers and use cases for our work >> > dramatically, not to mention cut out a productive body of fol= ks in
>> > this group who have been contributing an awful lot of documen= ts 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 g= ardens,
>> > because schools have big legal liability problems with lettin= g minors
>> > wander unwalled virtual worlds (most school libraries in the = US have
>> > internet filters for the same reasons) and have fairly intens= e
>> > supervision requirements which require substantial moderation= &
>> > surveillance tools. =A0However, a shared asset server that co= ntains a
>> > core of "safe" content might be of interest to thes= e folks, since
>> > educators don't necessarily need to reinvent the wheel fo= r their
>> > classrooms every year. =A0This is a really good case for serv= ice level
>> > interop ... implement the asset server specification only, no= t the
>> > "full" one that allows you to teleport to other wor= lds.
>> >
>> > On the other hand, universities have far greater interest in = letting
>> > students and professors teleport among university spaces (whi= ch
>> > happens metaphorically in the real world all the time), and f= ewer
>> > liability issues. =A0Sharing an asset server might be of inte= rest to
>> > them, but so too might "full" interop. =A0They'= d want to implement the
>> > "full" interop specification.
>> >
>> > (Paging Fleep Tuque, are you here to make this case better fo= r 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 domina= te the
>> > group.
>> >
>> > I will be unavailable to post anything else much lengthy thro= ugh 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
>> > ht= tp://facebook.com/kmancuso
>> > http://www.linkedin.com/in/kathymancuso
>> > Second Life: Muse Carmona
>> >
>> ------------------------------------------------------------------= ----------------------------
>> > _______________________________________________
>> > 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
>>
>

--000e0cd25caed72c8f049fc88db5-- From fleep513@gmail.com Thu Mar 31 08:09:23 2011 Return-Path: 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 71CD13A6B62 for ; Thu, 31 Mar 2011 08:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 nP62z6h73VTb for ; Thu, 31 Mar 2011 08:09:22 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EA5FB3A6B5D for ; Thu, 31 Mar 2011 08:09:21 -0700 (PDT) Received: by gxk19 with SMTP id 19so1141297gxk.31 for ; Thu, 31 Mar 2011 08:11:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=CjP8I/3e+RDk/2ZIhHlaq367SmAOWZgNZmjlRRdu0to=; b=WyfVpe0gmhrv+2md8HEKBW1NeCmZrJxs6L2wxEkYo3I23jp3eVo7eU+GCIx+WR7THL /fmD/nGfc3+wLDJYz8PR4pp9qZcEsf4fGtr4Am5c+0bowUf5XsxZXhbZ+rvPbTGM9Zyr Hep2Vl/rpQK8lg+Ca3FlQ0o7n/jy9Livzl25g= 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=rZW5qLD540yGcg3IgH8hLSJN8q+T/NrCkDvqIe9O9OocS/U7p2lirutANBE7hhWBQj 9eprIeWi65A7KXykpNBKRVIKasnDgg0AT30lxVhgVQDV4lTBOEqoAn0UR5edJeZxtS3U mhiXo25ISphn3xdBqm4JIrWjGmXf0oT/wPOkQ= MIME-Version: 1.0 Received: by 10.90.38.7 with SMTP id l7mr3113298agl.133.1301584261324; Thu, 31 Mar 2011 08:11:01 -0700 (PDT) Received: by 10.90.79.19 with HTTP; Thu, 31 Mar 2011 08:11:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 11:11:01 -0400 Message-ID: From: Fleep Tuque To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00163628363a8a9ea4049fc8b305 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:09:23 -0000 --00163628363a8a9ea4049fc8b305 Content-Type: text/plain; charset=ISO-8859-1 The formatting got a little wonky, but I printed the PPT to PDF and uploaded it to google docs. Should be a public document now, try https://docs.google.com/document/pub?id=1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA . - 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 On Thu, Mar 31, 2011 at 11:00 AM, Morgaine wrote: > That sounds interesting, Vaughn. > > Unfortunately my Firefox browser and Gmail on Linux appear to have a > semantic problem with Powerpoint, despite the success of Service Level > (Syntactic) Interoperability because it is a recognized type. Is the OGCII > material available in any other format? > > :P > > > Morgaine. > > > > > ========================== > > > On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca wrote: > It is a powerpoint presentation with teaching material from the OGCII (Open Geospatial Consortium Interoperability Institute). Processing Geospatial data appears to have many problems in common with our virtual worlds. See: http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint download) --00163628363a8a9ea4049fc8b305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The formatting got a little wonky, but I printed the PPT to PDF and uploade= d it to google docs. =A0Should be a public document now, try=A0https://docs.google.com/document/pub?id=3D1WsjarTozebPG8f7HRh_Q= yg9PO6dD603cnUzzLUCRSFA.

- Chris/Fleep

Chris M. Collins (SL:= Fleep Tuque)
Project Manager, UC Second Life=A0
Second= Life Ambassador, Ohio Learning Network=A0
UCit Instructional &am= p; Research Computing
University of Cincinnati=A0
406E Zimmer Hall
PO Bo= x 210088
Cincinnati, OH 45221-0088
(513)556-3018
<= div>chris.collins@uc.edu<= div>
OLN Second Life: http://www.ol= n.org/emerging_technologies/emtech.php



On Thu, Mar 31, 2011= at 11:00 AM, Morgaine <morgaine.dinova@googlemail.com> wrote:
That sounds interesting, Vaughn.

Unfortunately my Firefox browser an= d Gmail on Linux appear to have a semantic problem with Powerpoint, despite= the success of Service Level (Syntactic) Interoperability because it is a = recognized type.=A0 Is the OGCII material available in any other format?
:P


Morgaine.




=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca <vaughn.deluca@gmail= .com> wrote:
=A0
It is a powerpoint presentation with= teaching material from the OGCII
(Open Geospatial Consortium Interopera= bility Institute). =A0Processing
Geospatial data appears to have many pr= oblems in common with our
virtual worlds. See:
http://portal.ogcii.org/files/?artifact_id= =3D168=A0=A0 (warning: powerpoint download)=A0

--00163628363a8a9ea4049fc8b305-- From ohmeadhbh@gmail.com Thu Mar 31 08:19:24 2011 Return-Path: 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 32D533A6B0E for ; Thu, 31 Mar 2011 08:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 qZuijUb8Astc for ; Thu, 31 Mar 2011 08:19:22 -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 C6CBE3A6AD7 for ; Thu, 31 Mar 2011 08:19:21 -0700 (PDT) Received: by iye19 with SMTP id 19so2897892iye.31 for ; Thu, 31 Mar 2011 08:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=DlCqKmK97p0523e6wqNwRQe9G0/qqqc4ugqyc1/CQjg=; b=hxMDm/9mnsUYycgklqG0KBLzkerOhDshbfExih0hTVRXKqRXIjT36vGKCZJhIRWHr4 6dXse/hy7cCU2p2gtvJL6qINnoQrmEsq/3OJF97BN9ZepvqoA46afARUtC63J37pAj8v fLmz7tKE9efQx5SDjpOr0Qg8fi65yrFlDfBso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=BZydaVonZ4X+EvvAvRGiOJIr0vtnZHrz0Zyx5h1sTJ9u2+DI+GVqJbAsMfUB+agrDS SKqkz2HYpZYi7ckXAn8YtN6Yz1WfCgRbGY8Tp02GOc2um/+oLdngQx2KsuzuXKnHGN7m CGnHE6f2zmL9baFFlXhyLN3Hcu1H0FDRmfUbE= Received: by 10.43.52.195 with SMTP id vn3mr3481859icb.272.1301584861093; Thu, 31 Mar 2011 08:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.225.199 with HTTP; Thu, 31 Mar 2011 08:20:40 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Thu, 31 Mar 2011 08:20:40 -0700 Message-ID: To: Vaughn Deluca Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:19:24 -0000 fwiw... in terms of data formats, a couple years ago, this group was indicating we wanted to re-use existing formats as much as possible. Assets were to be COLLADA objects, textures were to be JPEGs or PNGs, audio files were to be MP3, WAV, AU or whatever. group chat, when it was considered "in scope" for this initiative, was hoped tobe IRC or XMPP. LLSD based services were supposed to provide the "glue" that held them together or to define things we couldn't find existing services for. A typical example might be... you use an LLSD over HTTPS service to authenticate to a auth service. Some magic happens and your client is given a URL on a target region / simulator system the client can use to retrieve the scene graph. Maybe that scene graph was represented as X3D/VRML (though some of us had some issues with X3D) and objects in the world were represented as URLs to COLLADA objects. it sounds philosophically similar to what you describe above, but probably different in execution. but the core idea is the same: "use existing standards where they apply, build new things only when an existing standard doesn't apply and use new things as 'glue' to glue things together." -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Thu, Mar 31, 2011 at 7:34 AM, Vaughn Deluca wr= ote: > Morgaine, > > Thanks a lot for the explanation, i now realise that "service level > interoperability is an existing technical term, and =A0not something > that was manufactured on the fly here in the group...my bad. > > I will update my definition in the glossary a bit, (and use an existing s= ource). > In the process of doing my homework, and reading up on the topic, i > stumbled over a very =A0interesting piece on the web that i would like > to bring up here for discussion. > > It is a powerpoint presentation with teaching material from the OGCII > (Open Geospatial Consortium Interoperability Institute). =A0Processing > Geospatial data appears to have many problems in common with our > virtual worlds. See: > http://portal.ogcii.org/files/?artifact_id=3D168 =A0 (warning: powerpoint= download) > > The core idea is simple. A standard intermediate data format, that is > used to match possibly very disparate datasets (like our assets from > different virtual worlds) and some mechanisms to extend this. > > I might have missed this, but it seems to me that this concept has up > till now not figured this explicitly in our thinking. It would be good > if people on this list have a look at this material, if only to point > out that it matches closely to stuff we *did*specify, or alternatively > why it is *not* applicable to our case, and bad idea. =A0However, =A0I > think it is very useful, and could easily be adapted for the VWRAP > problem domain with its many disparate and =A0distributed data sources. > > It anyhow nicely addresses the differences between working service > level interoperability and the semantic mismatch you mentioned. > > --Vaughn > > On 3/31/11, Morgaine wrote: >> Very well put, Vaughn. >> >> Regarding "service level interoperability", it's not really a subset of = VW >> interoperability at all, but lies orthogonal to it because it is a prope= rty >> of all multipart systems that implement services. =A0I'll try to explain= . >> >> Client-server systems for example have at least two distinct parts with >> distinct roles, server(s) and client(s). =A0Service-level interoperabili= ty >> typically consists of designing and specifying the protocols or interfac= es >> between them in such a way that any part of the system is interchangeabl= e >> with another equivalent part that performs the same role, say from a >> different manufacturer, and the system as a whole still continues to wor= k >> normally. >> >> This rarely needs to be honored with a fancy title such as "service leve= l >> interoperability" in these days of IETF standards and highly cross-platf= orm >> web applications. =A0Historically however, applications did not behave q= uite >> so nicely, and vendors often sought to lock customers in with hidden >> proprietary interfaces, so there was a need for adding "service level >> interoperability" to the tendering documentation in days gone by, to avo= id >> surprises later on. >> >> Today, the need for that has almost disappeared, and if your online serv= ice >> has a documented protocol interface then "service level interoperability= " is >> virtually assured without doing anything at all, assuming normal commons= ense >> has prevailed during development (and there is no deliberate obfuscation= of >> course). =A0There is only one other area of this topic where a little mo= re >> needs to be said. >> >> Protocol messages can normally be validated syntactically to a strong >> degree, and whether a message is correct or not is normally known >> immediately upon syntactic validation. =A0Unfortunately, that is not alw= ays >> the end of the story, because protocols can transport complex data items >> which are valid syntactically yet invalid semantically. >> >> This is the last vestige of where that term is commonly encountered, >> as *Service >> Level Semantic Interoperability*. =A0Is it relevant to us? =A0Yes, a lit= tle. >> For example, it would do us no good to transport Collada meshes from an >> asset service to a client that tries to render them as some other graphi= cs >> format --- that would create a semantic mishap, because one party thinks >> that the items means one thing and another party applies a different >> semantic. =A0So yes, there is a little more for us to consider here, but= it's >> not a lot. =A0In most part we have already stated the solution every tim= e that >> we have mentioned MIME types for describing content. =A0This is mostly a >> solved problem. >> >> There may be one or two other areas where we have to specify the require= d >> semantic alongside the simple matter of protocol syntax, but that's a >> standard part of defining protocols. =A0There is nothing really new here= . >> >> Lastly, service level interoperability focuses entirely on single servic= es >> and their clients, so it's unrelated to interoperability between multipl= e >> services, such as a set of virtual world services. =A0This means that, a= part >> from defining type semantics, it doesn't get us even a step closer towar= ds >> interop between virtual worlds. >> >> >> Morgaine. >> >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> >> On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca >> wrote: >> >>> Katherine wrote: >>> >It seems to me that accomodating "full" interop only would reduce the >>> >number of possible implementers and use cases for our work >>> >>> I am sure that nobody =A0suggested to we restrict ourselves to "full" >>> interop only. >>> "Service level interop" is clearly subset of VW interoperability. You >>> can't have VW interoperability without service level interoperability! >>> However, If i understand Morgaine right, she is worried that the VWRAP >>> specs will be *restricted* to service level interop only. >>> >>> It has been argued (sorry, I forgot by whom) that proper >>> specifications of service level interop will give us virtual world >>> interop for free. I think we need a bit more, but i really have a hard >>> time envisioning how service level interop can be specified in such a >>> way that it *prevents* VW interop, at least not if we pay attention to >>> this aspect, and clearly we do. So in conclusion i do not see much of >>> a problem. >>> >>> Izzy wrote in another tread "This whole argument between service level >>> interop and 'full' interop eludes me." At first it eluded me to, but >>> now i think that what is actually expressed in these discussions is >>> the question of the scope of our effort as well as design approach. >>> Some prefer to work bottom up, following their primary interests in >>> getting the low level protocols working, especially since that will >>> already be good enough for (all?) of their use cases . Some prefer a >>> more top-down approach, first sketching the high level picture of the >>> users perception of VW interop, =A0and from there working downwards, >>> obviously also because that approach optimises the realisation of >>> *their* use cases. >>> >>> I think we need both, and above all, i do feel that the two approaches >>> are not al all incompatible and both are without any doubt square >>> within the current charter. >>> Formally splitting our effort in two working parties along the current >>> visible fissures and getting each to work on their own interest is a >>> recipe for disaster. It will only strengthen the animosity that is >>> already slowing us down tremendously, and will sustain the infighting. >>> Rather than spitting efforts off, we need to address the causes for >>> the current disagreement and found common ground. =A0In my view that is >>> not all all hard. >>> >>> I have been reviewing the discussion we had in September and i am >>> actually amazed at the level of consensus that is expressed in those >>> email exchanges. Unfortuanately we have been very bad at consolidating >>> that consensus. As a result we recycle the same problems time and time >>> again. The archives make very depressing reading from that point of >>> view. We need to do more documentation for sure. >>> >>> I am currently going over the September discussion and looking up the >>> places were we all agreed on the way forward. =A0Much of that is still >>> undocumented, and my aim is to get those points written down in the >>> wiki. >>> >>> As i final point i want to make clear how I understand the term >>> "Service Level Interop". I used the term, and since the glosary entry >>> is still emtpy, i feel obliged to add at least my personal reading. If >>> somebody disagrees, please add an improved version. >>> >>> Service level interoperability: >>> =A0 =A0 =A0 =A0A subset of "Virtual World Interoperability" as defined = by the >>> VWRAP >>> protocol. Service level interoperabity loosely describes specific >>> interactions between VWRAP endpoints. These inteactions form the glue >>> that hold a particular virtual world together, but might just as well >>> be used for communication between different VWRAP compatible virtual >>> worlds (i.e. crossing trust domains). >>> >>> I intend to put this up in the glossary, but first will see how it >>> flies here =A0:) >>> >>> On 3/29/11, Katherine Mancuso wrote: >>> > Hi everyone, >>> > >>> > I want to speak up for agreeing with Meadhbh & Mike about keeping a >>> > role for service level interop in this group. =A0We'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. =A0I'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 gettin= g >>> > input from implementers such as the Hypergrid folks and the folks who >>> > coordinated the teleport test at Linden? =A0Citing 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 t= o >>> > 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. =A0Implementer= s >>> > 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. =A0I believe that both of thes= e >>> > 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. =A0However, 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. =A0This is a really good case for service leve= l >>> > 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. =A0Sharing an asset server might be of interest to >>> > them, but so too might "full" interop. =A0They'd want to implement th= e >>> > "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 >>> > >>> -----------------------------------------------------------------------= ----------------------- >>> > _______________________________________________ >>> > 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 mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From dzonatas@gmail.com Thu Mar 31 08:19:49 2011 Return-Path: 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 4226F3A6B24 for ; Thu, 31 Mar 2011 08:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 E3UlLp7874yW for ; Thu, 31 Mar 2011 08:19:47 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C40A73A6AD7 for ; Thu, 31 Mar 2011 08:19:47 -0700 (PDT) Received: by iwn39 with SMTP id 39so2891520iwn.31 for ; Thu, 31 Mar 2011 08:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9jgLBDYGca6EqOIhb4/Wmz6cyh2ErEBJHQN9AcU0KYg=; b=BSSnyncCdfYA6ztHScCXgD5RUQXCGcWc1+C9Jx15xJxu2tGBnKcux249EoMvo4SuYW WNpw7Zrzb5KC0uyshfLPtRX45rbrz7IM9WCUz1xaCV+y4Zb4hjJ68sMWJ25ZhmcLSlxb WKkKaOQLfwGPEUiTtGS/Gmqhc+G+ViYYFbejM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PTQGAcga+PSQivLkJzdqkN+MXeg5ELBLwNBxdUuoUP+RJVA0mQ8vhnGVAVzFEniyNA eRN012rvBiFg0Dc9sl8QH+x72n3IuiZAABrLGE0ptd+B3k7/5ui9X2BeJ5lQ6itihusS iAjSJSNBxExpvL0tgOPxMARZc2Br85iOdZaws= Received: by 10.43.57.131 with SMTP id wg3mr2026299icb.299.1301584887252; Thu, 31 Mar 2011 08:21:27 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id uf10sm684555icb.17.2011.03.31.08.21.23 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 08:21:23 -0700 (PDT) Message-ID: <4D949BFB.1010804@gmail.com> Date: Thu, 31 Mar 2011 08:21:31 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Morgaine References: <4D93E82C.7060503@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: vwrap@ietf.org Subject: Re: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:19:49 -0000 Don't need to assume too much like that, Morgaine; however, we need something more of "trust domains" defined and the example(s) I wrote about fit in well as lead-in. I stated these use-cases specially to avoid the use of terminology that now exists, and this leans towards the need to center on "trust domains." I see the use of current client/server-* terminology continually to confuse us (even if some like it, not all do). If we have to think about such terminology for more than 90 seconds each time then it needs to change. My side-point was that VWs may have their own object format in their world, and I'm thinking more then just the regions that exist now that the monolithic client connects. Perhaps, others only think about SL compatible grids, and don't worry about the default format. Morgaine wrote: > We've maintained throughout that our protocols would be extensible > with regard to data formats, allowing worlds and user expectations to > evolve without requiring protocol redefinition. > > In the area of meshes, it is very much to be expected that COLLADA > will figure strongly among the graphic formats used (particularly > since it was chosen for the iED initiative), but it's not of any > special interest to the VWRAP protocols other than as a potential > content type.� All we have to do is to make sure that we label each > transfer with its appropriate type, and possibly also include other > metadata that may be needed. > > We're certainly not standardizing what graphics are used in virtual > worlds, beyond assigning types where they might not yet exist.� > Hardwiring them would be a recipe not for extensibility but for > stagnation.� Other bodies may be standardizing which graphics formats > are used, whereas we're trying to define useful deployment > architectures and standardizing the protocols through which they are > accessed. > > > Morgaine. > > > > > =================== > > On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol > wrote: > > If we say the conditioner basically authenticates or re-signs an > asset from grid X to grid Y, and the refinery would make sure the > physics of the object described by the asset is translated from > the topology of grid X to the topology of grid Y, then this is > basically what COLLADA expects in exchange. This exchange is this > different from the usual import/export process. It doesn't have to > be this exact process, as this is only an example to us be more > familiar. > > It seems a complete waste to not realize that LL has implemented > the import process and physics refinery into their browser, and > this very feature, though not fully automated as such, could be > used to help move assets in-between grids/v-worlds. Since the > import is from local basis, the authentication is not implemented. > What's to stop to basically export to DAE format on the local > storage, from one world, and continue to import that DAE into > another grid. > > Note that the refineries may be proprietary. They may produce > non-COLLADA formats (from DAE files) that are for optimal > render/display capability of the software "client" (i.e. that the > end-user has to view graphics). > > As with Google Earth and Sony HOME, they already have their assets > conditioned and refined for those virtual worlds such that they > can optimally display them. The key note is not the optimal > display, as it is about being able to exchange and use in other > virtual worlds. > > The DAE format does have extensive abilities, yet the goal of > COLLADA is still to define the basic material, scripts, model, etc > in the most portable format. The DAE may contain hybrid or > specific formats that is stored in the extensions, so that custom > objects are retained/transferred. > > If virtual worlds start to not agree upon how they store objects, > I see COLLADA as the default format for digital asset exchange. > > https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F > > (Yes, we can put all inventory items in DAE format through the > user-data and asset extensions, despite the format mainly being > for 3D... just sayin') > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > _______________________________________________ > 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 > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From vaughn.deluca@gmail.com Thu Mar 31 08:31:11 2011 Return-Path: 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 112533A6B33 for ; Thu, 31 Mar 2011 08:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 vAEthZRFjyUY for ; Thu, 31 Mar 2011 08:31:10 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id AD57C3A6983 for ; Thu, 31 Mar 2011 08:31:09 -0700 (PDT) Received: by ewy19 with SMTP id 19so889002ewy.31 for ; Thu, 31 Mar 2011 08:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YTSjzl0PKPRJ6nXwsjAhYGGXre6FQP3opdbSGCvc+RM=; b=Qtdg2Exn9CiIwvJ7xZ5e0meyDmB3whTW0Q1QVz7NTokwkH/wlccpNsj94gUaLxQrnW cNEX01lUOocgX2YYwVNptY+MH4NFXH5dMDVAX1qqp/d3T1T+7f1kzhr/HY3n9Q8wUAh5 BakU3ClJ0doBBnIUYZN6o4Yo2j+MiY5q/5vb8= 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 :cc:content-type; b=ehcU74arhfR+8Jw/ziOI5Q/igl4OqRhLEZu3MiEVxef7DBbVrFqs6e0o7vFWfVWmxd k3ewZMyntMGO79gygleSC5CpENyePr04gqXmqNhLkoI6rK8FfUk3IoGMKjnN8E9hd1f/ x9czKsSeQK3uH+bDyGLsVlJ9FlpAqUAv8txw0= MIME-Version: 1.0 Received: by 10.213.26.152 with SMTP id e24mr1699003ebc.125.1301585568781; Thu, 31 Mar 2011 08:32:48 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Thu, 31 Mar 2011 08:32:48 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 17:32:48 +0200 Message-ID: From: Vaughn Deluca To: Fleep Tuque Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:31:11 -0000 Thanks for that upload, but it stops working for me after slide 9, and the interesting bits are starting at 17... Let me see if i can make a pdf out of the presentation. brb. On 3/31/11, Fleep Tuque wrote: > The formatting got a little wonky, but I printed the PPT to PDF and uploaded > it to google docs. Should be a public document now, try > https://docs.google.com/document/pub?id=1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA > . > > - 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 > > > > On Thu, Mar 31, 2011 at 11:00 AM, Morgaine > wrote: > >> That sounds interesting, Vaughn. >> >> Unfortunately my Firefox browser and Gmail on Linux appear to have a >> semantic problem with Powerpoint, despite the success of Service Level >> (Syntactic) Interoperability because it is a recognized type. Is the >> OGCII >> material available in any other format? >> >> :P >> >> >> Morgaine. >> >> >> >> >> ========================== >> >> >> On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca >> wrote: >> > > It is a powerpoint presentation with teaching material from the OGCII > (Open Geospatial Consortium Interoperability Institute). Processing > Geospatial data appears to have many problems in common with our > virtual worlds. See: > http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint > download) > From vaughn.deluca@gmail.com Thu Mar 31 08:41:33 2011 Return-Path: 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 1482E3A694C for ; Thu, 31 Mar 2011 08:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 bB3i06ScUupn for ; Thu, 31 Mar 2011 08:41:31 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 84E053A6844 for ; Thu, 31 Mar 2011 08:41:31 -0700 (PDT) Received: by ewy19 with SMTP id 19so893364ewy.31 for ; Thu, 31 Mar 2011 08:43:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=JJIhDafqwY/1Fo85ZMcyEJXLiaFQ9OUH4WG9iy5b2e4=; b=PTrZRNw4i/KXK+WCWqAFcT4J5oJMhtlcgBMlyjBYisXYjLMn5wQValrUKoV8pnXA93 VP1EEcfWWoP9wAy092wop9m9VqURX7oStVAqHL94Y3UreYsGOr8qa+4k3ObT1DOawfxU 2NKTBgo5OtHH4R1zNaC3JYkFL72F+ifiZnLRw= 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 :cc:content-type; b=pfALk3oUH4MkX5DUMrwgv6fzrLjpozzRDsadYr4D1dfFZToOwCpBHUzHcTmoUl0+y5 sagzb327BuXJ4+ZqUJjv/LlTVAIlBdVhcQqUddp1kbP5vyOOvedbzuK1wH5hAa2xao4D +psYlft3WRYSzlagCp52maEJlgthOQOr3LGk4= MIME-Version: 1.0 Received: by 10.213.14.203 with SMTP id h11mr1687398eba.87.1301586189407; Thu, 31 Mar 2011 08:43:09 -0700 (PDT) Received: by 10.213.17.17 with HTTP; Thu, 31 Mar 2011 08:43:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 17:43:09 +0200 Message-ID: From: Vaughn Deluca To: Fleep Tuque Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:41:33 -0000 I am not sure if i am allowed to upload this to the VWRAP wiki, for now put it here: http://ddscripting.net/Module_1_-_Overview.pdf On 3/31/11, Vaughn Deluca wrote: > Thanks for that upload, but it stops working for me after slide 9, and > the interesting bits are starting at 17... Let me see if i can make a > pdf out of the presentation. > brb. > > On 3/31/11, Fleep Tuque wrote: >> The formatting got a little wonky, but I printed the PPT to PDF and >> uploaded >> it to google docs. Should be a public document now, try >> https://docs.google.com/document/pub?id=1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA >> . >> >> - 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 >> >> >> >> On Thu, Mar 31, 2011 at 11:00 AM, Morgaine >> wrote: >> >>> That sounds interesting, Vaughn. >>> >>> Unfortunately my Firefox browser and Gmail on Linux appear to have a >>> semantic problem with Powerpoint, despite the success of Service Level >>> (Syntactic) Interoperability because it is a recognized type. Is the >>> OGCII >>> material available in any other format? >>> >>> :P >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> ========================== >>> >>> >>> On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca >>> wrote: >>> >> >> It is a powerpoint presentation with teaching material from the OGCII >> (Open Geospatial Consortium Interoperability Institute). Processing >> Geospatial data appears to have many problems in common with our >> virtual worlds. See: >> http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint >> download) >> > From morgaine.dinova@googlemail.com Thu Mar 31 09:21:23 2011 Return-Path: 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 9D12A3A6932 for ; Thu, 31 Mar 2011 09:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 rY1f48WyE1fb for ; Thu, 31 Mar 2011 09:21:21 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 570563A684E for ; Thu, 31 Mar 2011 09:21:21 -0700 (PDT) Received: by qyk29 with SMTP id 29so3483916qyk.10 for ; Thu, 31 Mar 2011 09:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=2NQ1PZ9YivR6O8HYJMXItAx0YTo+FSi/bc+2LmQH1Z8=; b=nCjGE4A+IGZPj5dV92qoEhvPPRah4aIl2LSJ40uikfsQhZL4397WJCVTUMVfO27XaI ws83pzFwXjKZ7BS2uZpqXgnZ89d/Qe8+SMETIOKdlBD4KwDKdV4vbFq4eaahXRWvjkAq 6k34xE3ai/4Y4zSjALyvNDqMSK0625UI535JY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=QQ+o5WI9LYCBkiI1bfIXdllhtO7SbKDESh26B1AW9dr5x1aID47vrXdNVhDVlHDN91 LeO9GYbG51mxE9QfwCQYlM0kf6PTYcTP9vzKcAx9Vir3fsqnHeibUJQHvbBQDc+EeiKu 6UW+c9k0wDfrTJpw0EPGt+DIcj/C6v1MMErXw= MIME-Version: 1.0 Received: by 10.229.78.228 with SMTP id m36mr2409595qck.109.1301588580408; Thu, 31 Mar 2011 09:23:00 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Thu, 31 Mar 2011 09:23:00 -0700 (PDT) In-Reply-To: <4D949BFB.1010804@gmail.com> References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> Date: Thu, 31 Mar 2011 17:23:00 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00235429d356faa22c049fc9b4ad Subject: Re: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:21:23 -0000 --00235429d356faa22c049fc9b4ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is no default format, and nowhere does VWRAP deal in SL-compatible grids. We are defining a services-oriented architecture which is nothing like that of today's SL, and we cannot for a moment assume that SL will adopt it in the future, as that is their choice, not ours. The only partly-compatible VW frameworks over which we have a small amount of influence are Opensim and realXtend (which uses Opensim server-side), because we can take their open source code and adapt it to our protocols if we wish. In that sense, we could be said to be defining an Opensim-compatible protocol, but never an SL-compatible protocol. That would be a misapprehension. We occasionally say that we are defining an SL-like *data* architecture, bu= t even that isn't really correct since VWRAP doesn't favor one in-world content type over another. All content types are denoted merely by a type tag and there is no standard set of content types required. So what is the real commonality between VWRAP and SL? Currently, only LLSD is reasonably compatible with SL, although LLSD might well change in more than just its name if we find the current spec not sufficiently powerful or lacking extensibility for our needs. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol wrote: > Don't need to assume too much like that, Morgaine; however, we need > something more of "trust domains" defined and the example(s) I wrote abou= t > fit in well as lead-in. I stated these use-cases specially to avoid the u= se > of terminology that now exists, and this leans towards the need to center= on > "trust domains." I see the use of current client/server-* terminology > continually to confuse us (even if some like it, not all do). If we have = to > think about such terminology for more than 90 seconds each time then it > needs to change. > > My side-point was that VWs may have their own object format in their worl= d, > and I'm thinking more then just the regions that exist now that the > monolithic client connects. Perhaps, others only think about SL compatibl= e > grids, and don't worry about the default format. > > Morgaine wrote: > >> We've maintained throughout that our protocols would be extensible with >> regard to data formats, allowing worlds and user expectations to evolve >> without requiring protocol redefinition. >> >> In the area of meshes, it is very much to be expected that COLLADA will >> figure strongly among the graphic formats used (particularly since it wa= s >> chosen for the iED initiative), but it's not of any special interest to = the >> VWRAP protocols other than as a potential content type.=EF=BF=BD All we = have to do >> is to make sure that we label each transfer with its appropriate type, a= nd >> possibly also include other metadata that may be needed. >> >> We're certainly not standardizing what graphics are used in virtual >> worlds, beyond assigning types where they might not yet exist.=EF=BF=BD = Hardwiring >> them would be a recipe not for extensibility but for stagnation.=EF=BF= =BD Other >> bodies may be standardizing which graphics formats are used, whereas we'= re >> trying to define useful deployment architectures and standardizing the >> protocols through which they are accessed. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol > dzonatas@gmail.com>> wrote: >> >> If we say the conditioner basically authenticates or re-signs an >> asset from grid X to grid Y, and the refinery would make sure the >> physics of the object described by the asset is translated from >> the topology of grid X to the topology of grid Y, then this is >> basically what COLLADA expects in exchange. This exchange is this >> different from the usual import/export process. It doesn't have to >> be this exact process, as this is only an example to us be more >> familiar. >> >> It seems a complete waste to not realize that LL has implemented >> the import process and physics refinery into their browser, and >> this very feature, though not fully automated as such, could be >> used to help move assets in-between grids/v-worlds. Since the >> import is from local basis, the authentication is not implemented. >> What's to stop to basically export to DAE format on the local >> storage, from one world, and continue to import that DAE into >> another grid. >> >> Note that the refineries may be proprietary. They may produce >> non-COLLADA formats (from DAE files) that are for optimal >> render/display capability of the software "client" (i.e. that the >> end-user has to view graphics). >> >> As with Google Earth and Sony HOME, they already have their assets >> conditioned and refined for those virtual worlds such that they >> can optimally display them. The key note is not the optimal >> display, as it is about being able to exchange and use in other >> virtual worlds. >> >> The DAE format does have extensive abilities, yet the goal of >> COLLADA is still to define the basic material, scripts, model, etc >> in the most portable format. The DAE may contain hybrid or >> specific formats that is stored in the extensions, so that custom >> objects are retained/transferred. >> >> If virtual worlds start to not agree upon how they store objects, >> I see COLLADA as the default format for digital asset exchange. >> >> >> https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_f= eatures_of_this_format.3F >> >> (Yes, we can put all inventory items in DAE format through the >> user-data and asset extensions, despite the format mainly being >> for 3D... just sayin') >> >> -- --- https://twitter.com/Dzonatas_Sol --- >> Web Development, Software Engineering, Virtual Reality, Consultant >> >> _______________________________________________ >> 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 >> >> > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > --00235429d356faa22c049fc9b4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable There is no default format, and nowhere does VWRAP deal in SL-compatible gr= ids.

We are defining a services-oriented architecture which is nothi= ng like that of today's SL, and we cannot for a moment assume that SL w= ill adopt it in the future, as that is their choice, not ours.

The only partly-compatible VW frameworks over which we have a small amo= unt of influence are Opensim and realXtend (which uses Opensim server-side)= , because we can take their open source code and adapt it to our protocols = if we wish.=C2=A0 In that sense, we could be said to be defining an Opensim= -compatible protocol, but never an SL-compatible protocol.=C2=A0 That would= be a misapprehension.

We occasionally say that we are defining an SL-like data = architecture, but even that isn't really correct since VWRAP doesn'= t favor one in-world content type over another.=C2=A0 All content types are= denoted merely by a type tag and there is no standard set of content types= required.

So what is the real commonality between VWRAP and SL?=C2=A0 Currently, = only LLSD is reasonably compatible with SL, although LLSD might well change= in more than just its name if we find the current spec not sufficiently po= werful or lacking extensibility for our needs.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol <dzonatas@gmail.com> wrote:
Don't need to= assume too much like that, Morgaine; however, we need something more of &q= uot;trust domains" defined and the example(s) I wrote about fit in wel= l as lead-in. I stated these use-cases specially to avoid the use of termin= ology that now exists, and this leans towards the need to center on "t= rust domains." I see the use of current client/server-* terminology co= ntinually to confuse us (even if some like it, not all do). If we have to t= hink about such terminology for more than 90 seconds each time then it need= s to change.

My side-point was that VWs may have their own object format in their world,= and I'm thinking more then just the regions that exist now that the mo= nolithic client connects. Perhaps, others only think about SL compatible gr= ids, and don't worry about the default format.

Morgaine wrote:
We've maintained throughout that our protocols would be extensible with= regard to data formats, allowing worlds and user expectations to evolve wi= thout requiring protocol redefinition.

In the area of meshes, it is very much to be expected that COLLADA will fig= ure strongly among the graphic formats used (particularly since it was chos= en for the iED initiative), but it's not of any special interest to the= VWRAP protocols other than as a potential content type.=EF=BF=BD All we ha= ve to do is to make sure that we label each transfer with its appropriate t= ype, and possibly also include other metadata that may be needed.

We're certainly not standardizing what graphics are used in virtual wor= lds, beyond assigning types where they might not yet exist.=EF=BF=BD Hardwi= ring them would be a recipe not for extensibility but for stagnation.=EF=BF= =BD Other bodies may be standardizing which graphics formats are used, wher= eas we're trying to define useful deployment architectures and standard= izing the protocols through which they are accessed.


Morgaine.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>= ; wrote:

=C2=A0 =C2=A0If we say the conditioner basically authenticates or re-signs= an
=C2=A0 =C2=A0asset from grid X to grid Y, and the refinery would make sure= the
=C2=A0 =C2=A0physics of the object described by the asset is translated fr= om
=C2=A0 =C2=A0the topology of grid X to the topology of grid Y, then this i= s
=C2=A0 =C2=A0basically what COLLADA expects in exchange. This exchange is = this
=C2=A0 =C2=A0different from the usual import/export process. It doesn'= t have to
=C2=A0 =C2=A0be this exact process, as this is only an example to us be mo= re
=C2=A0 =C2=A0familiar.

=C2=A0 =C2=A0It seems a complete waste to not realize that LL has implemen= ted
=C2=A0 =C2=A0the import process and physics refinery into their browser, a= nd
=C2=A0 =C2=A0this very feature, though not fully automated as such, could = be
=C2=A0 =C2=A0used to help move assets in-between grids/v-worlds. Since the=
=C2=A0 =C2=A0import is from local basis, the authentication is not impleme= nted.
=C2=A0 =C2=A0What's to stop to basically export to DAE format on the l= ocal
=C2=A0 =C2=A0storage, from one world, and continue to import that DAE into=
=C2=A0 =C2=A0another grid.

=C2=A0 =C2=A0Note that the refineries may be proprietary. They may produce=
=C2=A0 =C2=A0non-COLLADA formats (from DAE files) that are for optimal
=C2=A0 =C2=A0render/display capability of the software "client" = (i.e. that the
=C2=A0 =C2=A0end-user has to view graphics).

=C2=A0 =C2=A0As with Google Earth and Sony HOME, they already have their a= ssets
=C2=A0 =C2=A0conditioned and refined for those virtual worlds such that th= ey
=C2=A0 =C2=A0can optimally display them. The key note is not the optimal =C2=A0 =C2=A0display, as it is about being able to exchange and use in oth= er
=C2=A0 =C2=A0virtual worlds.

=C2=A0 =C2=A0The DAE format does have extensive abilities, yet the goal of=
=C2=A0 =C2=A0COLLADA is still to define the basic material, scripts, model= , etc
=C2=A0 =C2=A0in the most portable format. The DAE may contain hybrid or =C2=A0 =C2=A0specific formats that is stored in the extensions, so that cu= stom
=C2=A0 =C2=A0objects are retained/transferred.

=C2=A0 =C2=A0If virtual worlds start to not agree upon how they store obje= cts,
=C2=A0 =C2=A0I see COLLADA as the default format for digital asset exchang= e.

=C2=A0 =C2=A0https://= collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_= this_format.3F

=C2=A0 =C2=A0(Yes, we can put all inventory items in DAE format through th= e
=C2=A0 =C2=A0user-data and asset extensions, despite the format mainly bei= ng
=C2=A0 =C2=A0for 3D... just sayin')

=C2=A0 =C2=A0-- =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
=C2=A0 =C2=A0Web Development, Software Engineering, Virtual Reality, Consu= ltant

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0vwrap mailing list
=C2=A0 =C2=A0vwrap@iet= f.org <mailto:vw= rap@ietf.org>

=C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/vwrap


------------------------------------------------------------------------

_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap
=C2=A0


--
--- https://= twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant


--00235429d356faa22c049fc9b4ad-- From morgaine.dinova@googlemail.com Thu Mar 31 09:27:05 2011 Return-Path: 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 B5C6528C124 for ; Thu, 31 Mar 2011 09:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.865 X-Spam-Level: X-Spam-Status: No, score=-2.865 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 rGxV4zHSILmU for ; Thu, 31 Mar 2011 09:27:04 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 265A128C102 for ; Thu, 31 Mar 2011 09:27:04 -0700 (PDT) Received: by qyk7 with SMTP id 7so1742025qyk.10 for ; Thu, 31 Mar 2011 09:28:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=dOWtE3oq+OFDJ1fxkSBNgIDbY4Yfexu1NwVQe8lqOek=; b=vAOVXMDfdg+DEurjS5YWhH04GQ21+Zdsdmtla0LKmk3EiMA2evDFcyVbJX3COK8asZ 0SRI+tJY6ioaKoxZOX/UPhY9uFb9PRFIuy076q2HDaiTJ9SxSyK5bAmwKdYmyPzCMSti AQcGpSIenkSJBmse6ms6abtK42/vL/+SWuB4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=D0vi+VU2E1FPYFlENITikL9tyj6QK5DanVL/+FNT5BAqdGvcLwjG0IccNE3naxOm89 8UT1LE7/79oGC3XviYjqEhBUZpfJnPK0VcG+6WjkqSRiBo8ZMmSAZuazYVUuneA6Hv7W mXUipInZn+Y6cBhpcIs4CONsxji2qom+BJ88U= MIME-Version: 1.0 Received: by 10.229.37.130 with SMTP id x2mr2419381qcd.147.1301588923621; Thu, 31 Mar 2011 09:28:43 -0700 (PDT) Received: by 10.229.211.84 with HTTP; Thu, 31 Mar 2011 09:28:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 17:28:43 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016368340c06fa376049fc9c957 Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:27:05 -0000 --0016368340c06fa376049fc9c957 Content-Type: text/plain; charset=ISO-8859-1 Thanks Fleep, Vaughn, and Sean! Between the three of you, I have something that is readable here, :DDD Morgaine. ===================== On Thu, Mar 31, 2011 at 4:43 PM, Vaughn Deluca wrote: > I am not sure if i am allowed to upload this to the VWRAP wiki, for > now put it here: > > http://ddscripting.net/Module_1_-_Overview.pdf > > On 3/31/11, Vaughn Deluca wrote: > > Thanks for that upload, but it stops working for me after slide 9, and > > the interesting bits are starting at 17... Let me see if i can make a > > pdf out of the presentation. > > brb. > > > > On 3/31/11, Fleep Tuque wrote: > >> The formatting got a little wonky, but I printed the PPT to PDF and > >> uploaded > >> it to google docs. Should be a public document now, try > >> > https://docs.google.com/document/pub?id=1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA > >> . > >> > >> - 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 > >> > >> > >> > >> On Thu, Mar 31, 2011 at 11:00 AM, Morgaine > >> wrote: > >> > >>> That sounds interesting, Vaughn. > >>> > >>> Unfortunately my Firefox browser and Gmail on Linux appear to have a > >>> semantic problem with Powerpoint, despite the success of Service Level > >>> (Syntactic) Interoperability because it is a recognized type. Is the > >>> OGCII > >>> material available in any other format? > >>> > >>> :P > >>> > >>> > >>> Morgaine. > >>> > >>> > >>> > >>> > >>> ========================== > >>> > >>> > >>> On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca > >>> wrote: > >>> > >> > >> It is a powerpoint presentation with teaching material from the OGCII > >> (Open Geospatial Consortium Interoperability Institute). Processing > >> Geospatial data appears to have many problems in common with our > >> virtual worlds. See: > >> http://portal.ogcii.org/files/?artifact_id=168 (warning: powerpoint > >> download) > >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016368340c06fa376049fc9c957 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Fleep, Vaughn, and Sean!

Between the three of you, I have som= ething that is readable here, :DDD


Morgaine.


=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


On Thu, Mar 31, 2011 at 4:43 PM, Vaughn Deluca <vaughn.deluca@gma= il.com> wrote:
I am not sure if = i am allowed to upload this to the VWRAP wiki, for
now =A0put it here:

http://ddscripting.net/Module_1_-_Overview.pdf

On 3/31/11, Vaughn Deluca <va= ughn.deluca@gmail.com> wrote:
> Thanks for that upload, but it stops working for me after slide 9, and=
> the interesting bits are starting at 17... Let me see if i can make a<= br> > pdf out of the presentation.
> brb.
>
> On 3/31/11, Fleep Tuque <flee= p513@gmail.com> wrote:
>> The formatting got a little wonky, but I printed the PPT to PDF an= d
>> uploaded
>> it to google docs. =A0Should be a public document now, try
>> https://docs.google.com/= document/pub?id=3D1WsjarTozebPG8f7HRh_Qyg9PO6dD603cnUzzLUCRSFA
>> .
>>
>> - 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: =A0 http://homepages.uc.edu/secondlife
>> OLN Second Life: http://www.oln.org/emerging_technologies/e= mtech.php
>>
>>
>>
>> On Thu, Mar 31, 2011 at 11:00 AM, Morgaine
>> <morgaine.din= ova@googlemail.com>wrote:
>>
>>> That sounds interesting, Vaughn.
>>>
>>> Unfortunately my Firefox browser and Gmail on Linux appear to = have a
>>> semantic problem with Powerpoint, despite the success of Servi= ce Level
>>> (Syntactic) Interoperability because it is a recognized type. = =A0Is the
>>> OGCII
>>> material available in any other format?
>>>
>>> :P
>>>
>>>
>>> Morgaine.
>>>
>>>
>>>
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>>>
>>>
>>> On Thu, Mar 31, 2011 at 3:34 PM, Vaughn Deluca
>>> <vaughn.deluca@g= mail.com>wrote:
>>>
>>
>> It is a powerpoint presentation with teaching material from the OG= CII
>> (Open Geospatial Consortium Interoperability Institute). =A0Proces= sing
>> Geospatial data appears to have many problems in common with our >> virtual worlds. See:
>> http://portal.ogcii.org/files/?artifact_id=3D168 =A0 (warn= ing: powerpoint
>> download)
>>
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016368340c06fa376049fc9c957-- From dzonatas@gmail.com Thu Mar 31 09:53:31 2011 Return-Path: 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 010023A6A33 for ; Thu, 31 Mar 2011 09:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.534 X-Spam-Level: X-Spam-Status: No, score=-3.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 J9PFZYrIX1Fh for ; Thu, 31 Mar 2011 09:53:29 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 005AA3A699E for ; Thu, 31 Mar 2011 09:53:28 -0700 (PDT) Received: by iwn39 with SMTP id 39so2985132iwn.31 for ; Thu, 31 Mar 2011 09:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G1HboATv9dOZtVcVARMg324U72Fb4n/nGJkAv8iNwgg=; b=HwRoNOdVlahURgkhBc5YmPowPwjokA/6K+ygTREj+uW00l9xSVUTT8HwkFLyZ0+3ZF //AYbUmMb++tpFLMbdBulmk2LGL2iHiV2VGhi2vroznTnBRjBk0BJ3k8GtPZGc1n4Tf2 hDDwkL2PleaBCDO2jJAFXV0gF2LAe8Y14g24Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=gfq5efXb+KbRPBGZGDpZ87ZT8I1ZO2YiRa6WFxI+YU71+dobzcYv8uJbutEGUBziQb RtweklrknRWzyFgo2TLxv14MHFG10R+VGxmGiv1Q6ECLbYJMN7GYo6fTaYIztKGcD9Jb 0yZ2Lwj7TEJlgUJTU0HPlrm1p8ynkg6R8bXmE= Received: by 10.231.31.195 with SMTP id z3mr2881927ibc.182.1301590508495; Thu, 31 Mar 2011 09:55:08 -0700 (PDT) Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id i26sm849887iby.41.2011.03.31.09.55.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 09:55:07 -0700 (PDT) Message-ID: <4D94B1EF.2030206@gmail.com> Date: Thu, 31 Mar 2011 09:55:11 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: vwrap@ietf.org References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [vwrap] "Trust Domains", conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 16:53:31 -0000 Added "trust domains" to the subject line to hopefully narrow this thread before it goes into some random debate. At the source level, in the (voted upon?) client/server roles, who is the trust domain? If user A connect to asset server B, and B connects to grid X and grid Y, is the trust domain B, X, and Y, or just B and whatever A determines? I don't think there is any determinate client/server role here. Being able to export/import objects with given "trust domain" is obviously either going to be "local only" or maybe combination of above A, B, X, Y. Should we simply establish trust domains based upon sign-in capabilities keep it simple to PGP/GPG keys. I think the URI/GPG-key is the simpler way for non-local assets, yet to be proven. Do consider more complex assets that are "manufactured", and may contain encrypted assets within asset bundles in order to move objects between regions/v-worlds. The current SL(-compatible) protocols don't seem to handle bundles. What-if an asset is made for grid X and bundled with another asset for export/import. If grid Y cannot establish any "trust domain" with grid X then where should the export/import fail? Yes, I'm thinking ahead... but the "manufactured" use-case is old (and by Morgaine's keeps being set aside to argue other "misapprehensions"). The manufactured use-case may get as complex as materials from many different grids in order to put together one object. Then we'll have to consider if that object requires a predefine trust domain in order to interop at various levels. Let me also include this (un-rephrased from other email): Does "service level interop" include anything about "region-crossing"? If it does not, then we surely can then partition capabilities into different client/server clusters. If people want more seamless movement while in "service level interop" then mabye that needs to be upgraded to the"region-crossing" level. When is interop from grid X to grid Y seamless, when do assets need to be conditioned (keep "trust domains" in mind), and when do objects need to be refined? To continue to use client/server terminology in that question is just to complex (or confuses the discussion into further endless debate). Morgaine wrote: > There is no default format, and nowhere does VWRAP deal in > SL-compatible grids. > > We are defining a services-oriented architecture which is nothing like > that of today's SL, and we cannot for a moment assume that SL will > adopt it in the future, as that is their choice, not ours. > > The only partly-compatible VW frameworks over which we have a small > amount of influence are Opensim and realXtend (which uses Opensim > server-side), because we can take their open source code and adapt it > to our protocols if we wish. In that sense, we could be said to be > defining an Opensim-compatible protocol, but never an SL-compatible > protocol. That would be a misapprehension. > > We occasionally say that we are defining an SL-like /*data*/ > architecture, but even that isn't really correct since VWRAP doesn't > favor one in-world content type over another. All content types are > denoted merely by a type tag and there is no standard set of content > types required. > > So what is the real commonality between VWRAP and SL? Currently, only > LLSD is reasonably compatible with SL, although LLSD might well change > in more than just its name if we find the current spec not > sufficiently powerful or lacking extensibility for our needs. > > > Morgaine. > > > > > ========================== > > On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol > wrote: > > Don't need to assume too much like that, Morgaine; however, we > need something more of "trust domains" defined and the example(s) > I wrote about fit in well as lead-in. I stated these use-cases > specially to avoid the use of terminology that now exists, and > this leans towards the need to center on "trust domains." I see > the use of current client/server-* terminology continually to > confuse us (even if some like it, not all do). If we have to think > about such terminology for more than 90 seconds each time then it > needs to change. > > My side-point was that VWs may have their own object format in > their world, and I'm thinking more then just the regions that > exist now that the monolithic client connects. Perhaps, others > only think about SL compatible grids, and don't worry about the > default format. > > Morgaine wrote: > > We've maintained throughout that our protocols would be > extensible with regard to data formats, allowing worlds and > user expectations to evolve without requiring protocol > redefinition. > > In the area of meshes, it is very much to be expected that > COLLADA will figure strongly among the graphic formats used > (particularly since it was chosen for the iED initiative), but > it's not of any special interest to the VWRAP protocols other > than as a potential content type.� All we have to do is to > make sure that we label each transfer with its appropriate > type, and possibly also include other metadata that may be needed. > > We're certainly not standardizing what graphics are used in > virtual worlds, beyond assigning types where they might not > yet exist.� Hardwiring them would be a recipe not for > extensibility but for stagnation.� Other bodies may be > standardizing which graphics formats are used, whereas we're > trying to define useful deployment architectures and > standardizing the protocols through which they are accessed. > > > Morgaine. > > > > > =================== > > On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol > > >> wrote: > > If we say the conditioner basically authenticates or > re-signs an > asset from grid X to grid Y, and the refinery would make > sure the > physics of the object described by the asset is translated from > the topology of grid X to the topology of grid Y, then this is > basically what COLLADA expects in exchange. This exchange > is this > different from the usual import/export process. It doesn't > have to > be this exact process, as this is only an example to us be more > familiar. > > It seems a complete waste to not realize that LL has > implemented > the import process and physics refinery into their browser, and > this very feature, though not fully automated as such, could be > used to help move assets in-between grids/v-worlds. Since the > import is from local basis, the authentication is not > implemented. > What's to stop to basically export to DAE format on the local > storage, from one world, and continue to import that DAE into > another grid. > > Note that the refineries may be proprietary. They may produce > non-COLLADA formats (from DAE files) that are for optimal > render/display capability of the software "client" (i.e. > that the > end-user has to view graphics). > > As with Google Earth and Sony HOME, they already have their > assets > conditioned and refined for those virtual worlds such that they > can optimally display them. The key note is not the optimal > display, as it is about being able to exchange and use in other > virtual worlds. > > The DAE format does have extensive abilities, yet the goal of > COLLADA is still to define the basic material, scripts, > model, etc > in the most portable format. The DAE may contain hybrid or > specific formats that is stored in the extensions, so that > custom > objects are retained/transferred. > > If virtual worlds start to not agree upon how they store > objects, > I see COLLADA as the default format for digital asset exchange. > > > https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F > > (Yes, we can put all inventory items in DAE format through the > user-data and asset extensions, despite the format mainly being > for 3D... just sayin') > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > _______________________________________________ > 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 > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, Consultant > > > ------------------------------------------------------------------------ > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant From mike.dickson@hp.com Thu Mar 31 10:17:50 2011 Return-Path: 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 1AB523A6B32 for ; Thu, 31 Mar 2011 10:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 dW5j2bbQTKwg for ; Thu, 31 Mar 2011 10:17:48 -0700 (PDT) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by core3.amsl.com (Postfix) with ESMTP id 6182C3A6A63 for ; Thu, 31 Mar 2011 10:17:48 -0700 (PDT) X-Authority-Analysis: v=1.1 cv=r4yJ8ACLDmU9N8MfnU6qGSvboKzSN9UnPAeXToqJDNE= c=1 sm=0 a=6hDDB80cvpoA:10 a=IkcTkHD0fZMA:10 a=E1l+YgTSNfk5lq7wdBf7xA==:17 a=pGLkceISAAAA:8 a=voW1Q-phAAAA:8 a=JqEG_dyiAAAA:8 a=48vgC7mUAAAA:8 a=0BLlkqyfW-drSQ9SV_oA:9 a=qcpNCqsC8HWgllyJiFEA:7 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A:10 a=lZB815dzVvQA:10 a=1A9BHoZvh0-1-1k2:21 a=NfqAhXjJyNelK8ht:21 a=E1l+YgTSNfk5lq7wdBf7xA==:117 X-Cloudmark-Score: 0 X-Originating-IP: 174.100.47.252 Received: from [174.100.47.252] ([174.100.47.252:45423] helo=[192.168.0.101]) by cdptpa-oedge01.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id 80/D9-09483-F97B49D4; Thu, 31 Mar 2011 17:19:27 +0000 From: Mike Dickson To: Morgaine In-Reply-To: References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 31 Mar 2011 13:19:23 -0400 Message-ID: <1301591963.12359.53.camel@mdickson-hplinux> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit Cc: "vwrap@ietf.org" Subject: Re: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 17:17:50 -0000 On Thu, 2011-03-31 at 16:23 +0000, Morgaine wrote: > There is no default format, and nowhere does VWRAP deal in > SL-compatible grids. That's actually for the contributors to define. There's no reason we can't choose to favor a direction that's compatible or at least complimentary with existing practice. > > We are defining a services-oriented architecture which is nothing like > that of today's SL, and we cannot for a moment assume that SL will > adopt it in the future, as that is their choice, not ours. You have a tendency to use "we" as this inclusive, everyone agrees with me so its a done deal concept. Again wether the group chooses to leverage some of the concepts in SL (like LLSD for instance) is still open to discussion. And protocol standard are what "we" are about here. Honestly if we fail to produce something that can "inter-operate" with SL at least to some degree I think the usefulness is minimal. > The only partly-compatible VW frameworks over which we have a small > amount of influence are Opensim and realXtend (which uses Opensim > server-side), because we can take their open source code and adapt it > to our protocols if we wish. In that sense, we could be said to be > defining an Opensim-compatible protocol, but never an SL-compatible > protocol. That would be a misapprehension. This is all about implementation and isn't related to standards work at all. How what is produced here is implemented into a "product" (open source or not) is irrelevant. And again, wether the protocol is "SL-compatible" is open to discussion. You clearly have a bias away from it but its not clear that's true for everyone. > > We occasionally say that we are defining an SL-like data architecture, > but even that isn't really correct since VWRAP doesn't favor one > in-world content type over another. All content types are denoted > merely by a type tag and there is no standard set of content types > required. > > So what is the real commonality between VWRAP and SL? Currently, only > LLSD is reasonably compatible with SL, although LLSD might well change > in more than just its name if we find the current spec not > sufficiently powerful or lacking extensibility for our needs. Again, your making assumptions based on what you'd like to see. If you really feel as strongly as you do that an alternative is appropriate I'd get to drafting some documents that describe it. Otherwise IMO, standardizing around existing current practice is completely reasonable and appropriate. Not that there isn't room for improvement of course. But those improvements can be incremental in nature rather than revolutionary. Mike > > > Morgaine. > > > > > ========================== > > On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol > wrote: > Don't need to assume too much like that, Morgaine; however, we > need something more of "trust domains" defined and the > example(s) I wrote about fit in well as lead-in. I stated > these use-cases specially to avoid the use of terminology that > now exists, and this leans towards the need to center on > "trust domains." I see the use of current client/server-* > terminology continually to confuse us (even if some like it, > not all do). If we have to think about such terminology for > more than 90 seconds each time then it needs to change. > > My side-point was that VWs may have their own object format in > their world, and I'm thinking more then just the regions that > exist now that the monolithic client connects. Perhaps, others > only think about SL compatible grids, and don't worry about > the default format. > > Morgaine wrote: > We've maintained throughout that our protocols would > be extensible with regard to data formats, allowing > worlds and user expectations to evolve without > requiring protocol redefinition. > > In the area of meshes, it is very much to be expected > that COLLADA will figure strongly among the graphic > formats used (particularly since it was chosen for the > iED initiative), but it's not of any special interest > to the VWRAP protocols other than as a potential > content type.� All we have to do is to make sure that > we label each transfer with its appropriate type, and > possibly also include other metadata that may be > needed. > > We're certainly not standardizing what graphics are > used in virtual worlds, beyond assigning types where > they might not yet exist.� Hardwiring them would be a > recipe not for extensibility but for stagnation.� > Other bodies may be standardizing which graphics > formats are used, whereas we're trying to define > useful deployment architectures and standardizing the > protocols through which they are accessed. > > > Morgaine. > > > > > =================== > > > > On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol > > > wrote: > > If we say the conditioner basically authenticates > or re-signs an > asset from grid X to grid Y, and the refinery would > make sure the > physics of the object described by the asset is > translated from > the topology of grid X to the topology of grid Y, > then this is > basically what COLLADA expects in exchange. This > exchange is this > different from the usual import/export process. It > doesn't have to > be this exact process, as this is only an example > to us be more > familiar. > > It seems a complete waste to not realize that LL > has implemented > the import process and physics refinery into their > browser, and > this very feature, though not fully automated as > such, could be > used to help move assets in-between grids/v-worlds. > Since the > import is from local basis, the authentication is > not implemented. > What's to stop to basically export to DAE format on > the local > storage, from one world, and continue to import > that DAE into > another grid. > > Note that the refineries may be proprietary. They > may produce > non-COLLADA formats (from DAE files) that are for > optimal > render/display capability of the software > "client" (i.e. that the > end-user has to view graphics). > > As with Google Earth and Sony HOME, they already > have their assets > conditioned and refined for those virtual worlds > such that they > can optimally display them. The key note is not the > optimal > display, as it is about being able to exchange and > use in other > virtual worlds. > > The DAE format does have extensive abilities, yet > the goal of > COLLADA is still to define the basic material, > scripts, model, etc > in the most portable format. The DAE may contain > hybrid or > specific formats that is stored in the extensions, > so that custom > objects are retained/transferred. > > If virtual worlds start to not agree upon how they > store objects, > I see COLLADA as the default format for digital > asset exchange. > > > https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F > > (Yes, we can put all inventory items in DAE format > through the > user-data and asset extensions, despite the format > mainly being > for 3D... just sayin') > > -- --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual > Reality, Consultant > > _______________________________________________ > 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 > > > > > > -- > --- https://twitter.com/Dzonatas_Sol --- > Web Development, Software Engineering, Virtual Reality, > Consultant > > > From dyerbrookme@juno.com Thu Mar 31 13:12:10 2011 Return-Path: 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 8768528C122 for ; Thu, 31 Mar 2011 13:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, SARE_CHILDPRN1=1.15, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 ep+Lv+ROFyzi for ; Thu, 31 Mar 2011 13:11:51 -0700 (PDT) Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 743FF3A69C4 for ; Thu, 31 Mar 2011 13:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juno.com; s=alpha; t=1301602408; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; l=0; h=From:Date:To:Cc:Subject:Message-Id:Content-Type; b=iQPq91UUdkBM5OM/FaysMaEDdMSbW90z6Xn1rI3x6Tn1MmPJbgvSt9ulRPsOOXeAb ESBB0wnxBlCmfiSggRbrsZJsz/+snD9vjecjbrwJbycHSS8KrhzRhm2Nil/+nrwA0S 2+DuLGWx+gtF85495Wt3vLbwrsvLpa1rHSaHpyp4= X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail03.vgs.untd.com [10.181.12.143]) by smtpout05.vgs.untd.com with SMTP id AABG3K2BTAH88JQS for (sender ); Thu, 31 Mar 2011 13:12:33 -0700 (PST) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucf6HyplTnjJh8hlTRNOdndLg3sDjYfFQLg== Received: (from dyerbrookme@juno.com) by webmail03.vgs.untd.com (jqueuemail) id Q7RFQ9QT; Thu, 31 Mar 2011 13:11:40 PDT Received: from [96.246.67.245] by webmail03.vgs.untd.com with HTTP: Thu, 31 Mar 2011 20:10:50 GMT X-Originating-IP: [96.246.67.245] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 31 Mar 2011 20:10:50 GMT To: morgaine.dinova@googlemail.com X-Mailer: Webmail Version 6.1_P2 Message-Id: <20110331.161050.4499.0@webmail03.vgs.untd.com> Content-Type: multipart/alternative;boundary="--__JWM__J454f.3355S.1cfdM" X-UNTD-BodySize: 50420 X-ContentStamp: 1:1:3745829760 X-MAIL-INFO: 0435cdb9cdaded05f55c051118d1e91d08794c4c6de1bda5990c1d858598357c3da5353c2c71e1b975f1ad3d852828ed85ddbca93828f5f8f86ce9cc78d5894579e57d08217d002d452d01019888891cf18d5d4d91691c6909f955d58c813d85cd35cded751d285cb9bcd195bc5c9595f5a998987d995885d84158493d982c583c8835b981a9155d68899c8c895d8c8c1ca1cccced48c8882548a859b595a9dce5b591f89c0129452d411d2d49010ca541c9cce9783ce9091cfc09b17d08ec4508554579006575e9216d2c896878f92ce1a800bd41f98d1d81f9380c998128e5cc4c7c2885112858284d852811c5add8dd28a92861a898488828 dc69812cf5d995d838d99168c165488969016915b55d91ec6cac7dddd1f1197d79b8ccece5786c6cd57931cc6d659d0800282dfc492d814c453c2d9981e105550d01b9057c8881e19d81590511cd699d580511ad35a89ca8f538f8d1d9a8984db8f9adc1d895b53c8938c945c8c809ec11054825716c89158c3ce8c50db11cc5ad0d789ccce5cd6c08793c6871ec652de5297da5491dc101416d4c49d9bdb839bc78ec8d7cbcb9a5b925cd58f5cd6928a8b9 X-UNTD-Peer-Info: 10.181.12.143|webmail03.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com Cc: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 20:12:10 -0000 ----__JWM__J454f.3355S.1cfdM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 I thought this project had died a deserved death and been revealed long = ago for the Trojan horse of the radical open source cult that it is. Int= eroperability is not a demand of paying customers in Second Life; it's a= sectarian demand of a few ideological educators and coders who are usin= g it as a cover to advance their agenda. There is no demonstrable need t= o link Second Life to the open sims that are reverse engineered (yes ind= eed they are) from SL -- given the rampant flushing of content theft alr= eady underway. I've outlined all the problems with this ideological gamb= it here:http://secondthoughts.typepad.com/second_thoughts/2011/02/the-be= rne-inherency-and-the-interop-flop-reply-to-meadh.html?cid=3D6a00d83451c= fe069e2014e5f6737c6970c in answer toMeadhbh's article here herehttp://bl= og.meadhbh.org/2011/01/boiling-ocean-and-profit-motive.html Proprietary worlds are not "prisons". Far from being something to be sco= rned as they were by earlier ideologues in the AOL/Netscape/ etc wars, w= alled gardens are valued. Today, the walled gardens of Facebook, Twitter= and yes, Second Life have millions of happy customers precisely because= they can hold in value better than the Leninist sandboxes devised by th= e Internet's early adapters. All of these lovely walled gardens represen= t progress for civilization, more freedom, not less. While imperfect, as= they still present problems for privacy, IP rights, monetarization, etc= . they are still moving in the direction of *real life* and its *values*= and not in the direction of discredited ideologies from failed states o= f the last century. It's not an imposition to *gasp* log out and then lo= g into another world. The user find that it takes a second. And that's a= n important firewall and membrane to keep intact against theft, griefing= and crime. It's all good. It's not "balkanization" to have realms of ci= vilization that in fact can deter intellectual property theft, harassmen= t and stalking, and crime like child pornography. It's *ok*.The real wor= ld does not consist of warring Balkan-like states merely because they ha= ve customs & immigration and regulations and passports. These are all no= rmal things and their transposition on line is normal and expected and h= ealthy, despite the screeching we hear from people still clinging to a m= isguided and insular notion that everything has to be some communist uto= pia with everything coercively shared for the "good of humankind". WHEN = worlds are ready to hook up to each other -- because they have what are = the analogies of treaties that uphold the rule of law *like content perm= issions* -- THEN they will hook up. Fiddling around and making technical= standards for this execise now is merely an ideological gambit to force= the open source cult on the worlds. When companies *and their customers= * have a need for interoperability, they will FIRST develop the relevant= terms of service and POLICIES, THEN they will develop the tech *that su= pports that, instead of attempts to drive that*. That's it. That's how i= t's going to be. Efforts to abstractly enforce this in advance will like= ly be out of date even on the tech needed, and they will *MOST CERTAINLY= * be undemocratic and out of step with CUSTOMER REQUIREMENTS. Nobody but= those who need to steal them has a felt need to share the assets of Sec= ond Life. These are made by hard-working people who have copyrighted the= se assets. *Get your furry paws off them*. Prokofy Neva ---------- O= riginal Message ---------- From: Morgaine To: vwrap@ietf.org Subject: Re: [vwrap] vwrap Digest, Vol 11, Issue 24 Date: Thu, 31 Mar 2011 01:17:01 +0100 That's a good requirement, Sean. However, you're suggesting a rather inflexible way of achieving it, beca= use it would rely on one world giving you access to another world.ᦙ= 3; This doesn't scale at all when you consider thousands, let alone mill= ions, of destination worlds. = Also, it would result in balkanization of the metaverse, as restrictive = world operators seek to prevent you from travelling to worlds they don't= like.� We'd end up with prison enclaves in which the only way fo= r inmates to "escape" to visit friends in non-permitted worlds would be = to log out from this prison and log in to a different one, which defeats= most of the benefits of VW interop.� It's a poor approach. = Fortunately there is a much better way to achieve this, and David hinted= at it when he wrote about the near impossibility of one world forcing l= ocal policy onto services run by somebody else.� If your assets a= re not held by a world operator but in an independent external asset ser= vice (which could even be on your local system), then you don't need to = ask the current world for "permission" to teleport to some other world, = since you (or your external asset service) can supply all of the resourc= es needed by the destination world directly.� No more prison plan= et. = The Web doesn't usually provide a good analogy with virtual worlds becau= se its architecture is substantially different in several areas.�= However, in respect of teleports the analogy is a direct one.� O= ne world should not limit your ability to teleport to another world any = more than one website should have a say on which website you visit next.= = In summary, the inter-world teleport requirement that you describe is a = good one, but it should not be implemented as a cooperative agreement be= tween worlds because that has very negative repercussions for residents,= turning them into hapless inmates and splitting communities apart. = Instead, VWRAP provides the excellent concept of independent external sh= ared asset services which can serve content to multiple worlds.� = Using them we can design a teleport protocol that empowers users and hel= ps the open metaverse bloom, instead of enslaving them and balkanizing w= orlds into non-communicating factions. = Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee wrote: So, for example, one protocol we would like to define, in the name of V= W interoperability, is how a client, (a viewer and it's user in this cas= e), communicates, to a specific grid X authentication server, that it wa= nts to connect to that grid using grid Y authentication server, which co= uld be another grid or facebook, etc. The communication that happens the= re needs to have some way to determine if that grid Y authentication ser= vice is allowed or known, and if it was successful in authenticating you= , among other things. So, this is, in a way, service level interop, but = like you said, a bit orthogonal. Also, in addition to the communication = between the above service and client, there would have to be communicati= on between grid X authentication service and grid Y authentication servi= ce. More protocol this group would likely specify, I assume. = Peace, Sean = On 03/30/2011 03:40 PM, Morgaine wrote:Very well put, Vaughn. = Regarding "service level interoperability", it's not really a subset of= VW interoperability at all, but lies orthogonal to it because it is a property of all multipart systems that implement services. �I'll= try to explain. = Client-server systems for example have at least two distinct parts with= distinct roles, server(s) and client(s). �Service-level interope= rability typically consists of designing and specifying the protocols or interfaces between them in such a way that any part of the system is interchangeable with another equivalent part that performs the same role, say from a different manufacturer, and the system as a whole stil= l continues to work normally. = This rarely needs to be honored with a fancy title such as "service level interoperability" in these days of IETF standards and highly cross-platform web applications. �Historically however, applicat= ions did not behave quite so nicely, and vendors often sought to lock customers in with hidden proprietary interfaces, so there was a need for adding "service level interoperability" to the tendering documentation in days= gone by, to avoid surprises later on. = Today, the need for that has almost disappeared, and if your online service has a documented protocol interface then "service level interoperability" is virtually assured without doing anything at all, assuming normal commonsense has prevailed during development (and there= is no deliberate obfuscation of course). �There is only one othe= r area of this topic where a little more needs to be said. = Protocol messages can normally be validated syntactically to a strong degree, and whether a message is correct or not is normally known immediately upon syntactic validation. �Unfortunately, that is n= ot always the end of the story, because protocols can transport complex data items which are valid syntactically yet invalid semantically. = This is the last vestige of where that term is commonly encountered, as= *Service Level Semantic Interoperability*. �Is it relevant to us= ? �Yes, a little. �For example, it would do us no good to transport Coll= ada meshes from an asset service to a client that tries to render them as some other graphics format --- that would create a semantic mishap, because one party thinks that the items means one thing and another party applies a different semantic. �So yes, there is a little m= ore for us to consider here, but it's not a lot. �In most part we have a= lready stated the solution every time that we have mentioned MIME types for describing content. �This is mostly a solved problem. = There may be one or two other areas where we have to specify the required semantic alongside the simple matter of protocol syntax, but that's a standard part of defining protocols. �There is nothing = really new here. = Lastly, service level interoperability focuses entirely on single services and their clients, so it's unrelated to interoperability between multiple services, such as a set of virtual world services. This means that, apart from defining type semantics, it doesn't get us even a step closer towards interop between virtual worlds. = = Morgaine. = = = = = = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D = On Wed, Mar 30, 2011 at 10:07 PM, Vaughn Deluca > wrote: = � �Katherine wrote: � � >It seems to me that accomodating "full" interop only= would reduce the � � >number of possible implementers and use cases for ou= r work = � �I am sure that nobody �suggested to we restrict= ourselves to "full" � �interop only. � �"Service level interop" is clearly subset of VW intero= perability. You � �can't have VW interoperability without service level i= nteroperability! � �However, If i understand Morgaine right, she is worrie= d that the VWRAP � �specs will be *restricted* to service level interop on= ly. = � �It has been argued (sorry, I forgot by whom) that prop= er � �specifications of service level interop will give us v= irtual world � �interop for free. I think we need a bit more, but i re= ally have a hard � �time envisioning how service level interop can be spec= ified in such a � �way that it *prevents* VW interop, at least not if we = pay attention to � �this aspect, and clearly we do. So in conclusion i do = not see much of � �a problem. = � �Izzy wrote in another tread "This whole argument betwe= en service level � �interop and 'full' interop eludes me." At first it elu= ded me to, but � �now i think that what is actually expressed in these d= iscussions is � �the question of the scope of our effort as well as des= ign approach. � �Some prefer to work bottom up, following their primary= interests in � �getting the low level protocols working, especially si= nce that will � �already be good enough for (all?) of their use cases .= Some prefer a � �more top-down approach, first sketching the high level= picture of the � �users perception of VW interop, �and from there= working downwards, � �obviously also because that approach optimises the rea= lisation of � �*their* use cases. = � �I think we need both, and above all, i do feel that th= e two approaches � �are not al all incompatible and both are without any d= oubt square � �within the current charter. � �Formally splitting our effort in two working parties a= long the current � �visible fissures and getting each to work on their own= interest is a � �recipe for disaster. It will only strengthen the animo= sity that is � �already slowing us down tremendously, and will sustain= the infighting. � �Rather than spitting efforts off, we need to address t= he causes for � �the current disagreement and found common ground. A= 533;In my view that is � �not all all hard. = � �I have been reviewing the discussion we had in Septemb= er and i am � �actually amazed at the level of consensus that is expr= essed in those � �email exchanges. Unfortuanately we have been very bad = at consolidating � �that consensus. As a result we recycle the same proble= ms time and time � �again. The archives make very depressing reading from = that point of � �view. We need to do more documentation for sure. = � �I am currently going over the September discussion and= looking up the � �places were we all agreed on the way forward. �= Much of that is still � �undocumented, and my aim is to get those points writte= n down in the � �wiki. = � �As i final point i want to make clear how I understand= the term � �"Service Level Interop". I used the term, and since th= e glosary entry � �is still emtpy, i feel obliged to add at least my pers= onal reading. If � �somebody disagrees, please add an improved version. = � �Service level interoperability: � � � � � �A subset of "Virtu= al World Interoperability" as defined by � �the VWRAP � �protocol. Service level interoperabity loosely describ= es specific � �interactions between VWRAP endpoints. These inteaction= s form the glue � �that hold a particular virtual world together, but mig= ht just as well � �be used for communication between different VWRAP comp= atible virtual � �worlds (i.e. crossing trust domains). = � �I intend to put this up in the glossary, but first wil= l see how it � �flies here �:) = � �On 3/29/11, Katherine Mancuso > wrote: � � > Hi everyone, � � > � � > I want to speak up for agreeing with Meadhbh & Mike= about keeping a � � > role for service level interop in this group. ʏ= 33;We've made good � � > progress towards this goal and can continue to work= on it. � � > � � > Here is an alternative proposal to any which has be= en brought up so � � > far. �I'm aware this may not be fully correc= t in its technical � � > details, as I am not a software architect: � � > � � > Could the partisans of "full" VW interop consider w= orking together on � � > a draft specification that is something like the in= tro or David's � � > piece in scope that lays out which specific capacit= ies would need to � � > be supported at a minimum to allow for "full" inter= op, perhaps � �getting � � > input from implementers such as the Hypergrid folks= and the folks who � � > coordinated the teleport test at Linden? �Ci= ting existing service � � > specifications (either ones developed within this W= G, or outside � � > specifications like XML, Collada, etc) is preferred= , and for � � > capabilities for which there are not existing servi= ce specifications � � > or the existing specifications don't work well enou= gh, 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 individu= al services, and � � > the folks who wish to do "full" interop could defin= e a menu of � � > services which must be implemented for "full" inter= op. �Implementers � � > could then choose their path based on their use cas= es: implement the � � > "full" interop specification including all the spec= ifications called � � > for, or implement individual services. �I be= lieve that both of these � � > concepts can exist under our existing charter or wi= th limited � � > amendment to the charter and intro, which is much e= asier 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 onl= y would reduce the � � > number of possible implementers and use cases for o= ur work � � > dramatically, not to mention cut out a productive b= ody 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 educatio= n, I know � �there's a � � > substantial use case in K-12 education in the US fo= r walled gardens, � � > because schools have big legal liability problems w= ith letting minors � � > wander unwalled virtual worlds (most school librari= es in the US have � � > internet filters for the same reasons) and have fai= rly 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 thes= e folks, since � � > educators don't necessarily need to reinvent the wh= eel for their � � > classrooms every year. �This is a really goo= d case for service level � � > interop ... implement the asset server specificatio= n only, not the � � > "full" one that allows you to teleport to other wor= lds. � � > � � > On the other hand, universities have far greater in= terest in letting � � > students and professors teleport among university s= paces (which � � > happens metaphorically in the real world all the ti= me), and fewer � � > liability issues. �Sharing an asset server m= ight 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 paralle= l on their ideas, � � > rather than assuming that one model has to exclusiv= ely dominate the � � > group. � � > � � > I will be unavailable to post anything else much le= ngthy through � �3 April, � � > FYI. � � > � � > Katherine � � > � � > -- � � > � �------------------------------------------------------= --------------------------------------- � � > Katherine Mancuso � � > � � > ISIS Inc, Community Manager (http://www.isis-inc.or= g) � � > Sex::Tech Conference, Social Media Chair (http://ww= w.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 � � > � �------------------------------------------------------= ---------------------------------------- � � > _______________________________________________ � � > vwrap mailing list � � > vwrap@ietf.o= rg � � > https://www.ietf.org/mailman/listinfo/vwrap � � > � �_______________________________________________ � �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 = -- = = Sean Hennessee Central Computing Support Office of Information Technology UC Irvine = = ... . .- -. / �.... . -. -. . ... ... . . _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap = ____________________________________________________________ Groupon.com Official Site 1 huge daily deal on the best stuff to do in your city. Try it today! http://thirdpartyoffers.juno.com/TGL3141/4d94e0321d2534822c1st05vuc ----__JWM__J454f.3355S.1cfdM Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/html; charset=ISO-8859-1
I thought this project had died a deserved death and been rev= ealed long ago for the Trojan horse of the radical open source cult that= it is.
 
Interoperability is not a demand of p= aying customers in Second Life; it's a sectarian demand of a few ideolog= ical educators and coders who are using it as a cover to advance their a= genda.
 
There is no demonstrable need to link = Second Life to the open sims that are reverse engineered (yes indeed the= y are) from SL -- given the rampant flushing of content theft already un= derway.
 
I've outlined all the problems with t= his ideological gambit here:
http://secondthoughts.typepad.com= /second_thoughts/2011/02/the-berne-inherency-and-the-interop-flop-reply-= to-meadh.html?cid=3D6a00d83451cfe069e2014e5f6737c6970c
 <= /div>
in answer toMeadhbh's article here here
http://blog.= meadhbh.org/2011/01/boiling-ocean-and-profit-motive.html

P= roprietary worlds are not "prisons". Far from being something to be scor= ned as they were by earlier ideologues in the AOL/Netscape/ etc wars, wa= lled gardens are valued. Today, the walled gardens of Facebook, Twitter = and yes, Second Life have millions of happy customers precisely because = they can hold in value better than the Leninist sandboxes devised by the= Internet's early adapters. All of these lovely walled gardens represent= progress for civilization, more freedom, not less. While imperfect, as = they still present problems for privacy, IP rights, monetarization, etc.= they are still moving in the direction of *real life* and its *values* = and not in the direction of discredited ideologies from failed states of= the last century.
 
It's not an imposition to = *gasp* log out and then log into another world. The user find that it ta= kes a second. And that's an important firewall and membrane to keep inta= ct against theft, griefing and crime. It's all good.
 
It's not "balkanization" to have realms of civilization that in = fact can deter intellectual property theft, harassment and stalking, and= crime like child pornography. It's *ok*.The real world does not consist= of warring Balkan-like states merely because they have customs & im= migration and regulations and passports. These are all normal things and= their transposition on line is normal and expected and healthy, despite= the screeching we hear from people still clinging to a misguided and in= sular notion that everything has to be some communist utopia with everyt= hing coercively shared for the "good of humankind".
 
WHEN worlds are ready to hook up to each other -- because they ha= ve what are the analogies of treaties that uphold the rule of law *like = content permissions* -- THEN they will hook up. Fiddling around and maki= ng technical standards for this execise now is merely an ideological gam= bit to force the open source cult on the worlds. When companies *and the= ir customers* have a need for interoperability, they will FIRST develop = the relevant terms of service and POLICIES, THEN they will develop the t= ech *that supports that, instead of attempts to drive that*. That's it. = That's how it's going to be. Efforts to abstractly enforce this in advan= ce will likely be out of date even on the tech needed, and they will *MO= ST CERTAINLY* be undemocratic and out of step with CUSTOMER REQUIREMENTS= .
 
Nobody but those who need to steal them has= a felt need to share the assets of Second Life. These are made by hard-= working people who have copyrighted these assets. *Get your furry paws o= ff them*.
 
Prokofy Neva
 
=
 
 
 
 
---------- Original Message ----------
From: Morgaine <morgaine.d= inova@googlemail.com>
To: vwrap@ietf.org
Subject: Re: [vwrap] v= wrap Digest, Vol 11, Issue 24
Date: Thu, 31 Mar 2011 01:17:01 +0100
That's a good requirement, Sean.

However, you're suggesting= a rather inflexible way of achieving it, because it would rely on one w= orld giving you access to another world.� This doesn't scale at a= ll when you consider thousands, let alone millions, of destination world= s.

Also, it would result in balkanization of the metaverse, as r= estrictive world operators seek to prevent you from travelling to worlds= they don't like.� We'd end up with prison enclaves in which the = only way for inmates to "escape" to visit friends in non-permitted world= s would be to log out from this prison and log in to a different one, wh= ich defeats most of the benefits of VW interop.� It's a poor appr= oach.

Fortunately there is a much better way to achieve this, an= d David hinted at it when he wrote about the near impossibility of one w= orld forcing local policy onto services run by somebody else.� If= your assets are not held by a world operator but in an independent exte= rnal asset service (which could even be on your local system), then you = don't need to ask the current world for "permission" to teleport to some= other world, since you (or your external asset service) can supply all = of the resources needed by the destination world directly.� No mo= re prison planet.

The Web doesn't usually provide a good analogy= with virtual worlds because its architecture is substantially different= in several areas.� However, in respect of teleports the analogy = is a direct one.� One world should not limit your ability to tele= port to another world any more than one website should have a say on whi= ch website you visit next.

In summary, the inter-world teleport = requirement that you describe is a good one, but it should not be implem= ented as a cooperative agreement between worlds because that has very ne= gative repercussions for residents, turning them into hapless inmates an= d splitting communities apart.

Instead, VWRAP provides the excel= lent concept of independent external shared asset services which can ser= ve content to multiple worlds.� Using them we can design a telepo= rt protocol that empowers users and helps the open metaverse bloom, inst= ead of enslaving them and balkanizing worlds into non-communicating fact= ions.


Morgaine.





=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Thu, Mar 31, 2011 at 12:20 AM, Sean Hennessee <sean@uci.edu> wr= ote:
So, for examp= le, one protocol we would like to define, in the name of VW interoperabi= lity, is how a client, (a viewer and it's user in this case), communicat= es, to a specific grid X authentication server, that it wants to connect= to that grid using grid Y authentication server, which could be another= grid or facebook, etc. The communication that happens there needs to ha= ve some way to determine if that grid Y authentication service is allowe= d or known, and if it was successful in authenticating you, among other = things. So, this is, in a way, service level interop, but like you said,= a bit orthogonal. Also, in addition to the communication between the ab= ove service and client, there would have to be communication between gri= d X authentication service and grid Y authentication service. More proto= col this group would likely specify, I assume.

Peace,
Sean<= div>


On 03/30/2011 03:40 PM, Morgaine wrote:<= /div>
Very well put, Vaughn.

Regarding "service level int= eroperability", it's not really a subset of
VW interoperability at a= ll, but lies orthogonal to it because it is a
property of all multip= art systems that implement services. �I'll try to
explain.
Client-server systems for example have at least two distinct part= s with
distinct roles, server(s) and client(s). �Service-leve= l interoperability
typically consists of designing and specifying th= e protocols or
interfaces between them in such a way that any part o= f the system is
interchangeable with another equivalent part that pe= rforms the same
role, say from a different manufacturer, and the sys= tem as a whole still
continues to work normally.

This rarel= y needs to be honored with a fancy title such as "service
level inte= roperability" in these days of IETF standards and highly
cross-platf= orm web applications. �Historically however, applications did
= not behave quite so nicely, and vendors often sought to lock customers<= br> in with hidden proprietary interfaces, so there was a need for addin= g
"service level interoperability" to the tendering documentation in= days
gone by, to avoid surprises later on.

Today, the need= for that has almost disappeared, and if your online
service has a d= ocumented protocol interface then "service level
interoperability" i= s virtually assured without doing anything at all,
assuming normal c= ommonsense has prevailed during development (and there
is no deliber= ate obfuscation of course). �There is only one other area
of = this topic where a little more needs to be said.

Protocol messa= ges can normally be validated syntactically to a strong
degree, and = whether a message is correct or not is normally known
immediately up= on syntactic validation. �Unfortunately, that is not
always t= he end of the story, because protocols can transport complex
data it= ems which are valid syntactically yet invalid semantically.

Thi= s is the last vestige of where that term is commonly encountered, as
= *Service Level Semantic Interoperability*. �Is it relevant to us= ? �Yes,
a little. �For example, it would do us no good= to transport Collada
meshes from an asset service to a client that = tries to render them as
some other graphics format --- that would cr= eate a semantic mishap,
because one party thinks that the items mean= s one thing and another
party applies a different semantic. �= So yes, there is a little more for
us to consider here, but it's not= a lot. �In most part we have already
stated the solution eve= ry time that we have mentioned MIME types for
describing content. &#= 65533;This is mostly a solved problem.

There may be one or two = other areas where we have to specify the
required semantic alongside= the simple matter of protocol syntax, but
that's a standard part of= defining protocols. �There is nothing really
new here.
<= br> Lastly, service level interoperability focuses entirely on single services and their clients, so it's unrelated to interoperability
= between multiple services, such as a set of virtual world services.
= This means that, apart from defining type semantics, it doesn't get us even a step closer towards interop between virtual worlds.

<= br> Morgaine.






=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Wed, = Mar 30, 2011 at 10:07 PM, Vaughn Deluca <vaughn.deluca@gmail.com
=
<mailto:vaughn.deluca@gmail.com>> wrote:
� �Katherine wrote:
� � >It seems = to me that accomodating "full" interop only would reduce the
�= ; � >number of possible implementers and use cases for our wor= k

� �I am sure that nobody �suggested to w= e restrict ourselves to "full"
� �interop only.
&#= 65533; �"Service level interop" is clearly subset of VW interoper= ability. You
� �can't have VW interoperability without= service level interoperability!
� �However, If i unde= rstand Morgaine right, she is worried that the VWRAP
� ᦙ= 3;specs will be *restricted* to service level interop only.

= 5533; �It has been argued (sorry, I forgot by whom) that proper � �specifications of service level interop will give us= virtual world
� �interop for free. I think we need a = bit more, but i really have a hard
� �time envisioning= how service level interop can be specified in such a
� ʏ= 33;way that it *prevents* VW interop, at least not if we pay attention t= o
� �this aspect, and clearly we do. So in conclusion = i do not see much of
� �a problem.

� &= #65533;Izzy wrote in another tread "This whole argument between service = level
� �interop and 'full' interop eludes me." At fir= st it eluded me to, but
� �now i think that what is ac= tually expressed in these discussions is
� �the questi= on of the scope of our effort as well as design approach.
� &= #65533;Some prefer to work bottom up, following their primary interests = in
� �getting the low level protocols working, especia= lly since that will
� �already be good enough for (all= ?) of their use cases . Some prefer a
� �more top-down= approach, first sketching the high level picture of the
� &#= 65533;users perception of VW interop, �and from there working dow= nwards,
� �obviously also because that approach optimi= ses the realisation of
� �*their* use cases.

= � �I think we need both, and above all, i do feel that the= two approaches
� �are not al all incompatible and bot= h are without any doubt square
� �within the current c= harter.
� �Formally splitting our effort in two workin= g parties along the current
� �visible fissures and ge= tting each to work on their own interest is a
� �recip= e for disaster. It will only strengthen the animosity that is
ᦙ= 3; �already slowing us down tremendously, and will sustain the in= fighting.
� �Rather than spitting efforts off, we need= to address the causes for
� �the current disagreement= and found common ground. �In my view that is
� ᦙ= 3;not all all hard.

� �I have been reviewing the = discussion we had in September and i am
� �actually am= azed at the level of consensus that is expressed in those
� &= #65533;email exchanges. Unfortuanately we have been very bad at consolid= ating
� �that consensus. As a result we recycle the sa= me problems time and time
� �again. The archives make = very depressing reading from that point of
� �view. We= need to do more documentation for sure.

� �I am = currently going over the September discussion and looking up the
= 5533; �places were we all agreed on the way forward. �Much= of that is still
� �undocumented, and my aim is to ge= t those points written down in the
� �wiki.

&= #65533; �As i final point i want to make clear how I understand t= he term
� �"Service Level Interop". I used the term, a= nd since the glosary entry
� �is still emtpy, i feel o= bliged to add at least my personal reading. If
� �some= body disagrees, please add an improved version.

� ᦙ= 3;Service level interoperability:
� � � �= ; � �A subset of "Virtual World Interoperability" as defin= ed by
� �the VWRAP
� �protocol. Serv= ice level interoperabity loosely describes specific
� �= ;interactions between VWRAP endpoints. These inteactions form the glue � �that hold a particular virtual world together, but m= ight just as well
� �be used for communication between= different VWRAP compatible virtual
� �worlds (i.e. cr= ossing trust domains).

� �I intend to put this up= in the glossary, but first will see how it
� �flies h= ere �:)

� �On 3/29/11, Katherine Mancuso &= lt;kmancuso@gmai= l.com
� �<mailto:= kmancuso@gmail.c= om>> wrote:
� � > Hi everyone,
ᦙ= 3; � >
� � > I want to speak up for agree= ing with Meadhbh & Mike about keeping a
� � > r= ole for service level interop in this group. �We've made good
= � � > progress towards this goal and can continue to w= ork 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= 533; � > a draft specification that is something like the intr= o or David's
� � > piece in scope that lays out whi= ch specific capacities would need to
� � > be suppo= rted at a minimum to allow for "full" interop, perhaps
� A= 533;getting
� � > input from implementers such as t= he Hypergrid folks and the folks who
� � > coordina= ted the teleport test at Linden? �Citing existing service
= 5533; � > 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
� ᦙ= 3; > or the existing specifications don't work well enough, address � �that to
� � > lay out a clear r= oadmap of what must be developed.
� � >
�= ; � > My vision here is that folks who are doing service-level= work could
� � > continue developing and implement= ing their individual services, and
� � > the folks = who wish to do "full" interop could define a menu of
� ᦙ= 3; > services which must be implemented for "full" interop. �I= mplementers
� � > could then choose their path base= d on their use cases: implement the
� � > "full" in= terop specification including all the specifications called
�= � > for, or implement individual services. �I believe = that both of these
� � > concepts can exist under o= ur 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 r= equire
� � > trashing years of work.
� &= #65533; >
� � > 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 i= n
� � > this group who have been contributing an aw= ful lot of documents and
� � > implementing.
&#= 65533; � >
� � > For example, to illustra= te my point:
� � >
� � > From = my work as a SL developer focusing in education, I know
� = 5533;there's a
� � > substantial use case in K-12 e= ducation in the US for walled gardens,
� � > becaus= e schools have big legal liability problems with letting minors
A= 533; � > 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 &
� &#= 65533; > surveillance tools. �However, a shared asset server t= hat contains a
� � > core of "safe" content might b= e of interest to these folks, since
� � > educators= don't necessarily need to reinvent the wheel for their
� = 5533; > classrooms every year. �This is a really good case for= service level
� � > interop ... implement the asse= t server specification only, not the
� � > "full" o= ne that allows you to teleport to other worlds.
� � &g= t;
� � > On the other hand, universities have far g= reater interest in letting
� � > students and profe= ssors teleport among university spaces (which
� � >= happens metaphorically in the real world all the time), and fewer
&= #65533; � > liability issues. �Sharing an asset server = might be of interest to
� � > them, but so too migh= t "full" interop. �They'd want to implement the
� A= 533; > "full" interop specification.
� � >
&= #65533; � > (Paging Fleep Tuque, are you here to make this cas= e better for me?)
� � >
� � > = TL;DR - Proposal is to amend the charter & intro so that they allow<= br> � � > the "full" interop people to work in one comm= unity on their ideas and
� � > the service level in= terop people to work in parallel on their ideas,
� � &= gt; rather than assuming that one model has to exclusively dominate the<= br> � � > group.
� � >
�= ; � > I will be unavailable to post anything else much lengthy= through
� �3 April,
� � > FYI. � � >
� � > Katherine
ʏ= 33; � >
� � > --
� � &g= t;
� �------------------------------------------------= ---------------------------------------------
� � >= 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
� �= > (htt= p://www.thevesuviusgroup.com)
� � > GimpGirl Co= mmunity Liaison (h= ttp://www.gimpgirl.com)
� � >
� A= 533; > http://twitter.com/musingvirtual
� � > http://facebook.com/= kmancuso
� � > http://www.linkedin.com/in/kathyma= ncuso
� � > Second Life: Muse Carmona
ʏ= 33; � >
� �---------------------------------= -------------------------------------------------------------
ᦙ= 3; � > _______________________________________________
= 5533; � > vwrap mailing list
� � >= ; vwrap@ietf.org= <mailto:vwrap@ie= tf.org>

� � > https://ww= w.ietf.org/mailman/listinfo/vwrap
� � >
= 5533; �_______________________________________________
ᦙ= 3; �vwrap mailing list
� �vwrap@ietf.org <mailto:vwrap@ietf.org>

� �https://www.ietf.org/mailman/listinfo/= vwrap




______________________________________= _________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/l= istinfo/vwrap

--

Sean Hennessee
Central Computing Support
Office o= f Information Technology
UC Irvine


... . .- -. / ʏ= 33;.... . -. -. . ... ... . .

________= _______________________________________
vwrap mailing list
vwrap@ietf.org
= https://www.ietf.org/mailman/listinfo/vwrap
=

 



_____________________________= _______________________________
Groupon.com Official Site
1 huge daily deal on the best stuff to do in your city. = Try it today!
Gr= oupon.com ----__JWM__J454f.3355S.1cfdM-- From morgaine.dinova@googlemail.com Thu Mar 31 14:49:57 2011 Return-Path: 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 81AE33A6BC1 for ; Thu, 31 Mar 2011 14:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 6lol85xB+5uc for ; Thu, 31 Mar 2011 14:49:54 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 6CBF53A6BC0 for ; Thu, 31 Mar 2011 14:49:54 -0700 (PDT) Received: by pzk30 with SMTP id 30so640678pzk.31 for ; Thu, 31 Mar 2011 14:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=zjkJPnzmLoJFRqa22acREm06ORwPLMfibqv1wgOCWz8=; b=oVwyw5u+2WK621JZcj7AXfQMLjxgKBqrtmp/v1OZdxzKntvpfIHVWjLCVinPGe9j9/ bMoqVAcnf3KuwABt6+2ELXGp7tsuchsourMEqf454YvtYnqipRBEtGzphyldAJmYIoWh xEogEGqVR4j0OvtDi5Mz1AB0EfK9TiyZAgKRI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=ImKInSP2C4mxkVngmcjE5jWX1pEPxnlfZH/cCA1TQeQu6wzbh7a78oxAdyYHhj5SHr CWonh5PY+vIJGlA/tpW8VQxMi63cDgMPVUGMn1C7pHeIowuoWZ8tzgT4PMOM88JzUplw 7K+OH3WFOfSuwbJCuqSYSi9hv/UOEsSm3OrjM= MIME-Version: 1.0 Received: by 10.142.245.10 with SMTP id s10mr1807295wfh.90.1301608291058; Thu, 31 Mar 2011 14:51:31 -0700 (PDT) Received: by 10.142.207.7 with HTTP; Thu, 31 Mar 2011 14:51:31 -0700 (PDT) In-Reply-To: <1301591963.12359.53.camel@mdickson-hplinux> References: <4D93E82C.7060503@gmail.com> <4D949BFB.1010804@gmail.com> <1301591963.12359.53.camel@mdickson-hplinux> Date: Thu, 31 Mar 2011 22:51:31 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=000e0cd17298d34523049fce4bd1 Subject: Re: [vwrap] Conditioners and refineries X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 21:49:57 -0000 --000e0cd17298d34523049fce4bd1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2011 at 6:19 PM, Mike Dickson wrote: > On Thu, 2011-03-31 at 16:23 +0000, Morgaine wrote: > > There is no default format, and nowhere does VWRAP deal in > > SL-compatible grids. > > That's actually for the contributors to define. There's no reason we > can't choose to favor a direction that's compatible or at least > complimentary with existing practice. > > > > > We are defining a services-oriented architecture which is nothing like > > that of today's SL, and we cannot for a moment assume that SL will > > adopt it in the future, as that is their choice, not ours. > > You have a tendency to use "we" as this inclusive, everyone agrees with > me so its a done deal concept. Again wether the group chooses to > leverage some of the concepts in SL (like LLSD for instance) is still > open to discussion. And protocol standard are what "we" are about here. > Honestly if we fail to produce something that can "inter-operate" with > SL at least to some degree I think the usefulness is minimal. > > Mike, in the post you quoted, I made no reference to what I personally woul= d like to see. When I've used the word "we" and suggested that "we" hold som= e view, it is because the participants of THIS GROUP have expressed similar ideas in sufficient numbers for it to be an approximate majority view, and often (but not always) unanimous. If the "we" does not include yourself, i= t is because you were either not participating at the time, or because you were in the minority on the topic at the time. A default content format has never even been *mentioned* here until Dzonatas' recent post, so when I wrote "There is no default format" it was = a wholly accurate statement up to this point in time, and not just my opinion. And while we cannot foretell the future, that statement will continue to be accurate until such a time as we've discussed the issue and decided that there will be a default format. In the interim, the fact that there is no default format specified, agreed, or even discussed in VWRAP, stands, regardless of whether you or I would wish it otherwise personally. With regard to our relationship with SL, I don't think I need to explain further the fact that we are not defining Linden Lab's future architecture, protocols, nor service concepts for them. We don't have that power, and they are under no obligation to take any notice of what we do, particularly now that they have officially withdrawn from the table. At best we can hop= e that our protocols are good enough and flexible enough that a subset of the= m is useful for a proprietary service like Second Life. Our work is not being undertaken for their benefit however, but to serve th= e needs of the entire Internet community as per our mandate under the *IETF Mission Statement*. If Linden Lab can benefit as well then we have done a good job. I hope that you are not disagreeing that "we are defining a services-oriented architecture", so I'm not sure why you cited that sentence. Having witnessed all the discussions since the start of AWG and OGP and MMOX all the way through to VWRAP, I believe that we are completely unanimous that that is exactly what we are doing, so the "we" was, again, accurate. If you don't think that we should be defining a services-oriente= d architecture, I have yet to read any objections in that regard. > > The only partly-compatible VW frameworks over which we have a small > > amount of influence are Opensim and realXtend (which uses Opensim > > server-side), because we can take their open source code and adapt it > > to our protocols if we wish. In that sense, we could be said to be > > defining an Opensim-compatible protocol, but never an SL-compatible > > protocol. That would be a misapprehension. > > This is all about implementation and isn't related to standards work at > all. How what is produced here is implemented into a "product" (open > source or not) is irrelevant. And again, wether the protocol is > "SL-compatible" is open to discussion. You clearly have a bias away > from it but its not clear that's true for everyone. > > That is incorrect. IETF drafts are not promoted to Internet standards unless they have implementations --- again, the Mission Statement is worth reading. "*Rough consensus and running code*" is a cardinal principle highlighted in BCP 95. Since we do not have the power to test our ideas within Second Life, but only within open source frameworks like Opensim, SL compatibility is beyond our reach until such a time as Linden Lab provides the required test implementation. In the absence of that, only Opensim and/or realXtend compatibility is within our grasp because we can add the "running code" there ourselves. (Adding VWRAP protocol code to other open source VW frameworks such as OpenWonderland, OpenCobalt, or Sirikata is potentially within our grasp as well, but would require much more work and knowledge of those systems.) > > > > We occasionally say that we are defining an SL-like data architecture, > > but even that isn't really correct since VWRAP doesn't favor one > > in-world content type over another. All content types are denoted > > merely by a type tag and there is no standard set of content types > > required. > > > > So what is the real commonality between VWRAP and SL? Currently, only > > LLSD is reasonably compatible with SL, although LLSD might well change > > in more than just its name if we find the current spec not > > sufficiently powerful or lacking extensibility for our needs. > > Again, your making assumptions based on what you'd like to see. If you > really feel as strongly as you do that an alternative is appropriate I'd > get to drafting some documents that describe it. Otherwise IMO, > standardizing around existing current practice is completely reasonable > and appropriate. Not that there isn't room for improvement of course. > But those improvements can be incremental in nature rather than > revolutionary. > > What you refer to as my "assumptions" are nothing more than rather obvious observations which have never been a matter of disagreement here. Our target for VWRAP testing is Opensim because, as I already explained, the SL platform is outside of our control. Indeed, Linden Lab has probably disclaimed more than once any unwarranted expectation that they undertake t= o implement VWRAP concepts, so it would be quite odd for us to insist that we are designing a protocol that will be compatible with a new generation of SL. That is not something which we can claim, nor work towards. The most we ca= n do is design a flexible protocol usable in many different deployments (including commercial services), and hope that Linden Lab decides to adopt it. Much more important though is that our protocols serve the much broade= r Internet community well, and that goes far beyond the needs of one commercial provider. That is a duty which we have undertaken by being members of this IETF working group. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D On Thu, Mar 31, 2011 at 6:19 PM, Mike Dickson wrote: > On Thu, 2011-03-31 at 16:23 +0000, Morgaine wrote: > > There is no default format, and nowhere does VWRAP deal in > > SL-compatible grids. > > That's actually for the contributors to define. There's no reason we > can't choose to favor a direction that's compatible or at least > complimentary with existing practice. > > > > > We are defining a services-oriented architecture which is nothing like > > that of today's SL, and we cannot for a moment assume that SL will > > adopt it in the future, as that is their choice, not ours. > > You have a tendency to use "we" as this inclusive, everyone agrees with > me so its a done deal concept. Again wether the group chooses to > leverage some of the concepts in SL (like LLSD for instance) is still > open to discussion. And protocol standard are what "we" are about here. > Honestly if we fail to produce something that can "inter-operate" with > SL at least to some degree I think the usefulness is minimal. > > > The only partly-compatible VW frameworks over which we have a small > > amount of influence are Opensim and realXtend (which uses Opensim > > server-side), because we can take their open source code and adapt it > > to our protocols if we wish. In that sense, we could be said to be > > defining an Opensim-compatible protocol, but never an SL-compatible > > protocol. That would be a misapprehension. > > This is all about implementation and isn't related to standards work at > all. How what is produced here is implemented into a "product" (open > source or not) is irrelevant. And again, wether the protocol is > "SL-compatible" is open to discussion. You clearly have a bias away > from it but its not clear that's true for everyone. > > > > > We occasionally say that we are defining an SL-like data architecture, > > but even that isn't really correct since VWRAP doesn't favor one > > in-world content type over another. All content types are denoted > > merely by a type tag and there is no standard set of content types > > required. > > > > So what is the real commonality between VWRAP and SL? Currently, only > > LLSD is reasonably compatible with SL, although LLSD might well change > > in more than just its name if we find the current spec not > > sufficiently powerful or lacking extensibility for our needs. > > Again, your making assumptions based on what you'd like to see. If you > really feel as strongly as you do that an alternative is appropriate I'd > get to drafting some documents that describe it. Otherwise IMO, > standardizing around existing current practice is completely reasonable > and appropriate. Not that there isn't room for improvement of course. > But those improvements can be incremental in nature rather than > revolutionary. > > Mike > > > > > > > Morgaine. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > > > > On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol > > wrote: > > Don't need to assume too much like that, Morgaine; however, we > > need something more of "trust domains" defined and the > > example(s) I wrote about fit in well as lead-in. I stated > > these use-cases specially to avoid the use of terminology that > > now exists, and this leans towards the need to center on > > "trust domains." I see the use of current client/server-* > > terminology continually to confuse us (even if some like it, > > not all do). If we have to think about such terminology for > > more than 90 seconds each time then it needs to change. > > > > My side-point was that VWs may have their own object format in > > their world, and I'm thinking more then just the regions that > > exist now that the monolithic client connects. Perhaps, others > > only think about SL compatible grids, and don't worry about > > the default format. > > > > Morgaine wrote: > > We've maintained throughout that our protocols would > > be extensible with regard to data formats, allowing > > worlds and user expectations to evolve without > > requiring protocol redefinition. > > > > In the area of meshes, it is very much to be expected > > that COLLADA will figure strongly among the graphic > > formats used (particularly since it was chosen for the > > iED initiative), but it's not of any special interest > > to the VWRAP protocols other than as a potential > > content type.=EF=BF=BD All we have to do is to make sur= e that > > we label each transfer with its appropriate type, and > > possibly also include other metadata that may be > > needed. > > > > We're certainly not standardizing what graphics are > > used in virtual worlds, beyond assigning types where > > they might not yet exist.=EF=BF=BD Hardwiring them woul= d be a > > recipe not for extensibility but for stagnation.=EF=BF= =BD > > Other bodies may be standardizing which graphics > > formats are used, whereas we're trying to define > > useful deployment architectures and standardizing the > > protocols through which they are accessed. > > > > > > Morgaine. > > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D > > > > > > > > On Thu, Mar 31, 2011 at 3:34 AM, Dzonatas Sol > > > > > wrote: > > > > If we say the conditioner basically authenticates > > or re-signs an > > asset from grid X to grid Y, and the refinery would > > make sure the > > physics of the object described by the asset is > > translated from > > the topology of grid X to the topology of grid Y, > > then this is > > basically what COLLADA expects in exchange. This > > exchange is this > > different from the usual import/export process. It > > doesn't have to > > be this exact process, as this is only an example > > to us be more > > familiar. > > > > It seems a complete waste to not realize that LL > > has implemented > > the import process and physics refinery into their > > browser, and > > this very feature, though not fully automated as > > such, could be > > used to help move assets in-between grids/v-worlds. > > Since the > > import is from local basis, the authentication is > > not implemented. > > What's to stop to basically export to DAE format on > > the local > > storage, from one world, and continue to import > > that DAE into > > another grid. > > > > Note that the refineries may be proprietary. They > > may produce > > non-COLLADA formats (from DAE files) that are for > > optimal > > render/display capability of the software > > "client" (i.e. that the > > end-user has to view graphics). > > > > As with Google Earth and Sony HOME, they already > > have their assets > > conditioned and refined for those virtual worlds > > such that they > > can optimally display them. The key note is not the > > optimal > > display, as it is about being able to exchange and > > use in other > > virtual worlds. > > > > The DAE format does have extensive abilities, yet > > the goal of > > COLLADA is still to define the basic material, > > scripts, model, etc > > in the most portable format. The DAE may contain > > hybrid or > > specific formats that is stored in the extensions, > > so that custom > > objects are retained/transferred. > > > > If virtual worlds start to not agree upon how they > > store objects, > > I see COLLADA as the default format for digital > > asset exchange. > > > > > > > https://collada.org/mediawiki/index.php/COLLADA_FAQ#What_are_the_major_fe= atures_of_this_format.3F > > > > (Yes, we can put all inventory items in DAE format > > through the > > user-data and asset extensions, despite the format > > mainly being > > for 3D... just sayin') > > > > -- --- https://twitter.com/Dzonatas_Sol --- > > Web Development, Software Engineering, Virtual > > Reality, Consultant > > > > _______________________________________________ > > 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 > > > > > > > > > > > > -- > > --- https://twitter.com/Dzonatas_Sol --- > > Web Development, Software Engineering, Virtual Reality, > > Consultant > > > > > > > > > --000e0cd17298d34523049fce4bd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2011 at 6:19 PM, Mike Dickson <mike.dickson@hp.com> wrote:
On Thu, 2011-03-31 at 16:23 +0000, Morgaine wrote:
> There is no default format, and nowhere does VWRAP deal in
> SL-compatible grids.

That's actually for the contributors to define. =C2=A0There's= no reason we
can't choose to favor a direction that's compatible or at least
complimentary with existing practice.

>
> We are defining a services-oriented architecture which is nothing like=
> that of today's SL, and we cannot for a moment assume that SL will=
> adopt it in the future, as that is their choice, not ours.

You have a tendency to use "we" as this inclusive, everyone= agrees with
me so its a done deal concept. =C2=A0Again wether the group chooses to
leverage some of the concepts in SL (like LLSD for instance) is still
open to discussion. =C2=A0And protocol standard are what "we" are= about here.
Honestly if we fail to produce something that can "inter-operate"= with
SL at least to some degree I think the usefulness is minimal.



Mike, in the post you= quoted, I made no reference to what I personally would like to see.=C2=A0 = When I've used the word "we" and suggested that "we"= ; hold some view, it is because the participants of THIS GROUP have express= ed similar ideas in sufficient numbers for it to be an approximate majority= view, and often (but not always) unanimous.=C2=A0 If the "we" do= es not include yourself, it is because you were either not participating at= the time, or because you were in the minority on the topic at the time.
A default content format has never even been mentioned here unti= l Dzonatas' recent post, so when I wrote "There is no default form= at" it was a wholly accurate statement up to this point in time, and n= ot just my opinion.=C2=A0 And while we cannot foretell the future, that sta= tement will continue to be accurate until such a time as we've discusse= d the issue and decided that there will be a default format.=C2=A0 In the i= nterim, the fact that there is no default format specified, agreed, or even= discussed in VWRAP, stands, regardless of whether you or I would wish it o= therwise personally.

With regard to our relationship with SL, I don't think I need to ex= plain further the fact that we are not defining Linden Lab's future arc= hitecture, protocols, nor service concepts for them.=C2=A0 We don't hav= e that power, and they are under no obligation to take any notice of what w= e do, particularly now that they have officially withdrawn from the table.= =C2=A0 At best we can hope that our protocols are good enough and flexible = enough that a subset of them is useful for a proprietary service like Secon= d Life.

Our work is not being undertaken for their benefit however, but to serv= e the needs of the entire Internet community as per our mandate under the <= b>IETF Mission Statement.=C2=A0 If Linden Lab can benefit as well then = we have done a good job.

I hope that you are not disagreeing that "we are defining a servic= es-oriented architecture", so I'm not sure why you cited that sent= ence.=C2=A0 Having witnessed all the discussions since the start of AWG and= OGP and MMOX all the way through to VWRAP, I believe that we are completel= y unanimous that that is exactly what we are doing, so the "we" w= as, again, accurate.=C2=A0 If you don't think that we should be definin= g a services-oriented architecture, I have yet to read any objections in th= at regard.



=C2=A0
> The only partly-compatible VW frameworks over which we have a small > amount of influence are Opensim and realXtend (which uses Opensim
> server-side), because we can take their open source code and adapt it<= br> > to our protocols if we wish. =C2=A0In that sense, we could be said to = be
> defining an Opensim-compatible protocol, but never an SL-compatible > protocol. =C2=A0That would be a misapprehension.

This is all about implementation and isn't related to standards w= ork at
all. =C2=A0How what is produced here is implemented into a "product&qu= ot; (open
source or not) is irrelevant. And again, wether the protocol is
"SL-compatible" is open to discussion. =C2=A0You clearly have a b= ias away
from it but its not clear that's true for everyone.




That is incorrect= .=C2=A0 IETF drafts are not promoted to Internet standards unless they have= implementations --- again, the Mission Statement is worth reading.=C2=A0 &= quot;Rough consensus and running code" is a cardinal principle = highlighted in BCP 95.=C2=A0 Since we do not have the power to test our ide= as within Second Life, but only within open source frameworks like Opensim,= SL compatibility is beyond our reach until such a time as Linden Lab provi= des the required test implementation.=C2=A0 In the absence of that, only Op= ensim and/or realXtend compatibility is within our grasp because we can add= the "running code" there ourselves.

(Adding VWRAP protocol code to other open source VW frameworks such as = OpenWonderland, OpenCobalt, or Sirikata is potentially within our grasp as = well, but would require much more work and knowledge of those systems.)


=C2=A0
>
> We occasionally say that we are defining an SL-like data architecture,=
> but even that isn't really correct since VWRAP doesn't favor o= ne
> in-world content type over another. =C2=A0All content types are denote= d
> merely by a type tag and there is no standard set of content types
> required.
>
> So what is the real commonality between VWRAP and SL? =C2=A0Currently,= only
> LLSD is reasonably compatible with SL, although LLSD might well change=
> in more than just its name if we find the current spec not
> sufficiently powerful or lacking extensibility for our needs.

Again, your making assumptions based on what you'd like to see. = =C2=A0If you
really feel as strongly as you do that an alternative is appropriate I'= d
get to drafting some documents that describe it. =C2=A0Otherwise IMO,
standardizing around existing current practice is completely reasonable
and appropriate. =C2=A0Not that there isn't room for improvement of cou= rse.
But those improvements can be incremental in nature rather than
revolutionary.



What you refer= to as my "assumptions" are nothing more than rather obvious obse= rvations which have never been a matter of disagreement here.=C2=A0 Our tar= get for VWRAP testing is Opensim because, as I already explained, the SL pl= atform is outside of our control.=C2=A0 Indeed, Linden Lab has probably dis= claimed more than once any unwarranted expectation that they undertake to i= mplement VWRAP concepts, so it would be quite odd for us to insist that we = are designing a protocol that will be compatible with a new generation of S= L.

That is not something which we can claim, nor work towards.=C2=A0 The m= ost we can do is design a flexible protocol usable in many different deploy= ments (including commercial services), and hope that Linden Lab decides to = adopt it.=C2=A0 Much more important though is that our protocols serve the = much broader Internet community well, and that goes far beyond the needs of= one commercial provider.=C2=A0 That is a duty which we have undertaken by = being members of this IETF working group.


Morgaine.








=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D


On Thu, Mar 31, 2011 at 6= :19 PM, Mike Dickson <mike.dickson@hp.com> wrote:
On Thu, 2011-03-31 at 16:23 +0000, Morgaine wrote:
> There is no default format, and nowhere does VWRAP deal in
> SL-compatible grids.

That's actually for the contributors to define. =C2=A0There's= no reason we
can't choose to favor a direction that's compatible or at least
complimentary with existing practice.

>
> We are defining a services-oriented architecture which is nothing like=
> that of today's SL, and we cannot for a moment assume that SL will=
> adopt it in the future, as that is their choice, not ours.

You have a tendency to use "we" as this inclusive, everyone= agrees with
me so its a done deal concept. =C2=A0Again wether the group chooses to
leverage some of the concepts in SL (like LLSD for instance) is still
open to discussion. =C2=A0And protocol standard are what "we" are= about here.
Honestly if we fail to produce something that can "inter-operate"= with
SL at least to some degree I think the usefulness is minimal.

> The only partly-compatible VW frameworks over which we have a small > amount of influence are Opensim and realXtend (which uses Opensim
> server-side), because we can take their open source code and adapt it<= br> > to our protocols if we wish. =C2=A0In that sense, we could be said to = be
> defining an Opensim-compatible protocol, but never an SL-compatible > protocol. =C2=A0That would be a misapprehension.

This is all about implementation and isn't related to standards w= ork at
all. =C2=A0How what is produced here is implemented into a "product&qu= ot; (open
source or not) is irrelevant. And again, wether the protocol is
"SL-compatible" is open to discussion. =C2=A0You clearly have a b= ias away
from it but its not clear that's true for everyone.

>
> We occasionally say that we are defining an SL-like data architecture,=
> but even that isn't really correct since VWRAP doesn't favor o= ne
> in-world content type over another. =C2=A0All content types are denote= d
> merely by a type tag and there is no standard set of content types
> required.
>
> So what is the real commonality between VWRAP and SL? =C2=A0Currently,= only
> LLSD is reasonably compatible with SL, although LLSD might well change=
> in more than just its name if we find the current spec not
> sufficiently powerful or lacking extensibility for our needs.

Again, your making assumptions based on what you'd like to see. = =C2=A0If you
really feel as strongly as you do that an alternative is appropriate I'= d
get to drafting some documents that describe it. =C2=A0Otherwise IMO,
standardizing around existing current practice is completely reasonable
and appropriate. =C2=A0Not that there isn't room for improvement of cou= rse.
But those improvements can be incremental in nature rather than
revolutionary.

Mike

>
>
> Morgaine.
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
>
> On Thu, Mar 31, 2011 at 4:21 PM, Dzonatas Sol <dzonatas@gmail.com>
> wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Don't need to assume too much like tha= t, Morgaine; however, we
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 need something more of "trust domains= " defined and the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 example(s) I wrote about fit in well as le= ad-in. I stated
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 these use-cases specially to avoid the use= of terminology that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 now exists, and this leans towards the nee= d to center on
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 "trust domains." I see the use o= f current client/server-*
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 terminology continually to confuse us (eve= n if some like it,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 not all do). If we have to think about suc= h terminology for
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 more than 90 seconds each time then it nee= ds to change.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 My side-point was that VWs may have their = own object format in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 their world, and I'm thinking more the= n just the regions that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 exist now that the monolithic client conne= cts. Perhaps, others
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 only think about SL compatible grids, and = don't worry about
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the default format.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine wrote:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We've main= tained throughout that our protocols would
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be extensible = with regard to data formats, allowing
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 worlds and use= r expectations to evolve without
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 requiring prot= ocol redefinition.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the area of= meshes, it is very much to be expected
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that COLLADA w= ill figure strongly among the graphic
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 formats used (= particularly since it was chosen for the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 iED initiative= ), but it's not of any special interest
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to the VWRAP p= rotocols other than as a potential
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 content type.= =EF=BF=BD All we have to do is to make sure that
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 we label each = transfer with its appropriate type, and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possibly also = include other metadata that may be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 needed.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We're cert= ainly not standardizing what graphics are
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 used in virtua= l worlds, beyond assigning types where
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 they might not= yet exist.=EF=BF=BD Hardwiring them would be a
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recipe not for= extensibility but for stagnation.=EF=BF=BD
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Other bodies m= ay be standardizing which graphics
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 formats are us= ed, whereas we're trying to define
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 useful deploym= ent architectures and standardizing the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocols thro= ugh which they are accessed.
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Morgaine.
>
>
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Mar 31= , 2011 at 3:34 AM, Dzonatas Sol
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <dzonatas@gmail.com <mailto:dzonatas@gmail.com>>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 wrote:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= f we say the conditioner basically authenticates
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 or re-signs an=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a= sset from grid X to grid Y, and the refinery would
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 make sure the<= br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0p= hysics of the object described by the asset is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 translated fro= m
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t= he topology of grid X to the topology of grid Y,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 then this is > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b= asically what COLLADA expects in exchange. This
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 exchange is th= is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= ifferent from the usual import/export process. It
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 doesn't ha= ve to
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b= e this exact process, as this is only an example
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to us be more<= br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f= amiliar.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= t seems a complete waste to not realize that LL
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 has implemente= d
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t= he import process and physics refinery into their
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 browser, and > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t= his very feature, though not fully automated as
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such, could be=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= sed to help move assets in-between grids/v-worlds.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Since the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i= mport is from local basis, the authentication is
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 not implemente= d.
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0W= hat's to stop to basically export to DAE format on
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the local
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s= torage, from one world, and continue to import
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 that DAE into<= br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a= nother grid.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N= ote that the refineries may be proprietary. They
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 may produce > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0n= on-COLLADA formats (from DAE files) that are for
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 optimal
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r= ender/display capability of the software
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "client&q= uot; (i.e. that the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e= nd-user has to view graphics).
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A= s with Google Earth and Sony HOME, they already
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have their ass= ets
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c= onditioned and refined for those virtual worlds
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 such that they=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0c= an optimally display them. The key note is not the
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 optimal
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0d= isplay, as it is about being able to exchange and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 use in other > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v= irtual worlds.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0T= he DAE format does have extensive abilities, yet
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the goal of > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= OLLADA is still to define the basic material,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scripts, model= , etc
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0i= n the most portable format. The DAE may contain
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hybrid or
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0s= pecific formats that is stored in the extensions,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 so that custom=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0o= bjects are retained/transferred.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= f virtual worlds start to not agree upon how they
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 store objects,=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I= see COLLADA as the default format for digital
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 asset exchange= .
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://collada.org/mediawiki= /index.php/COLLADA_FAQ#What_are_the_major_features_of_this_format.3F >
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(= Yes, we can put all inventory items in DAE format
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through the > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u= ser-data and asset extensions, despite the format
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mainly being > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f= or 3D... just sayin')
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-= - =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0W= eb Development, Software Engineering, Virtual
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reality, Consu= ltant
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_= ______________________________________________
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0v= wrap mailing list
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= a href=3D"mailto:vwrap@ietf.org">vwrap@ietf.org <mailto:vwrap@ietf.org>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= a href=3D"https://www.ietf.org/mailman/listinfo/vwrap" target=3D"_blank">ht= tps://www.ietf.org/mailman/listinfo/vwrap
>
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --------------= ----------------------------------------------------------
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________= _________________________________
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap mailing = list
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vwrap@ietf.org
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/vwrap
>
>
>
>
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 --
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 --- https://twitter.com/Dzonatas_Sol ---
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Development, Software Engineering, Vir= tual Reality,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Consultant
>
>
>



--000e0cd17298d34523049fce4bd1--