From jhurliman@jhurliman.org Thu Jan 13 16:26: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 10C823A6C11 for ; Thu, 13 Jan 2011 16:26:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 83Q0FmXNRXOT for ; Thu, 13 Jan 2011 16:26:14 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E825F3A6BFB for ; Thu, 13 Jan 2011 16:26:13 -0800 (PST) Received: by fxm9 with SMTP id 9so2481929fxm.31 for ; Thu, 13 Jan 2011 16:28:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.72.197 with SMTP id n5mr81817faj.8.1294964916786; Thu, 13 Jan 2011 16:28:36 -0800 (PST) Received: by 10.223.101.129 with HTTP; Thu, 13 Jan 2011 16:28:36 -0800 (PST) Date: Thu, 13 Jan 2011 16:28:36 -0800 Message-ID: From: John Hurliman To: opensim-dev@lists.berlios.de, vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] Departing from virtual world development 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, 14 Jan 2011 00:26:15 -0000 Hi everyone, I'm sad to announce that I've decided to leave my position at Intel and the virtual world development sphere. This is my last official week, although I will be tying up development ends in the open source virtual world arena for a bit longer. 2011 marks my fifth year working on virtual worlds, from the beginning of libsecondlife/libopenmetaverse to the current OpenSim and SimianGrid development. Things have come a long way from reverse engineering the terrain packet encoding, and we now have a decentralized network of worlds and a protocol to link them together. My departure is the beginning of a new adventure into machine learning with an early stage startup. This endeavor is a full-time commitment and won't leave me enough time to contribute to OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any substantive way. Although I'm transitioning into a different area of technology, I'm still interested in the progress of the open metaverse and keeping in contact with everyone, and can be reached any time at this e-mail. On a related note, Intel's Virtual Worlds Infrastructure team is looking for a software researcher. Working with the VWI team has been great; I can't say enough good things about being a member of the team and advancing research in the virtual worlds and distributed computing field. Ping Mic Bowman if you are interested in working in the field in a research capacity. I am going to miss working with all of you, and I wish the best of luck to everyone in this area. I'll pop into IRC periodically to say hello. Best, John From dahliatrimble@gmail.com Thu Jan 13 16:52: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 5031028C0EE for ; Thu, 13 Jan 2011 16:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=0.400, 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 3vz5QMVtwc2T for ; Thu, 13 Jan 2011 16:52:39 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 50DD73A683B for ; Thu, 13 Jan 2011 16:52:38 -0800 (PST) Received: by wwa36 with SMTP id 36so2310537wwa.13 for ; Thu, 13 Jan 2011 16:55:01 -0800 (PST) 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=38W0H1DnNqQwg2oEMFgcyg82PDXkT1xUST1mZL9M1Pg=; b=uU7/ccM5WXGKkoiTRw0+mAjdbhxN6h8nkk8MlT7837svt6EcKUXK4/1n+TUr6zdJXu k3HruG9jjIseVcbDgmZfVBd717b6AYe5b7+wY04cv8ZlJHtCIe/RP5W73ADVCZ7DpMUA ZmjSrlnOshEMoBuC8tkjwDVMHEyimy7WAF7KI= 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=hVWvrLGvNeMDcK62fet7QpXXfPPGXweP5jYo+VwtY3Y4VKq+S5KitOGTD8cWpqd6AY urTSmC9eZAjUx1vPuu+TxOfHu9QwDDZdSS4CT7oJFZYno40EvrwqHIe29ZF0mAk7byHS /1zrVvqaJWLgYVuAwE9PNPv1r+wd3JkOX8sW8= MIME-Version: 1.0 Received: by 10.216.46.135 with SMTP id r7mr1194059web.21.1294966501228; Thu, 13 Jan 2011 16:55:01 -0800 (PST) Received: by 10.216.86.210 with HTTP; Thu, 13 Jan 2011 16:55:01 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Jan 2011 16:55:01 -0800 Message-ID: From: Dahlia Trimble To: John Hurliman Content-Type: multipart/alternative; boundary=001485f20c1a4d42ed0499c3e263 Cc: vwrap@ietf.org, opensim-dev@lists.berlios.de Subject: Re: [vwrap] Departing from virtual world development 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, 14 Jan 2011 00:52:41 -0000 --001485f20c1a4d42ed0499c3e263 Content-Type: text/plain; charset=ISO-8859-1 Best of luck in your new field. You will be sorely missed. I hope to hear more about your new endeavors, I've done some work in the field of machine vision and learning in the past and I understand what a rewarding field it can be. Please continue to stay in touch and let us know how you are doing and what research you can share. On Thu, Jan 13, 2011 at 4:28 PM, John Hurliman wrote: > Hi everyone, > > I'm sad to announce that I've decided to leave my position at Intel > and the virtual world development sphere. This is my last official > week, although I will be tying up development ends in the open source > virtual world arena for a bit longer. > > 2011 marks my fifth year working on virtual worlds, from the beginning > of libsecondlife/libopenmetaverse to the current OpenSim and > SimianGrid development. Things have come a long way from reverse > engineering the terrain packet encoding, and we now have a > decentralized network of worlds and a protocol to link them together. > > My departure is the beginning of a new adventure into machine learning > with an early stage startup. This endeavor is a full-time commitment > and won't leave me enough time to contribute to > OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any > substantive way. Although I'm transitioning into a different area of > technology, I'm still interested in the progress of the open metaverse > and keeping in contact with everyone, and can be reached any time at > this e-mail. > > On a related note, Intel's Virtual Worlds Infrastructure team is > looking for a software researcher. Working with the VWI team has been > great; I can't say enough good things about being a member of the team > and advancing research in the virtual worlds and distributed computing > field. Ping Mic Bowman if you are interested in working in the field > in a research capacity. > > I am going to miss working with all of you, and I wish the best of > luck to everyone in this area. I'll pop into IRC periodically to say > hello. > > Best, > John > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001485f20c1a4d42ed0499c3e263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Best of luck in your new field. You will be sorely missed.

I hope to= hear more about your new endeavors, I've done some work in the field o= f machine vision and learning in the past and I understand what a rewarding= field it can be. Please continue to stay in touch and let us know how you = are doing and what research you can share.


On Thu, Jan 13, 2011 at 4:28 PM, John Hu= rliman <jhu= rliman@jhurliman.org> wrote:
Hi everyone,

I'm sad to announce that I've decided to leave my position at Intel=
and the virtual world development sphere. This is my last official
week, although I will be tying up development ends in the open source
virtual world arena for a bit longer.

2011 marks my fifth year working on virtual worlds, from the beginning
of libsecondlife/libopenmetaverse to the current OpenSim and
SimianGrid development. Things have come a long way from reverse
engineering the terrain packet encoding, and we now have a
decentralized network of worlds and a protocol to link them together.

My departure is the beginning of a new adventure into machine learning
with an early stage startup. This endeavor is a full-time commitment
and won't leave me enough time to contribute to
OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any
substantive way. Although I'm transitioning into a different area of technology, I'm still interested in the progress of the open metaverse<= br> and keeping in contact with everyone, and can be reached any time at
this e-mail.

On a related note, Intel's Virtual Worlds Infrastructure team is
looking for a software researcher. Working with the VWI team has been
great; I can't say enough good things about being a member of the team<= br> and advancing research in the virtual worlds and distributed computing
field. Ping Mic Bowman if you are interested in working in the field
in a research capacity.

I am going to miss working with all of you, and I wish the best of
luck to everyone in this area. I'll pop into IRC periodically to say hello.

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

--001485f20c1a4d42ed0499c3e263-- From morgaine.dinova@googlemail.com Fri Jan 14 05:55: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 19E093A6B26 for ; Fri, 14 Jan 2011 05:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=0.167, 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 KiVun2ot-ure for ; Fri, 14 Jan 2011 05:55:51 -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 9D7503A6B7F for ; Fri, 14 Jan 2011 05:55:50 -0800 (PST) Received: by qyk34 with SMTP id 34so6420010qyk.10 for ; Fri, 14 Jan 2011 05:58:16 -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=aEHbPq/2zjs/RAYhEZGVN7wODHVYJqLj4sMWdIi/Twg=; b=i/vAM6l7ih+qZ+27N7ZKgN0Tm53MeWIpzvExgEjlPLrYlekULEwvBvI6ACXbApjASU Zpoyl3X1g2rGSeIXP7VhAjKzpbRtG2uaHrfOt/95zlghIBfn7FIbQ7UXWgkdH6O2pJzH cTVTg0wNQSWHTF7CgF8cgZih/mtRIXczp24EM= 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=r2hxFb0uClKEI0mCCX2sh5iFenYAHkFg/fSwjSnKjM4lJp80ERCElXTTFk21ynNxNw s0xe0USgW7asIPU+9CBAGl0U+VaWjGmE+CJU/xP7s7xjrPzO30hRhex1UiDenxLDaHV8 D3S1ByOchxYUDmqVKZ2MrbIFwpYa/btPn2xMM= MIME-Version: 1.0 Received: by 10.229.231.21 with SMTP id jo21mr708498qcb.119.1295013495763; Fri, 14 Jan 2011 05:58:15 -0800 (PST) Received: by 10.229.225.81 with HTTP; Fri, 14 Jan 2011 05:58:15 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 13:58:15 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org, opensim-dev@lists.berlios.de Content-Type: multipart/alternative; boundary=0016e686cd6c64f22e0499ced3ec Subject: Re: [vwrap] [Opensim-dev] Departing from virtual world development 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, 14 Jan 2011 13:55:54 -0000 --0016e686cd6c64f22e0499ced3ec Content-Type: text/plain; charset=ISO-8859-1 All the best to you, John, in your new occupation and venture. I think it's not an overstatement to say that you've been a major inspiration to the technical communities in our VW area, and I am sure that you will have a similar impact in your next line of work. Machine learning is one of those disciplines with boundless spheres of application, and it wouldn't surprise me if it brings you back to virtual worlds in due course. Or at least I hope so. :-) All the best for the future, and I look forward very much to your occasional staying in touch. Morgaine. =============================== On Fri, Jan 14, 2011 at 12:28 AM, John Hurliman wrote: > Hi everyone, > > I'm sad to announce that I've decided to leave my position at Intel > and the virtual world development sphere. This is my last official > week, although I will be tying up development ends in the open source > virtual world arena for a bit longer. > > 2011 marks my fifth year working on virtual worlds, from the beginning > of libsecondlife/libopenmetaverse to the current OpenSim and > SimianGrid development. Things have come a long way from reverse > engineering the terrain packet encoding, and we now have a > decentralized network of worlds and a protocol to link them together. > > My departure is the beginning of a new adventure into machine learning > with an early stage startup. This endeavor is a full-time commitment > and won't leave me enough time to contribute to > OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any > substantive way. Although I'm transitioning into a different area of > technology, I'm still interested in the progress of the open metaverse > and keeping in contact with everyone, and can be reached any time at > this e-mail. > > On a related note, Intel's Virtual Worlds Infrastructure team is > looking for a software researcher. Working with the VWI team has been > great; I can't say enough good things about being a member of the team > and advancing research in the virtual worlds and distributed computing > field. Ping Mic Bowman if you are interested in working in the field > in a research capacity. > > I am going to miss working with all of you, and I wish the best of > luck to everyone in this area. I'll pop into IRC periodically to say > hello. > > Best, > John > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > --0016e686cd6c64f22e0499ced3ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All the best to you, John, in your new occupation and venture.=A0 I think i= t's not an overstatement to say that you've been a major inspiratio= n to the technical communities in our VW area, and I am sure that you will = have a similar impact in your next line of work.

Machine learning is one of those disciplines with boundless spheres of = application, and it wouldn't surprise me if it brings you back to virtu= al worlds in due course.=A0 Or at least I hope so. :-)

All the best = for the future, and I look forward very much to your occasional staying in = touch.


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 Fri, Jan 14, 2011 at 12:28 AM, John Hurliman <jhurliman@jhurliman= .org> wrote:
Hi everyone,

I'm sad to announce that I've decided to leave my position at Intel=
and the virtual world development sphere. This is my last official
week, although I will be tying up development ends in the open source
virtual world arena for a bit longer.

2011 marks my fifth year working on virtual worlds, from the beginning
of libsecondlife/libopenmetaverse to the current OpenSim and
SimianGrid development. Things have come a long way from reverse
engineering the terrain packet encoding, and we now have a
decentralized network of worlds and a protocol to link them together.

My departure is the beginning of a new adventure into machine learning
with an early stage startup. This endeavor is a full-time commitment
and won't leave me enough time to contribute to
OpenSim/SimianGrid/libOpenMetaverse/Fortis/Aurora/VWRAP in any
substantive way. Although I'm transitioning into a different area of technology, I'm still interested in the progress of the open metaverse<= br> and keeping in contact with everyone, and can be reached any time at
this e-mail.

On a related note, Intel's Virtual Worlds Infrastructure team is
looking for a software researcher. Working with the VWI team has been
great; I can't say enough good things about being a member of the team<= br> and advancing research in the virtual worlds and distributed computing
field. Ping Mic Bowman if you are interested in working in the field
in a research capacity.

I am going to miss working with all of you, and I wish the best of
luck to everyone in this area. I'll pop into IRC periodically to say hello.

Best,
John
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.d= e
https://lists.berlios.de/mailman/listinfo/opensim-dev

--0016e686cd6c64f22e0499ced3ec-- From barryleiba@gmail.com Fri Jan 14 09:11: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 9031228C11B for ; Fri, 14 Jan 2011 09:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.754 X-Spam-Level: X-Spam-Status: No, score=-102.754 tagged_above=-999 required=5 tests=[AWL=0.223, 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 hPz4rbFVjf5B for ; Fri, 14 Jan 2011 09:11:11 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 788F228C10F for ; Fri, 14 Jan 2011 09:11:10 -0800 (PST) Received: by iyi42 with SMTP id 42so2932035iyi.31 for ; Fri, 14 Jan 2011 09:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=FU2opha2X8IQmsBNDb0SpA0tkvlnbBiPLui1UnG4AHw=; b=btEqVsm6ZWsUlHBUFMxjb0W6FdLtdBVH1jjsOzE58hGgRlBcr2uv9kjKpnJluQ2Doy gMZJSNI7pTmln/j0LwAkFT/CtbcIlGE+oRrAdt67FEk8xOQGUOxVqvC5BsRQcc6O7vOC J//hBqT2DDJEuIRo/dw+XlXlwKMCHiP/lKLwk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=eFCdB1OA3C1zLehvdOva6FA2yn0DlJ6re7DSMp9WeB0qSb6N6uOZ4YTwOsCBPDy1Fr IfJi8I7w9x3o05/MkgN9aRPpglzW/dppmLxp3NGE5RvN2wJslWpuCKkh/XZT1IrvOIWk 2HSZoi0IqYf5ufac9JH9jqeoxy/MrNi3RBnH4= MIME-Version: 1.0 Received: by 10.231.200.138 with SMTP id ew10mr966873ibb.59.1295025216173; Fri, 14 Jan 2011 09:13:36 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Fri, 14 Jan 2011 09:13:36 -0800 (PST) Date: Fri, 14 Jan 2011 12:13:36 -0500 X-Google-Sender-Auth: TYV5uuPc85IX2CACn9bpbHQ_A34 Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [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, 14 Jan 2011 17:11:12 -0000 Good day, all. The chairs and area directors have been talking about the status and future of the VWRAP working group. Owing to changes in focus and commitment by both companies and individuals, things have been languishing, and it's not clear to us that we have what we need to get the chartered work done. The introduction document looked close to ready, until some controversy on its content and direction brewed, and the result of that discussion was inconclusive. The normative drafts that have seen some implementation (type system, launch message, etc.) also appear nearly technically complete, but some issues have been identified and not resolved by subsequent discussion, consensus, and editing. At this point, the mailing list has been too quiet for too long, all the draft documents have expired, and we need to make a decision about what to do. The chairs and ADs see three possibilities: 1. Find new document editors, pick up the chartered work with the existing document base, and get moving again. Get the introduction document finished by the end of February, and make progress on the others. 2. Come to consensus on significant changes to the direction of the VWRAP specs, find new document editors, revamp the introduction document, and get that finished, or substantially so, by the end of February. Have some clear consensus, clear direction, and enthusiasm to continue. Consider rechartering, if the direction has changed enough to require that. 3. Accept that we no longer have enough core participation, consensus, and enthusiasm to make progress, and close the working group. Future work in the virtual world area could charter a new working group later. Note that options 1 and 2 both require that we demonstrate sufficient energy and participation to really get work done and to demonstrate consensus. That means that we need people to commit to writing/editing documents, actively discussing the technical issues with the goal of reaching consensus on the content of the documents, and, importantly, reviewing documents and showing that we have consensus. Three or four participants isn't enough, and conflicting ideas that can't be resolved into a consensus-based position won't work. What say you, VWRAP participants? Can we pick up the work and make progress? Shall we close the working group, and perhaps consider something in future? Do you favour options 1, 2, or 3? Or do you see an alternative option you'd like to bring up? Barry and Joshua, VWRAP chairs From ohmeadhbh@gmail.com Fri Jan 14 09:55: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 DE6A128C113 for ; Fri, 14 Jan 2011 09:55:54 -0800 (PST) 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 CzPv92Vi1PbT for ; Fri, 14 Jan 2011 09:55:53 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6D2E828C108 for ; Fri, 14 Jan 2011 09:55:52 -0800 (PST) Received: by qyj19 with SMTP id 19so3402723qyj.10 for ; Fri, 14 Jan 2011 09:58:18 -0800 (PST) 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=pVktaRJfojecIZCX8/APAvLc5rry4dYOzYvICsFTbjs=; b=u/hiwzrk9IWUUyo/XbFInIVCQJObbyMX902gtec14trPyf8OZGLJbS/A4wziwBtxcd lWQ3FOoomVcOMvjlxfHZqZhpu+gDtKNfxjk4k4MtoIU6wP2Qfum48FbK7i4n9qMpMxv9 t0UypKMZuHJ7S+PwokEwfzJ4/aC2PRtI4YZ+4= 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=QCB3Ib0IuCE4MiW66QGO920rxNV2wgh2Pl14yjukRMe7dTx9Kx+3TIo4rS0lVSlOeh hTORqRyV82BdZItPTD/ZuSbE7l91oWdkSY1dcw3CKb0Sdn3/dRSJ3hV/B8izn+NWKYL0 VxIdDoNkfHpX6K0BcOwLSmli56Xtb0ExVxtnY= Received: by 10.229.88.207 with SMTP id b15mr936071qcm.34.1295027897683; Fri, 14 Jan 2011 09:58:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.99.21 with HTTP; Fri, 14 Jan 2011 09:57:57 -0800 (PST) In-Reply-To: References: From: Meadhbh Hamrick Date: Fri, 14 Jan 2011 09:57:57 -0800 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: Fri, 14 Jan 2011 17:55:55 -0000 hey barry, comments on options: option 1 : find new editors as the author of the overwhelming majority of words in VWRAP IDs, i would LOVE to hand off responsibility for everything except the type system to someone else. the most recent drafts of the IDs are in SVN, and i'm happy to email them to the list or to individuals. i am (more than) happy to discuss the motivations or historical context of various "controversial" phrases. i have some personal stake in the type system since my company is using it for a commercial service. i have numerous issues with the existing type system draft, many are documented in a blog post at: http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.html the changes i'm calling for are kind of extensive, so i changed the name of my type system to DSD (dynamic structured data.) for the last couple of months, the sl8.us service and a couple other services we haven't announced have been using the X-application/dsd+xml and X-application/dsd+json content type. we would like to remove the X- from the front of that since we're developing types that are of general use, implemented using open source software. if we can't find another editor for VWRAP, i'm happy to publish DSD as an individual / informational RFC for the purpose of registering the mime type and to document DSD's use. if we do find another editor and this working group continues, i would yield to group consensus on whether we want to move away from LLSD to DSD. either way, i should finish the documentation i've been saying i would finish for the last three months. option 2 : recharter go for it! (assuming there's consensus.) again, because i'm barred from contributing code to the OpenSim core and i have no interest in maintaining a fork, i'm not personally interested in participating in standardizing hypergrid. but if anyone from the OpenSim group wants to document it in this forum, i'm happy to lend advice, encouragement and whatever minor work the OpenSim peeps think i can contribute without introducing intellectual property weirdness. option 3 : death, coma or hibernation as a casual observer, i'm putting my money on this option. Linden's no longer supporting open virtual worlds. Smithee, et all (my current employer) is only interested in a subsection of the VWRAP work. IBM & Intel seems to be focusing on other things. I know we participate here as individuals, but at the end of the day, it's a lot easier to participate if someone is paying you to do so. the core hypergrid folk always regarded this group as a "linden marketing stunt," so i don't know if there's much interest from that corner to recharter. the OpenSim core, for better or worse, seems to be focused on their implementation, not on protocol standardization. maybe that will change in the future. maybe in a few years there'll be renewed interest in this domain. if there's a snowball's chance in hades that work could get completed, i'll probably try to participate. anyway... i wish everyone here good luck. i think there were some great people here who contributed some great ideas, even if i didn't agree with all of them. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, Jan 14, 2011 at 9:13 AM, Barry Leiba wrot= e: > Good day, all. > The chairs and area directors have been talking about the status and > future of the VWRAP working group. =A0Owing to changes in focus and > commitment by both companies and individuals, things have been > languishing, and it's not clear to us that we have what we need to get > the chartered work done. =A0The introduction document looked close to > ready, until some controversy on its content and direction brewed, and > the result of that discussion was inconclusive. =A0The normative drafts > that have seen some implementation (type system, launch message, etc.) > also appear nearly technically complete, but some issues have been > identified and not resolved by subsequent discussion, consensus, and > editing. > > At this point, the mailing list has been too quiet for too long, all > the draft documents have expired, and we need to make a decision about > what to do. > > The chairs and ADs see three possibilities: > > 1. Find new document editors, pick up the chartered work with the > existing document base, and get moving again. =A0Get the introduction > document finished by the end of February, and make progress on the > others. > > 2. Come to consensus on significant changes to the direction of the > VWRAP specs, find new document editors, revamp the introduction > document, and get that finished, or substantially so, by the end of > February. =A0Have some clear consensus, clear direction, and enthusiasm > to continue. =A0Consider rechartering, if the direction has changed > enough to require that. > > 3. Accept that we no longer have enough core participation, consensus, > and enthusiasm to make progress, and close the working group. =A0Future > work in the virtual world area could charter a new working group > later. > > Note that options 1 and 2 both require that we demonstrate sufficient > energy and participation to really get work done and to demonstrate > consensus. =A0That means that we need people to commit to > writing/editing documents, actively discussing the technical issues > with the goal of reaching consensus on the content of the documents, > and, importantly, reviewing documents and showing that we have > consensus. =A0Three or four participants isn't enough, and conflicting > ideas that can't be resolved into a consensus-based position won't > work. > > What say you, VWRAP participants? =A0Can we pick up the work and make > progress? =A0Shall we close the working group, and perhaps consider > something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you se= e > an alternative option you'd like to bring up? > > Barry and Joshua, VWRAP chairs > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From kmancuso@gmail.com Fri Jan 14 10:13: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 A0C673A6C76 for ; Fri, 14 Jan 2011 10:13:06 -0800 (PST) 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 iKA+TyCzhuXU for ; Fri, 14 Jan 2011 10:13:05 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id B58D93A6C1D for ; Fri, 14 Jan 2011 10:13:05 -0800 (PST) Received: by iyi42 with SMTP id 42so2990428iyi.31 for ; Fri, 14 Jan 2011 10:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:from:date:message-id :subject:to:content-type; bh=Luj4q+9xlJZSuf1PD6fGa1MMhnQp/kI7uALTeJnyhAw=; b=Cbv38E+WYOdAnoRkxk1SXOr6Y5zEJgIZ/05wlLMpZDbaeZmsdoEV6eC9G0JewPcAno D0jCFc7YNBZMaf3lO4wTNFw0z8UUr2VAQBHa6sA+xVydWls84rgxdlWJkbK81fq13w1o sapV5qT6ySYYHPcqydTYxaCJci7uQ6b1vAP/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:from:date:message-id:subject:to:content-type; b=UCR/NQdYDGN3R+ykZWNAQguM0UZRcYz9slJnI3PmLdF6VAg8P4bXTt8l7Et2jy0vyl T3kT3e/VkggywcrHKTBaR+s+hoyZkWIQluJE58MjxZwoSk/R3Chn8fsFeb3g+WDrhPah YCfaqugp3jv5lJeBRzGlreKUfetQWzQd1w4EM= Received: by 10.231.19.131 with SMTP id a3mr1040649ibb.85.1295028931542; Fri, 14 Jan 2011 10:15:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.30.77 with HTTP; Fri, 14 Jan 2011 10:15:11 -0800 (PST) From: Katherine Mancuso Date: Fri, 14 Jan 2011 10:15:11 -0800 Message-ID: To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00221532cba4703f730499d26b62 Subject: [vwrap] Status and future of the VWRAP working group 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, 14 Jan 2011 18:13:06 -0000 --00221532cba4703f730499d26b62 Content-Type: text/plain; charset=ISO-8859-1 Like Meadhbh, I am not terribly optimistic that we can come to consensus on continuing, because we suffer from a problem of not enough willing draft editors and implementers. I honestly think that the use case for virtual world interoperability at this point is not strong enough for standardization to be the correct choice. However, I am willing to continue being the accessibility professional contributing to the group no matter which decision is made. It is not quite clear whether my work with the W3C-WAI UAAG continues if this working group founders, but if anyone who I haven't already talked with has serious interest in being an implementer focusing on accessibility features for viewers (with a universal design bent towards making viewers which are more usable for everyone) OR someone who understands virtual world viewers & the server-client relationship in VWRAP very well and wants to be a go-to technical resource for me in the case that this work does go forward, please do contact me. Depending on how things shake out, if we could have a document editor who's not an author and just compiles feedback into drafts and is not an especially technical person on their own, I might be willing to do that kind of document management. This would mean that folks would have to submit very specific line by line changes to the drafts and I would do only collating & polishing for style, not technical polishing, and we would likely need a technical editor to make sure the final drafts make full technical sense too. Katherine --00221532cba4703f730499d26b62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Like Meadhbh, I am not terribly optimistic that we can come to consensus on= continuing, because we suffer from a problem of not enough willing draft e= ditors and implementers.=A0 I honestly think that the use case for virtual = world interoperability at this point is not strong enough for standardizati= on to be the correct choice.

However, I am willing to continue being the accessibility professional = contributing to the group no matter which decision is made.=A0 It is not qu= ite clear whether my work with the W3C-WAI UAAG continues if this working g= roup founders, but if anyone who I haven't already talked with has seri= ous interest in being an implementer focusing on accessibility features for= viewers (with a universal design bent towards making viewers which are mor= e usable for everyone) OR someone who understands virtual world viewers &am= p; the server-client relationship in VWRAP very well and wants to be a go-t= o technical resource for me in the case that this work does go forward, ple= ase do contact me.

Depending on how things shake out, if we could have a document editor w= ho's not an author and just compiles feedback into drafts and is not an= especially technical person on their own, I might be willing to do that ki= nd of document management. This would mean that folks would have to submit = very specific line by line changes to the drafts and I would do only collat= ing & polishing for style, not technical polishing, and we would likely= need a technical editor to make sure the final drafts make full technical = sense too.

Katherine
--00221532cba4703f730499d26b62-- From morgaine.dinova@googlemail.com Fri Jan 14 12:23: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 BA67B3A6BD2 for ; Fri, 14 Jan 2011 12:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.152, 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 IUTS91yBrM5s for ; Fri, 14 Jan 2011 12:23:04 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 87FAB3A6BCE for ; Fri, 14 Jan 2011 12:23:04 -0800 (PST) Received: by qyj19 with SMTP id 19so3544292qyj.10 for ; Fri, 14 Jan 2011 12:25:29 -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:content-type; bh=B+7J8eZLCMe1EJdChFH1WpZMi7mBDYoUKpvBt7po4WY=; b=QN5gkkTiTmQQYz658T54wNRWkx9vMTMYg/3Ewo4WuH7luOsbpFDazYvmvnP0jNuTHn nUcZJj1sLu+my310PT97v9fxFlapuR7PJWzXoYkQHtiGZjmw/SnU2XMdz307aSFOvx0C XK1YMhQIm27pGeqrQvdfpKnAvBAv1HVNEh17c= 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=o+4THGDebseyLP+VVxqrqqe74S53jzlsaVNmQLeYasYm0wFhtvd/WULydB9N4gd0gz 2ue5+0p7BnuQZ27Gx5WaeBswHWgrl7sRgbT1eDz6hhpc/1OVUfKEewH0PXBMgT6jw7u8 m79H/wzCtq3bGv3KaXINMZ5n+jiI3pU9wVjIY= MIME-Version: 1.0 Received: by 10.229.231.21 with SMTP id jo21mr1034228qcb.119.1295036727836; Fri, 14 Jan 2011 12:25:27 -0800 (PST) Received: by 10.229.225.81 with HTTP; Fri, 14 Jan 2011 12:25:27 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Jan 2011 20:25:27 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e686cd6c22416c0499d43c37 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, 14 Jan 2011 20:23:06 -0000 --0016e686cd6c22416c0499d43c37 Content-Type: text/plain; charset=ISO-8859-1 As a point of information and perhaps a call for patience, the period of low progress coincided with December, a month in which traditionally nothing gets done (in the West) for reasons that need no explanation. In October/November, a number of us embarked on a collective edit of a wiki page as *input* to the next version of an Intro draft, starting from scratch. This was a direct followup to our rather epic list discussions of September precipitated by Diva, which had finally made explicit what had been known implicitly from the beginning of OGPX/VWRAP, but which was never openly expressed until then: that some central documents produced by the original OGP designers were completely out of step with this group's near-unanimous desire to provide a protocol foundation for interop *between*virtual worlds. September was a watershed month in that respect, and change was inevitable after that point. We're not going back (I believe) to a destructive worldview that denies a central goal of the group, a goal which, it's worth stating, is wholly aligned with the IETF Mission Statement in respect of interoperation on the Internet. Yes, it does mean that (some) previous drafts have become not only expired but actually wrong. Yes, it does mean that our schedule is unlikely to be met, but then the schedule was a result of commercial interests more than anything else. It shouldn't come as a big surprise that earlier business-driven deadlines became inappropriate after the commercial interest disappeared. But IETF WG participants are individuals rather than corporations, and loss of commercial interest does not necessarily mean that participants' interest has disappeared as well. I can only speak for myself, but I am still very keen to work towards a standards track specification to underpin interop between VWs. I think this is important work, because even if it does not take the world by storm, it provides a very valuable Internet community focus for protocol design efforts in this area, and most importantly, an *open participatory* focus. There is no shortage of less participatory groups dealing with VW interop, each doing whatever their main designer thinks is the right thing, but an IETF group is "constitutionally" open, and that is healthy. So what's our future? Well assuming that the IETF is flexible on deadlines, I don't see a huge problem. It's always hard to start the initial version of something, but people tend to contribute more easily once a framework exists, ready to be improved. And documents are like software: they're ready when they're ready. Extra resourcing does not necessarily speed up the process, and whipping is probably the wrong approach for accelerating intellectual goals. :P Perhaps we need to change our focus a little. We have been working top-down (service orchestration through caps) and bottom-up (LLSD), but there has been no meat in the sandwich: for example, we've left asset services languishing as little more than a cloud in a mental picture, despite asset services being the very core of interop between worlds. I think there is much work to be done, many good reasons for doing it, and no reason to force the pace. Indeed, the best standards are those that reflect *de facto* mechanisms in use in the industry, and the "VW industry" is very actively working on methods that we can incorporate into our specifications. As an example, the VWRAP emphasis on services using Web infrastructure has become quite popular as a general approach, which tells me that we were on the right track. In summary, I see change happening in VWRAP, but no reason for despair. John's exit from the VW arena to pursue different interests is undoubtedly a setback for us, as he was leading the exploration of protocols consistent with the VWRAP model and his enthusiasm knew no bounds. But Opensim, realXtend and many other groups continue to work on protocols, and so a working group that is able to assimilate their ideas will be central for interoperation between them. If our options are the three presented, then I support #2, and I see no reason for doom and gloom. :-) PS. The wiki page for the new Intro document which I mentioned earlier is available here --- http://vwrap-playpen.wikispaces.com/New+VWRAP+intro+draft. Editing is of course open to all VWRAP contributors (I believe David is coordinating access). This pre-draft has the purpose of overcoming a major failing in VWRAP so far: drafts were written, extensive discussions were held, and the comments were totally ignored by the draft writers and never made it into subsequent versions. The interactive wiki approach overcomes that (human) problem by technical means. The general goal is to put us on the right road for an official IETF draft that reflects the group's desired direction on interop. Previously we were on the wrong road entirely. Morgaine. PS. Happy New Year to all ! :-) ========================== On Fri, Jan 14, 2011 at 5:13 PM, Barry Leiba wrote: > Good day, all. > The chairs and area directors have been talking about the status and > future of the VWRAP working group. Owing to changes in focus and > commitment by both companies and individuals, things have been > languishing, and it's not clear to us that we have what we need to get > the chartered work done. The introduction document looked close to > ready, until some controversy on its content and direction brewed, and > the result of that discussion was inconclusive. The normative drafts > that have seen some implementation (type system, launch message, etc.) > also appear nearly technically complete, but some issues have been > identified and not resolved by subsequent discussion, consensus, and > editing. > > At this point, the mailing list has been too quiet for too long, all > the draft documents have expired, and we need to make a decision about > what to do. > > The chairs and ADs see three possibilities: > > 1. Find new document editors, pick up the chartered work with the > existing document base, and get moving again. Get the introduction > document finished by the end of February, and make progress on the > others. > > 2. Come to consensus on significant changes to the direction of the > VWRAP specs, find new document editors, revamp the introduction > document, and get that finished, or substantially so, by the end of > February. Have some clear consensus, clear direction, and enthusiasm > to continue. Consider rechartering, if the direction has changed > enough to require that. > > 3. Accept that we no longer have enough core participation, consensus, > and enthusiasm to make progress, and close the working group. Future > work in the virtual world area could charter a new working group > later. > > Note that options 1 and 2 both require that we demonstrate sufficient > energy and participation to really get work done and to demonstrate > consensus. That means that we need people to commit to > writing/editing documents, actively discussing the technical issues > with the goal of reaching consensus on the content of the documents, > and, importantly, reviewing documents and showing that we have > consensus. Three or four participants isn't enough, and conflicting > ideas that can't be resolved into a consensus-based position won't > work. > > What say you, VWRAP participants? Can we pick up the work and make > progress? Shall we close the working group, and perhaps consider > something in future? Do you favour options 1, 2, or 3? Or do you see > an alternative option you'd like to bring up? > > Barry and Joshua, VWRAP chairs > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016e686cd6c22416c0499d43c37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As a point of information and perhaps a call for patience, the period of lo= w progress coincided with December, a month in which traditionally nothing = gets done (in the West) for reasons that need no explanation.

In Oct= ober/November, a number of us embarked on a collective edit of a wiki page = as input to the next version of an Intro draft, starting from= scratch.=A0 This was a direct followup to our rather epic list discussions= of September precipitated by Diva, which had finally made explicit what ha= d been known implicitly from the beginning of OGPX/VWRAP, but which was nev= er openly expressed until then:=A0 that some central documents produced by = the original OGP designers were completely out of step with this group'= s near-unanimous desire to provide a protocol foundation for interop = between virtual worlds.

September was a watershed month in that respect, and change was inevita= ble after that point.=A0 We're not going back (I believe) to a destruct= ive worldview that denies a central goal of the group, a goal which, it'= ;s worth stating, is wholly aligned with the IETF Mission Statement in resp= ect of interoperation on the Internet.

Yes, it does mean that (some) previous drafts have become not only expi= red but actually wrong.=A0 Yes, it does mean that our schedule is unlikely = to be met, but then the schedule was a result of commercial interests more = than anything else.=A0 It shouldn't come as a big surprise that earlier= business-driven deadlines became inappropriate after the commercial intere= st disappeared.=A0 But IETF WG participants are individuals rather than cor= porations, and loss of commercial interest does not necessarily mean that p= articipants' interest has disappeared as well.

I can only speak for myself, but I am still very keen to work towards a= standards track specification to underpin interop between VWs.=A0 I think = this is important work, because even if it does not take the world by storm= , it provides a very valuable Internet community focus for protocol design = efforts in this area, and most importantly, an open participatory fo= cus.=A0 There is no shortage of less participatory groups dealing with VW i= nterop, each doing whatever their main designer thinks is the right thing, = but an IETF group is "constitutionally" open, and that is healthy= .

So what's our future?=A0 Well assuming that the IETF is flexible on= deadlines, I don't see a huge problem.=A0 It's always hard to star= t the initial version of something, but people tend to contribute more easi= ly once a framework exists, ready to be improved.=A0 And documents are like= software:=A0 they're ready when they're ready.=A0 Extra resourcing= does not necessarily speed up the process, and whipping is probably the wr= ong approach for accelerating intellectual goals. :P

Perhaps we need to change our focus a little.=A0 We have been working t= op-down (service orchestration through caps) and bottom-up (LLSD), but ther= e has been no meat in the sandwich:=A0 for example, we've left asset se= rvices languishing as little more than a cloud in a mental picture, despite= asset services being the very core of interop between worlds.

I think there is much work to be done, many good reasons for doing it, = and no reason to force the pace.=A0 Indeed, the best standards are those th= at reflect de facto mechanisms in use in the industry, and the "= ;VW industry" is very actively working on methods that we can incorpor= ate into our specifications.=A0 As an example, the VWRAP emphasis on servic= es using Web infrastructure has become quite popular as a general approach,= which tells me that we were on the right track.

In summary, I see change happening in VWRAP, but no reason for despair.= =A0 John's exit from the VW arena to pursue different interests is undo= ubtedly a setback for us, as he was leading the exploration of protocols co= nsistent with the VWRAP model and his enthusiasm knew no bounds.=A0 But Ope= nsim, realXtend and many other groups continue to work on protocols, and so= a working group that is able to assimilate their ideas will be central for= interoperation between them.

If our options are the three presented, then I support #2, and I see no= reason for doom and gloom. :-)

PS. The wiki page for the new Intro = document which I mentioned earlier is available here --- http://vwrap-playpen.wi= kispaces.com/New+VWRAP+intro+draft .=A0 Editing is of course open to al= l VWRAP contributors (I believe David is coordinating access).=A0 This pre-= draft has the purpose of overcoming a major failing in VWRAP so far:=A0 dra= fts were written, extensive discussions were held, and the comments were to= tally ignored by the draft writers and never made it into subsequent versio= ns.=A0 The interactive wiki approach overcomes that (human) problem by tech= nical means.=A0 The general goal is to put us on the right road for an offi= cial IETF draft that reflects the group's desired direction on interop.= =A0 Previously we were on the wrong road entirely.


Morgaine.

PS. Happy New Year to all ! :-)



=3D= =3D=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 Fri, Jan 14, 2011 at 5:13 PM, Barry L= eiba <barry= leiba@computer.org> wrote:
Good day, all. The chairs and area directors have been talking about the status and
future of the VWRAP working group. =A0Owing to changes in focus and
commitment by both companies and individuals, things have been
languishing, and it's not clear to us that we have what we need to get<= br> the chartered work done. =A0The introduction document looked close to
ready, until some controversy on its content and direction brewed, and
the result of that discussion was inconclusive. =A0The normative drafts
that have seen some implementation (type system, launch message, etc.)
also appear nearly technically complete, but some issues have been
identified and not resolved by subsequent discussion, consensus, and
editing.

At this point, the mailing list has been too quiet for too long, all
the draft documents have expired, and we need to make a decision about
what to do.

The chairs and ADs see three possibilities:

1. Find new document editors, pick up the chartered work with the
existing document base, and get moving again. =A0Get the introduction
document finished by the end of February, and make progress on the
others.

2. Come to consensus on significant changes to the direction of the
VWRAP specs, find new document editors, revamp the introduction
document, and get that finished, or substantially so, by the end of
February. =A0Have some clear consensus, clear direction, and enthusiasm
to continue. =A0Consider rechartering, if the direction has changed
enough to require that.

3. Accept that we no longer have enough core participation, consensus,
and enthusiasm to make progress, and close the working group. =A0Future
work in the virtual world area could charter a new working group
later.

Note that options 1 and 2 both require that we demonstrate sufficient
energy and participation to really get work done and to demonstrate
consensus. =A0That means that we need people to commit to
writing/editing documents, actively discussing the technical issues
with the goal of reaching consensus on the content of the documents,
and, importantly, reviewing documents and showing that we have
consensus. =A0Three or four participants isn't enough, and conflicting<= br> ideas that can't be resolved into a consensus-based position won't<= br> work.

What say you, VWRAP participants? =A0Can we pick up the work and make
progress? =A0Shall we close the working group, and perhaps consider
something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you see<= br> an alternative option you'd like to bring up?

Barry and Joshua, VWRAP chairs
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e686cd6c22416c0499d43c37-- From lopes@ics.uci.edu Fri Jan 14 17:20:45 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 0C7823A6CE5 for ; Fri, 14 Jan 2011 17:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.458, 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 kBawuN5qLEYO for ; Fri, 14 Jan 2011 17:20:43 -0800 (PST) Received: from colin-baker-v0.ics.uci.edu (colin-baker-v0.ics.uci.edu [128.195.1.153]) by core3.amsl.com (Postfix) with ESMTP id B3C043A6CE2 for ; Fri, 14 Jan 2011 17:20:43 -0800 (PST) Received: from [169.234.246.223] (susan-foreman.ics.uci.edu [128.195.1.134]) (authenticated bits=0) by colin-baker-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id p0F1N4Wf021542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 14 Jan 2011 17:23:04 -0800 Message-ID: <4D30F6FE.4020805@ics.uci.edu> Date: Fri, 14 Jan 2011 17:23:10 -0800 From: Cristina Videira Lopes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 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 X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information X-ICS-MailScanner-ID: p0F1N4Wf021542 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.363, required 5, autolearn=disabled, ALL_TRUSTED -1.44, TW_VW 0.08) X-ICS-MailScanner-From: lopes@ics.uci.edu 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, 15 Jan 2011 01:20:45 -0000 I'm leaning towards #2 and #3 simultaneously :) Let me explain. The goal of achieving virtual world interoperability always felt like a niche goal to me, but one that, given the nature of these applications, touched on a couple of more foundational issues: single sign ons and Web services security -- in short, federations that cross enterprise boundaries. There is a variety of implementations for SSOs out there, more recently the one in the Hypergrid, and a variety of ways of securing Web services. But no standards that I know of -- apart from the SOAP stuff. Perhaps this group should band with others who may be interested in standardizing these things -- SSO seems like it's ripe for that. In other words, let's join with others on common foundational issues, rather than separating from them along the lines of application domains (VWs vs everything else). In that sense I'd argue for #3, because doing an IETF SSO working group properly would require substantial change and outreach. There's a long history in SSOs. The good news is that from what I read in [1], there is now some interest in the IETF on this. However, some issues are application-domain-specific -- e.g. avatars, assets; in the Web model, these are MIME type issues. They need standardization too -- or at least generalized agreement on the data that gets passed around. In that sense I'd argue for #2. There are MIME type standards that this group can define specifically for virtual worlds. That's one part of interoperability that only ppl in the VW field can tackle. Crista / Diva [1] http://isoc.org/wp/ietfjournal/?p=1715 On 1/14/2011 9:13 AM, Barry Leiba wrote: > Good day, all. > The chairs and area directors have been talking about the status and > future of the VWRAP working group. Owing to changes in focus and > commitment by both companies and individuals, things have been > languishing, and it's not clear to us that we have what we need to get > the chartered work done. The introduction document looked close to > ready, until some controversy on its content and direction brewed, and > the result of that discussion was inconclusive. The normative drafts > that have seen some implementation (type system, launch message, etc.) > also appear nearly technically complete, but some issues have been > identified and not resolved by subsequent discussion, consensus, and > editing. > > At this point, the mailing list has been too quiet for too long, all > the draft documents have expired, and we need to make a decision about > what to do. > > The chairs and ADs see three possibilities: > > 1. Find new document editors, pick up the chartered work with the > existing document base, and get moving again. Get the introduction > document finished by the end of February, and make progress on the > others. > > 2. Come to consensus on significant changes to the direction of the > VWRAP specs, find new document editors, revamp the introduction > document, and get that finished, or substantially so, by the end of > February. Have some clear consensus, clear direction, and enthusiasm > to continue. Consider rechartering, if the direction has changed > enough to require that. > > 3. Accept that we no longer have enough core participation, consensus, > and enthusiasm to make progress, and close the working group. Future > work in the virtual world area could charter a new working group > later. > > Note that options 1 and 2 both require that we demonstrate sufficient > energy and participation to really get work done and to demonstrate > consensus. That means that we need people to commit to > writing/editing documents, actively discussing the technical issues > with the goal of reaching consensus on the content of the documents, > and, importantly, reviewing documents and showing that we have > consensus. Three or four participants isn't enough, and conflicting > ideas that can't be resolved into a consensus-based position won't > work. > > What say you, VWRAP participants? Can we pick up the work and make > progress? Shall we close the working group, and perhaps consider > something in future? Do you favour options 1, 2, or 3? Or do you see > an alternative option you'd like to bring up? > > Barry and Joshua, VWRAP chairs > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap From vaughn.deluca@gmail.com Sat Jan 15 02:46: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 D3EE428C0E3 for ; Sat, 15 Jan 2011 02:46:49 -0800 (PST) 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 DF5+DIQ1WY70 for ; Sat, 15 Jan 2011 02:46:48 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id D871A3A6D36 for ; Sat, 15 Jan 2011 02:46:47 -0800 (PST) Received: by ewy8 with SMTP id 8so1995652ewy.31 for ; Sat, 15 Jan 2011 02:49:15 -0800 (PST) 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=+ZzAo91c166YqheEbQl3UB/Id6BNRfzhbZ6PJ+zMgmE=; b=gVwK6uRr97VRLbzsK1Bg+9KRNKnMnjakpVynHtKVq+3Oz+2u9OjQBISr1Oi7mq/pMc pUGaoHPXoheLO32inC4oVra92sckMGufhdc/4JFUwSkiUH2H1KTTTkmrWfSG6ncgRdpu sDE086M1bQeWrlI8JoGj7IOvZxTVXCMbgMoGQ= 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=dmrlkAgOSvsVpLvm47dN98AI6rsm23H5/857evFlp0hH4EFcKLqeutwhS4pAuKpBPw 54niIXL7qrNzImKZkckGY7I4stSYpGTgVsLzgDEy/8Alzw8+LncQFReX5tYTm3qGatoe M5oGgb+jKZPhu5YeF7oiAXugiOlPohIYuvFXA= MIME-Version: 1.0 Received: by 10.213.22.209 with SMTP id o17mr1690506ebb.41.1295088554948; Sat, 15 Jan 2011 02:49:14 -0800 (PST) Received: by 10.213.8.78 with HTTP; Sat, 15 Jan 2011 02:49:14 -0800 (PST) In-Reply-To: <4D30F6FE.4020805@ics.uci.edu> References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 11:49:14 +0100 Message-ID: From: Vaughn Deluca To: Cristina Videira Lopes 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, 15 Jan 2011 10:46:49 -0000 Although i have only been operating in the fringe of this group, i would like to argue for #2 It clear that some refocussing and consensus building is needed, but we should at least give that a try. To me it seems definitely to early to give up. If we try #2 it will become clear if #3 can indedeed be avoided. I see christina's point of starting at the basis, and fixing SSO first. However, I feel that from the perspective of VWRAP SSO is actually a well described sub-problem that can be left to others to solve, while we focus on the specific of avatars and assets. In terms of actual commitment, i think the wiki idea is great, and i will try to free some time to contribute there in the near future. --Vaughn On 1/15/11, Cristina Videira Lopes wrote: > I'm leaning towards #2 and #3 simultaneously :) > Let me explain. > > The goal of achieving virtual world interoperability always felt like a > niche goal to me, but one that, given the nature of these applications, > touched on a couple of more foundational issues: single sign ons and Web > services security -- in short, federations that cross enterprise boundaries. > > There is a variety of implementations for SSOs out there, more recently > the one in the Hypergrid, and a variety of ways of securing Web > services. But no standards that I know of -- apart from the SOAP stuff. > Perhaps this group should band with others who may be interested in > standardizing these things -- SSO seems like it's ripe for that. In > other words, let's join with others on common foundational issues, > rather than separating from them along the lines of application domains > (VWs vs everything else). > > In that sense I'd argue for #3, because doing an IETF SSO working group > properly would require substantial change and outreach. There's a long > history in SSOs. The good news is that from what I read in [1], there is > now some interest in the IETF on this. > > However, some issues are application-domain-specific -- e.g. avatars, > assets; in the Web model, these are MIME type issues. They need > standardization too -- or at least generalized agreement on the data > that gets passed around. > > In that sense I'd argue for #2. There are MIME type standards that this > group can define specifically for virtual worlds. That's one part of > interoperability that only ppl in the VW field can tackle. > > Crista / Diva > > [1] http://isoc.org/wp/ietfjournal/?p=1715 > > On 1/14/2011 9:13 AM, Barry Leiba wrote: >> Good day, all. >> The chairs and area directors have been talking about the status and >> future of the VWRAP working group. Owing to changes in focus and >> commitment by both companies and individuals, things have been >> languishing, and it's not clear to us that we have what we need to get >> the chartered work done. The introduction document looked close to >> ready, until some controversy on its content and direction brewed, and >> the result of that discussion was inconclusive. The normative drafts >> that have seen some implementation (type system, launch message, etc.) >> also appear nearly technically complete, but some issues have been >> identified and not resolved by subsequent discussion, consensus, and >> editing. >> >> At this point, the mailing list has been too quiet for too long, all >> the draft documents have expired, and we need to make a decision about >> what to do. >> >> The chairs and ADs see three possibilities: >> >> 1. Find new document editors, pick up the chartered work with the >> existing document base, and get moving again. Get the introduction >> document finished by the end of February, and make progress on the >> others. >> >> 2. Come to consensus on significant changes to the direction of the >> VWRAP specs, find new document editors, revamp the introduction >> document, and get that finished, or substantially so, by the end of >> February. Have some clear consensus, clear direction, and enthusiasm >> to continue. Consider rechartering, if the direction has changed >> enough to require that. >> >> 3. Accept that we no longer have enough core participation, consensus, >> and enthusiasm to make progress, and close the working group. Future >> work in the virtual world area could charter a new working group >> later. >> >> Note that options 1 and 2 both require that we demonstrate sufficient >> energy and participation to really get work done and to demonstrate >> consensus. That means that we need people to commit to >> writing/editing documents, actively discussing the technical issues >> with the goal of reaching consensus on the content of the documents, >> and, importantly, reviewing documents and showing that we have >> consensus. Three or four participants isn't enough, and conflicting >> ideas that can't be resolved into a consensus-based position won't >> work. >> >> What say you, VWRAP participants? Can we pick up the work and make >> progress? Shall we close the working group, and perhaps consider >> something in future? Do you favour options 1, 2, or 3? Or do you see >> an alternative option you'd like to bring up? >> >> Barry and Joshua, VWRAP chairs >> _______________________________________________ >> 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 fleep513@gmail.com Sat Jan 15 06:02: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 D0D803A6D4A for ; Sat, 15 Jan 2011 06:02:12 -0800 (PST) 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 VPeZ+NXi-ZfP for ; Sat, 15 Jan 2011 06:02:11 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id A6F4C3A6D3E for ; Sat, 15 Jan 2011 06:02:11 -0800 (PST) Received: by yxt33 with SMTP id 33so1638545yxt.31 for ; Sat, 15 Jan 2011 06:04:39 -0800 (PST) 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=8Pdi2iF+BLy74ILrj8uw4JLFmRJuSfPxo2G9DZsoeGE=; b=EErjD5y7YTzySxzlP1FPkFt41x6EoYVmLw3Rle48MiU9AZzNj0e0CrrmJ3PuMjkm5y iSb9DWXCoCjGhFj8fk9VXRGJZlGH43YYarz/II4x9FmK6+qWUVGAKYjCoegvTagWq+jM DQPLj/tbkwVfNu/B2EFW4lz6yth3h9lm3hsCI= 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=LTY/cTZLCgRp7dEMMuGsK38VM5eQmBy1H2pt1ZdrFFqUAFKZ1e/6lv4i8aUtA7OcKn Ohag7w1YV7r2C8ZW2DfHXYjHvFqBcjxZheqEjIoVi6tVF0fYNUgFTVBQpnpEOjiMEa39 svE5qrVY8o8VbO4it0Ek0nwjJLkAsi9twLbeM= MIME-Version: 1.0 Received: by 10.91.43.35 with SMTP id v35mr2462211agj.209.1295100278479; Sat, 15 Jan 2011 06:04:38 -0800 (PST) Received: by 10.91.162.6 with HTTP; Sat, 15 Jan 2011 06:04:38 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 09:04:38 -0500 Message-ID: From: Fleep Tuque To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016363b7b660c1d7f0499e30832 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, 15 Jan 2011 14:02:13 -0000 --0016363b7b660c1d7f0499e30832 Content-Type: text/plain; charset=ISO-8859-1 I still feel too new to this effort to voice an opinion that counts for much, but my sense is #1 is truly not feasible since it doesn't seem there is general consensus on the existing document base at all. Nevertheless, I would like to see #2 happen. From this newcomer's perspective, there are a number of issues that DO seem to have consensus. I would suggest tackling the introductory document and the parts that aren't as controversial first. An introductory document doesn't have to have all the answers, it can address the outlines of the issues up for debate, no? I also have volunteered to assist with editing and compiling feedback into draft documents, though I don't feel the least bit qualified to be a primary author. I can help wordsmith, edit for readability, and help keep track of suggested edits and I'm still 100% willing to do that. Sincerely, - 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 --0016363b7b660c1d7f0499e30832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I still feel too new to this effort to voice an opinion that counts for muc= h, but my sense is #1 is truly not feasible since it doesn't seem there= is general consensus on the existing document base at all.=A0

Nevertheless, I would like to see #2 happen. =A0From this newcomer'= ;s perspective, there are a number of issues that DO seem to have consensus= . =A0I would suggest tackling the introductory document and the parts that = aren't as controversial first. =A0An introductory document doesn't = have to have all the answers, it can address the outlines of the issues up = for debate, no?


I also have volunteered to assist with e= diting and compiling feedback into draft documents, though I don't feel= the least bit qualified to be a primary author. =A0I can help wordsmith, e= dit for readability, and help keep track of suggested edits and I'm sti= ll 100% willing to do that. =A0


Sincerely,

- Ch= ris/Fleep


Chris M. Collins (SL: Fle= ep Tuque)
Project Manager, UC Second Life=A0
Second Lif= e Ambassador, Ohio Learning Network=A0
UCit Instructional & Research Computing
University of Ci= ncinnati=A0
406E Zimmer Hall
PO Box 210088
Ci= ncinnati, OH 45221-0088
(513)556-3018



--0016363b7b660c1d7f0499e30832-- From morgaine.dinova@googlemail.com Sat Jan 15 06:12: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 BF4143A6D4C for ; Sat, 15 Jan 2011 06:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.837 X-Spam-Level: X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.139, 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 hV7tHTlqhyB3 for ; Sat, 15 Jan 2011 06:12:03 -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 E6AE73A6BA9 for ; Sat, 15 Jan 2011 06:12:02 -0800 (PST) Received: by qyk34 with SMTP id 34so410705qyk.10 for ; Sat, 15 Jan 2011 06:14:31 -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:content-type; bh=/CDnloEbmfl4oxmPZ6km33NXnBlcooHphnxAHrxp29U=; b=P72GYQCsToOnyNxHZowUnFWdOVXrcJukKrB5rAHES9Yiyvav3tWWuGc1QPqEjii5MN H+MOwawRZVeUuYJlwwaBRsOFv0bWofpQE/IxiZRnfqqgKzrN2YuuzEq1xE14bVSa7POt 4zIh/FeplNk/w67SZQTsPny30VoL9If/IAIXs= 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=hYUzu+1+pKDV/GYb5ZsWonIsF4yfeqNDuHtPMtWNxpSq1rrZnSNb8yIpau4fMjZVqs sKBdCXytujxUQLC5f/4DHHxn5+UfiLM2h6G3+tgeNXt2unnIWkJ4Yb5QchWV2lKRqkCe K74gSnzIZ3gHVDcON/5Zyq/ho+BiQlg61E7dk= MIME-Version: 1.0 Received: by 10.229.231.21 with SMTP id jo21mr1767744qcb.119.1295100869795; Sat, 15 Jan 2011 06:14:29 -0800 (PST) Received: by 10.229.225.81 with HTTP; Sat, 15 Jan 2011 06:14:29 -0800 (PST) In-Reply-To: <4D30F6FE.4020805@ics.uci.edu> References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 14:14:29 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e686cd6c4ae06d0499e32b07 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, 15 Jan 2011 14:12:04 -0000 --0016e686cd6c4ae06d0499e32b07 Content-Type: text/plain; charset=ISO-8859-1 That's well said. Frankly I've never understood why OGP/OGPX/VWRAP focussed so strongly on login and authentication when these issues have been addressed very thoroughly by numerous other groups. All we ever needed was a means of associating an agent ID with a protected credential, and that credential could be obtained through any of the common login / authentication systems, giving the user the choice of method. We really didn't need to roll our own. Far more interesting than login would have been for us to focus on the relationship between asset services and agents, since access to shared asset services from various worlds is really the heart of interop. Yet, we never even touched on it, because for historical reasons the documents were heading in a completely different direction. I think we can do a lot better from here on as a result of this new group focus on interop between worlds as the primary goal. Option #2 looks good to me. Morgaine. ==================================== On Sat, Jan 15, 2011 at 1:23 AM, Cristina Videira Lopes wrote: > I'm leaning towards #2 and #3 simultaneously :) > Let me explain. > > The goal of achieving virtual world interoperability always felt like a > niche goal to me, but one that, given the nature of these applications, > touched on a couple of more foundational issues: single sign ons and Web > services security -- in short, federations that cross enterprise boundaries. > > There is a variety of implementations for SSOs out there, more recently the > one in the Hypergrid, and a variety of ways of securing Web services. But no > standards that I know of -- apart from the SOAP stuff. Perhaps this group > should band with others who may be interested in standardizing these things > -- SSO seems like it's ripe for that. In other words, let's join with others > on common foundational issues, rather than separating from them along the > lines of application domains (VWs vs everything else). > > In that sense I'd argue for #3, because doing an IETF SSO working group > properly would require substantial change and outreach. There's a long > history in SSOs. The good news is that from what I read in [1], there is now > some interest in the IETF on this. > > However, some issues are application-domain-specific -- e.g. avatars, > assets; in the Web model, these are MIME type issues. They need > standardization too -- or at least generalized agreement on the data that > gets passed around. > > In that sense I'd argue for #2. There are MIME type standards that this > group can define specifically for virtual worlds. That's one part of > interoperability that only ppl in the VW field can tackle. > > Crista / Diva > > [1] http://isoc.org/wp/ietfjournal/?p=1715 > > > On 1/14/2011 9:13 AM, Barry Leiba wrote: > >> Good day, all. >> The chairs and area directors have been talking about the status and >> future of the VWRAP working group. Owing to changes in focus and >> commitment by both companies and individuals, things have been >> languishing, and it's not clear to us that we have what we need to get >> the chartered work done. The introduction document looked close to >> ready, until some controversy on its content and direction brewed, and >> the result of that discussion was inconclusive. The normative drafts >> that have seen some implementation (type system, launch message, etc.) >> also appear nearly technically complete, but some issues have been >> identified and not resolved by subsequent discussion, consensus, and >> editing. >> >> At this point, the mailing list has been too quiet for too long, all >> the draft documents have expired, and we need to make a decision about >> what to do. >> >> The chairs and ADs see three possibilities: >> >> 1. Find new document editors, pick up the chartered work with the >> existing document base, and get moving again. Get the introduction >> document finished by the end of February, and make progress on the >> others. >> >> 2. Come to consensus on significant changes to the direction of the >> VWRAP specs, find new document editors, revamp the introduction >> document, and get that finished, or substantially so, by the end of >> February. Have some clear consensus, clear direction, and enthusiasm >> to continue. Consider rechartering, if the direction has changed >> enough to require that. >> >> 3. Accept that we no longer have enough core participation, consensus, >> and enthusiasm to make progress, and close the working group. Future >> work in the virtual world area could charter a new working group >> later. >> >> Note that options 1 and 2 both require that we demonstrate sufficient >> energy and participation to really get work done and to demonstrate >> consensus. That means that we need people to commit to >> writing/editing documents, actively discussing the technical issues >> with the goal of reaching consensus on the content of the documents, >> and, importantly, reviewing documents and showing that we have >> consensus. Three or four participants isn't enough, and conflicting >> ideas that can't be resolved into a consensus-based position won't >> work. >> >> What say you, VWRAP participants? Can we pick up the work and make >> progress? Shall we close the working group, and perhaps consider >> something in future? Do you favour options 1, 2, or 3? Or do you see >> an alternative option you'd like to bring up? >> >> Barry and Joshua, VWRAP chairs >> _______________________________________________ >> 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 > --0016e686cd6c4ae06d0499e32b07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's well said.

Frankly I've never understood why OGP/OGPX= /VWRAP focussed so strongly on login and authentication when these issues h= ave been addressed very thoroughly by numerous other groups.=A0 All we ever= needed was a means of associating an agent ID with a protected credential,= and that credential could be obtained through any of the common login / au= thentication systems, giving the user the choice of method.=A0 We really di= dn't need to roll our own.

Far more interesting than login would have been for us to focus on the = relationship between asset services and agents, since access to shared asse= t services from various worlds is really the heart of interop.=A0 Yet, we n= ever even touched on it, because for historical reasons the documents were = heading in a completely different direction.

I think we can do a lot better from here on as a result of this new gro= up focus on interop between worlds as the primary goal.=A0 Option #2 looks = good to me.


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

On Sat, Jan 15, 2011 at 1:23 AM, Cristina Vi= deira Lopes <lope= s@ics.uci.edu> wrote:
I'm leaning towards #2 and #3 simultaneously :)
Let me explain.

The goal of achieving virtual world interoperability always felt like a nic= he goal to me, but one that, given the nature of these applications, touche= d on a couple of more foundational issues: single sign ons and Web services= security -- in short, federations that cross enterprise boundaries.

There is a variety of implementations for SSOs out there, more recently the= one in the Hypergrid, and a variety of ways of securing Web services. But = no standards that I know of -- apart from the SOAP stuff. Perhaps this grou= p should band with others who may be interested in standardizing these thin= gs -- SSO seems like it's ripe for that. In other words, let's join= with others on common foundational issues, rather than separating from the= m along the lines of application domains (VWs vs everything else).

In that sense I'd argue for #3, because doing an IETF SSO working group= properly would require substantial change and outreach. There's a long= history in SSOs. The good news is that from what I read in [1], there is n= ow some interest in the IETF on this.

However, some issues are application-domain-specific -- e.g. avatars, asset= s; =A0in the Web model, these are MIME type issues. They need standardizati= on too -- or at least generalized agreement on the data that gets passed ar= ound.

In that sense I'd argue for #2. There are MIME type standards that this= group can define specifically for virtual worlds. That's one part of i= nteroperability that only ppl in the VW field can tackle.

Crista / Diva

[1] = http://isoc.org/wp/ietfjournal/?p=3D1715


On 1/14/2011 9:13 AM, Barry Leiba wrote:
Good day, all.
The chairs and area directors have been talking about the status and
future of the VWRAP working group. =A0Owing to changes in focus and
commitment by both companies and individuals, things have been
languishing, and it's not clear to us that we have what we need to get<= br> the chartered work done. =A0The introduction document looked close to
ready, until some controversy on its content and direction brewed, and
the result of that discussion was inconclusive. =A0The normative drafts
that have seen some implementation (type system, launch message, etc.)
also appear nearly technically complete, but some issues have been
identified and not resolved by subsequent discussion, consensus, and
editing.

At this point, the mailing list has been too quiet for too long, all
the draft documents have expired, and we need to make a decision about
what to do.

The chairs and ADs see three possibilities:

1. Find new document editors, pick up the chartered work with the
existing document base, and get moving again. =A0Get the introduction
document finished by the end of February, and make progress on the
others.

2. Come to consensus on significant changes to the direction of the
VWRAP specs, find new document editors, revamp the introduction
document, and get that finished, or substantially so, by the end of
February. =A0Have some clear consensus, clear direction, and enthusiasm
to continue. =A0Consider rechartering, if the direction has changed
enough to require that.

3. Accept that we no longer have enough core participation, consensus,
and enthusiasm to make progress, and close the working group. =A0Future
work in the virtual world area could charter a new working group
later.

Note that options 1 and 2 both require that we demonstrate sufficient
energy and participation to really get work done and to demonstrate
consensus. =A0That means that we need people to commit to
writing/editing documents, actively discussing the technical issues
with the goal of reaching consensus on the content of the documents,
and, importantly, reviewing documents and showing that we have
consensus. =A0Three or four participants isn't enough, and conflicting<= br> ideas that can't be resolved into a consensus-based position won't<= br> work.

What say you, VWRAP participants? =A0Can we pick up the work and make
progress? =A0Shall we close the working group, and perhaps consider
something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you see<= br> an alternative option you'd like to bring up?

Barry and Joshua, VWRAP chairs
_______________________________________________
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

--0016e686cd6c4ae06d0499e32b07-- From mark.bannon@littlehall.com Sat Jan 15 05:58: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 6C0A93A6D3E for ; Sat, 15 Jan 2011 05:58:27 -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 tEafqOUbAz05 for ; Sat, 15 Jan 2011 05:58:25 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id CFB8B3A6A5D for ; Sat, 15 Jan 2011 05:58:24 -0800 (PST) Received: by gwj17 with SMTP id 17so1632421gwj.31 for ; Sat, 15 Jan 2011 06:00:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.164.5 with SMTP id m5mr1315936ane.132.1295100049971; Sat, 15 Jan 2011 06:00:49 -0800 (PST) Sender: mark.bannon@littlehall.com Received: by 10.100.109.17 with HTTP; Sat, 15 Jan 2011 06:00:49 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 14:00:49 +0000 X-Google-Sender-Auth: p17Bl66G-XDp_3d8q-OVu2mY_hs Message-ID: From: Mark Bannon To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e644bc446d5b460499e2fa9f X-Mailman-Approved-At: Sat, 15 Jan 2011 06:34:10 -0800 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, 15 Jan 2011 14:00:12 -0000 --0016e644bc446d5b460499e2fa9f Content-Type: text/plain; charset=ISO-8859-1 Hey everyone. Up until recently I have been more of an observer in the group due to other committee work related to 3D development. Now being transferred onto this end of things so should be a lot more active in this group in the future. With regards to our options, I would personally suggest for number two. Certainly some refocus is required! Number three would be a last option situation. At least option two would give us a chance to gather our thoughts again and then if that didn't work, option three would be there further down the road. Don't think we are at the point of giving up yet. Wiki idea sounds great. Actually I have a bit of suggestion or question to ask. One of the organisations I do volunteer work for (IDCAS) has created an excellent project management system which has a wiki built into it. Its just one of the things incorporated into the system but has a lot of other helpful tools. IDCAS currently provides a lot of free services to a number of technology groups and even help manage a quite active registered opensim grid association as a side project in the field of 3D internet development ( http://opensimulator.org/wiki/Grid_Associations). Mostly their work relates to opensim but they work on other platforms too. A lot of the discussion in their grid association for the last 6 months has been related to standardization of avatars, meshing and other properties. So from what I can tell IDCAS itself could be open to perhaps helping a group like ours out if we asked them. Would anyone like me to enquire about this, since they are already heavily involved in the area of vwap and have a lot of members in ICANN groups it may be good to see what support they could provide us. I was using an internal volunteer/demo version of this developers system for a different purpose last week and it has support ticketing systems, project/task allocation, code/version management etc in addition to the wiki so could be very useful. Anyway basic question is would you like me to ask if they could give us all access? Word of warning though, they typically dont grant access to individuals, they mostly only give it to official non-profit based organisations and groups. I think though that if we asked as a "working group of IETF" there should not be a problem, after all they granted access to a various ICANN groups in the past, precidence thus has been set so think we would have a good chance of getting a lot of help from them. Who knows what else they might supply, know they are in process of developing a framework/bridge for connecting opensim and websites and are in partnership with the development team of ICMS (integrated client messaging service) which is IANA port recognised (I know that because it was one of the committees I got involved in a while ago so am aware of the partnership that way), perhaps it could be a clever move on our part of ask for help in "general" terms off them? Returning to our group options though, so that we can go further from here. I would certainly like to see us go for option two as its always difficult with any project at the start, that can be equated to initial documentation in the same way. Once an initial version exists then people can work on it and thus the framework develops further. Mark On Sat, Jan 15, 2011 at 10:49 AM, Vaughn Deluca wrote: > Although i have only been operating in the fringe of this group, i > would like to argue for #2 > > It clear that some refocussing and consensus building is needed, but > we should at least give that a try. To me it seems definitely to > early to give up. If we try #2 it will become clear if #3 can > indedeed be avoided. > > I see christina's point of starting at the basis, and fixing SSO > first. However, I feel that from the perspective of VWRAP SSO is > actually a well described sub-problem that can be left to others to > solve, while we focus on the specific of avatars and assets. > > In terms of actual commitment, i think the wiki idea is great, and i > will try to free some time to contribute there in the near future. > > --Vaughn > > On 1/15/11, Cristina Videira Lopes wrote: > > I'm leaning towards #2 and #3 simultaneously :) > > Let me explain. > > > > The goal of achieving virtual world interoperability always felt like a > > niche goal to me, but one that, given the nature of these applications, > > touched on a couple of more foundational issues: single sign ons and Web > > services security -- in short, federations that cross enterprise > boundaries. > > > > There is a variety of implementations for SSOs out there, more recently > > the one in the Hypergrid, and a variety of ways of securing Web > > services. But no standards that I know of -- apart from the SOAP stuff. > > Perhaps this group should band with others who may be interested in > > standardizing these things -- SSO seems like it's ripe for that. In > > other words, let's join with others on common foundational issues, > > rather than separating from them along the lines of application domains > > (VWs vs everything else). > > > > In that sense I'd argue for #3, because doing an IETF SSO working group > > properly would require substantial change and outreach. There's a long > > history in SSOs. The good news is that from what I read in [1], there is > > now some interest in the IETF on this. > > > > However, some issues are application-domain-specific -- e.g. avatars, > > assets; in the Web model, these are MIME type issues. They need > > standardization too -- or at least generalized agreement on the data > > that gets passed around. > > > > In that sense I'd argue for #2. There are MIME type standards that this > > group can define specifically for virtual worlds. That's one part of > > interoperability that only ppl in the VW field can tackle. > > > > Crista / Diva > > > > [1] http://isoc.org/wp/ietfjournal/?p=1715 > > > > On 1/14/2011 9:13 AM, Barry Leiba wrote: > >> Good day, all. > >> The chairs and area directors have been talking about the status and > >> future of the VWRAP working group. Owing to changes in focus and > >> commitment by both companies and individuals, things have been > >> languishing, and it's not clear to us that we have what we need to get > >> the chartered work done. The introduction document looked close to > >> ready, until some controversy on its content and direction brewed, and > >> the result of that discussion was inconclusive. The normative drafts > >> that have seen some implementation (type system, launch message, etc.) > >> also appear nearly technically complete, but some issues have been > >> identified and not resolved by subsequent discussion, consensus, and > >> editing. > >> > >> At this point, the mailing list has been too quiet for too long, all > >> the draft documents have expired, and we need to make a decision about > >> what to do. > >> > >> The chairs and ADs see three possibilities: > >> > >> 1. Find new document editors, pick up the chartered work with the > >> existing document base, and get moving again. Get the introduction > >> document finished by the end of February, and make progress on the > >> others. > >> > >> 2. Come to consensus on significant changes to the direction of the > >> VWRAP specs, find new document editors, revamp the introduction > >> document, and get that finished, or substantially so, by the end of > >> February. Have some clear consensus, clear direction, and enthusiasm > >> to continue. Consider rechartering, if the direction has changed > >> enough to require that. > >> > >> 3. Accept that we no longer have enough core participation, consensus, > >> and enthusiasm to make progress, and close the working group. Future > >> work in the virtual world area could charter a new working group > >> later. > >> > >> Note that options 1 and 2 both require that we demonstrate sufficient > >> energy and participation to really get work done and to demonstrate > >> consensus. That means that we need people to commit to > >> writing/editing documents, actively discussing the technical issues > >> with the goal of reaching consensus on the content of the documents, > >> and, importantly, reviewing documents and showing that we have > >> consensus. Three or four participants isn't enough, and conflicting > >> ideas that can't be resolved into a consensus-based position won't > >> work. > >> > >> What say you, VWRAP participants? Can we pick up the work and make > >> progress? Shall we close the working group, and perhaps consider > >> something in future? Do you favour options 1, 2, or 3? Or do you see > >> an alternative option you'd like to bring up? > >> > >> Barry and Joshua, VWRAP chairs > >> _______________________________________________ > >> 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 > --0016e644bc446d5b460499e2fa9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey everyone. =A0
Up until recently I have been more of an observer in = the group due to other committee work related to 3D development. =A0Now bei= ng transferred onto this end of things so should be a lot more active in th= is group in the future. =A0

With regards to our options, I would personally suggest for = number two. =A0Certainly some refocus is required! =A0Number three would be= a last option situation. At least option two would give us a chance to gat= her our thoughts again and then if that=A0didn't=A0work, option three w= ould be there further down the road. =A0Don't think we are at the point= of giving up yet.

Wiki idea sounds great. =A0Actually I have a bit of sug= gestion or question to ask. =A0One of the organisations I do volunteer work= for (IDCAS) has created an excellent project management system which has a= wiki built into it. =A0Its just one of the things incorporated into the sy= stem but has a lot of other helpful tools. =A0IDCAS currently provides a lo= t of free services to a number of technology groups and even help manage a = quite active registered opensim grid association as a side project in the f= ield of 3D internet development (http://opensimulator.org/wiki/Grid_Associations). Mos= tly their work relates to opensim but they work on other platforms too. =A0= A lot of the=A0discussion=A0in their grid association for the last 6 months= has been related to standardization of avatars, meshing and other properti= es. =A0So from what I can tell IDCAS itself could be open to perhaps helpin= g a group like ours out if we asked them. =A0Would anyone like me to enquir= e about this, since they are already heavily involved in the area of vwap a= nd have a lot of members in ICANN groups it may be good to see what support= they could provide us. =A0 I was using an internal volunteer/demo version = of this developers system for a different purpose last week and it has supp= ort ticketing systems, project/task allocation, code/version management etc= in addition to the wiki so could be very useful. =A0Anyway basic question = is would you like me to ask if they could give us all access? =A0Word of wa= rning though, they=A0typically=A0dont grant access to individuals, they mos= tly only give it to official non-profit based organisations and groups. =A0= I think though that if we asked as a "working group of IETF" ther= e should not be a problem, after all they granted access to a various ICANN= groups in the past, precidence thus has been set so think we would have a = good chance of getting a lot of help from them. =A0Who knows what else they= might supply, know they are in process of developing a framework/bridge fo= r connecting opensim and websites and are in partnership with the developme= nt team of ICMS (integrated client messaging service) which is IANA port re= cognised (I know that because it was one of the committees I got involved i= n a while ago so am aware of the partnership that way), perhaps it could be= a clever move on our part of ask for help in "general" terms off= them?

Returning = to our group options though, so that we can go further from here. I would c= ertainly like to see us go for option two as its always difficult with any = project at the start, that can be equated to initial documentation in the s= ame way. =A0Once an initial version exists then people can work on it and t= hus the framework develops further.=A0

Mark



On Sat, Jan 15, 2011 at 10:49 AM, Vaughn Deluca &= lt;vaughn.deluca@gmail.com&g= t; wrote:
Although i have only been operating in the = fringe of this group, i
would like to argue for #2

It clear that some refocussing and consensus building is needed, but
we should at least =A0give that a try. To me it seems definitely to
early to give up. If we try #2 =A0it will become clear if =A0#3 can
indedeed be avoided.

I see christina's point of starting at the basis, and fixing SSO
first. However, I feel that from the perspective of VWRAP SSO is
actually a well described sub-problem that can be left to others to
solve, while we focus on the specific =A0of avatars and assets.

In =A0terms of actual commitment, i think the wiki idea is great, and i
will try to free some time to contribute there in the near future.

--Vaughn

On 1/15/11, Cristina Videira Lopes <lopes@ics.uci.edu> wrote:
> I'm leaning towards #2 and #3 simultaneously :)
> Let me explain.
>
> The goal of achieving virtual world interoperability always felt like = a
> niche goal to me, but one that, given the nature of these applications= ,
> touched on a couple of more foundational issues: single sign ons and W= eb
> services security -- in short, federations that cross enterprise bound= aries.
>
> There is a variety of implementations for SSOs out there, more recentl= y
> the one in the Hypergrid, and a variety of ways of securing Web
> services. But no standards that I know of -- apart from the SOAP stuff= .
> Perhaps this group should band with others who may be interested in > standardizing these things -- SSO seems like it's ripe for that. I= n
> other words, let's join with others on common foundational issues,=
> rather than separating from them along the lines of application domain= s
> (VWs vs everything else).
>
> In that sense I'd argue for #3, because doing an IETF SSO working = group
> properly would require substantial change and outreach. There's a = long
> history in SSOs. The good news is that from what I read in [1], there = is
> now some interest in the IETF on this.
>
> However, some issues are application-domain-specific -- e.g. avatars,<= br> > assets; =A0in the Web model, these are MIME type issues. They need
> standardization too -- or at least generalized agreement on the data > that gets passed around.
>
> In that sense I'd argue for #2. There are MIME type standards that= this
> group can define specifically for virtual worlds. That's one part = of
> interoperability that only ppl in the VW field can tackle.
>
> Crista / Diva
>
> [1] http://isoc.org/wp/ietfjournal/?p=3D1715
>
> On 1/14/2011 9:13 AM, Barry Leiba wrote:
>> Good day, all.
>> The chairs and area directors have been talking about the status a= nd
>> future of the VWRAP working group. =A0Owing to changes in focus an= d
>> commitment by both companies and individuals, things have been
>> languishing, and it's not clear to us that we have what we nee= d to get
>> the chartered work done. =A0The introduction document looked close= to
>> ready, until some controversy on its content and direction brewed,= and
>> the result of that discussion was inconclusive. =A0The normative d= rafts
>> that have seen some implementation (type system, launch message, e= tc.)
>> also appear nearly technically complete, but some issues have been=
>> identified and not resolved by subsequent discussion, consensus, a= nd
>> editing.
>>
>> At this point, the mailing list has been too quiet for too long, a= ll
>> the draft documents have expired, and we need to make a decision a= bout
>> what to do.
>>
>> The chairs and ADs see three possibilities:
>>
>> 1. Find new document editors, pick up the chartered work with the<= br> >> existing document base, and get moving again. =A0Get the introduct= ion
>> document finished by the end of February, and make progress on the=
>> others.
>>
>> 2. Come to consensus on significant changes to the direction of th= e
>> VWRAP specs, find new document editors, revamp the introduction >> document, and get that finished, or substantially so, by the end o= f
>> February. =A0Have some clear consensus, clear direction, and enthu= siasm
>> to continue. =A0Consider rechartering, if the direction has change= d
>> enough to require that.
>>
>> 3. Accept that we no longer have enough core participation, consen= sus,
>> and enthusiasm to make progress, and close the working group. =A0F= uture
>> work in the virtual world area could charter a new working group >> later.
>>
>> Note that options 1 and 2 both require that we demonstrate suffici= ent
>> energy and participation to really get work done and to demonstrat= e
>> consensus. =A0That means that we need people to commit to
>> writing/editing documents, actively discussing the technical issue= s
>> with the goal of reaching consensus on the content of the document= s,
>> and, importantly, reviewing documents and showing that we have
>> consensus. =A0Three or four participants isn't enough, and con= flicting
>> ideas that can't be resolved into a consensus-based position w= on't
>> work.
>>
>> What say you, VWRAP participants? =A0Can we pick up the work and m= ake
>> progress? =A0Shall we close the working group, and perhaps conside= r
>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do= you see
>> an alternative option you'd like to bring up?
>>
>> Barry and Joshua, VWRAP chairs
>> _______________________________________________
>> 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
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e644bc446d5b460499e2fa9f-- From virtualregions@gmail.com Sat Jan 15 07:09: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 23C083A6B89 for ; Sat, 15 Jan 2011 07:09:29 -0800 (PST) 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 z5HOLsCHAI4N for ; Sat, 15 Jan 2011 07:09:28 -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 1F1B83A6B58 for ; Sat, 15 Jan 2011 07:09:28 -0800 (PST) Received: by qyk34 with SMTP id 34so438247qyk.10 for ; Sat, 15 Jan 2011 07:11:56 -0800 (PST) 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=n3ip5SB+LGmOLhvQ6kF/Q2wWAwHSISS91QBNGz1e34I=; b=E0hBzFtB4S4JA28cWSRa9fCc+skAPJor+WUQJQvr6vNJj6KCaja7Rtj1YFyvVABigy 2uKUhFq7Ka6e8SrNHNkUX2+aW6stBRMECRm9nYmi4M002+I0DCqC4o1IECJJSMznRIRK SCl+v17Bp8UJpF4/mHUveXCYZb/rdt2gbLcBU= 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=dSzjcyxizhDfuf/Nz+HSccmEbIO0nZw3TfFasFFbkXJ6X7IUVgHHU2M16UtyLpuQDm sV4j99ANqTm28RR9W59uRgf/JWH/6+bx1QE1fKXvKYisTGXnAh2vurIeTss+m2mINmI7 LAE3smpLy2nr9Mq7+gW+9TggJGanyKTnf7bY4= MIME-Version: 1.0 Received: by 10.229.96.132 with SMTP id h4mr1838443qcn.41.1295104316322; Sat, 15 Jan 2011 07:11:56 -0800 (PST) Received: by 10.229.38.65 with HTTP; Sat, 15 Jan 2011 07:11:56 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 16:11:56 +0100 Message-ID: From: peter host 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: Sat, 15 Jan 2011 15:09:29 -0000 Agreed too. I'm not involved in the VWRAP working group but I've followed it with interest. I'll give more of an "external" and "candid" opinion. First, there is nothing wrong in re-purposing work (#2, #3). We might once have thought that LL could be a key player in VW research, and obviously they aren't anymore as most the motivated/interesting Lindens have left the LL boat anyway. VWRAP is very much marked by (now legacy with Humble, most likely) LL views, and they ditched the baby. Second, I happen to have implemented XML as soon as it appeared in 1998 for the INSEE (the main French Statistics Governmental organization) in order to exchange data between services, and we had tried SGML before. We eventually managed it, and designed a pipeline based on that standard. But very soon we found ourselves trapped in layers of complexity (xsl, xpath, namespace hell...), big bosses liking nothing more than presenting *their* bosses a nice reassuring report assessing that all they do is 100% standard based... Whether the standard is appropriate not being an issue, and at the cost of a huge developer/maintainer/education overload. As it came out, XML was fine for a very little subset of what we did, and horrible for most of the rest (especially tabular data and http transactions). Then JSON came out in 2002/2003. At first, our hierarchy thought it was a joke. But after 1 year of developing a parallel pipeline, JSON based, they were with us. Same with Ecmascript. We ditched java although most of the French ministries were engulfing in it (and still suffer from it). By the way, Ecma initially is a 1guy, 4weeks project, and Crockford did JSON in a few days. How much effort took XML ? XML at least taught us one thing in my team, it's that it was not needed in most of our use cases (which *is* important to know), though we *did* manage a lot of document oriented data. Reason why I do agree with Christa. What we need most is a SSO standard. Corporations need to have their networks of trust, and to be able connect them together. This is exactly, on another level, what Hypergrid is addressing. And It's lightweight to the core, so it's good standard material. No decent, open economy can develop without SSO. What we're seeing now is the proliferation of mostly closed appstores/contentstores... of all sorts. Because these models bring accountability and enable enforcement. (at the *ghastly* cost of monopolies). Time for a standard. In the same line of thoughts, securing web services is the main focus of the 'Harmony' version of TC39 - ECMAScript. Second area (yes i know, it's not VWRAP related) that will likely have be addressed is re-purposing LSL to something more inter-operable, which can run in lightweight, platform (ie mono) independent VMs too. llHTTPrequest is fine, but well... We've all tortured it already. LSL's event-driven, finite state machine is brilliant. Strong Type,... not so brilliant. Interop, awfull. Most flaws relate in one way or another to the built-in requirements of a money module. Which brings us back to SSO. Enough rambling on my part. Last, I wish to thank all the people who've really worked hard on this, because it's always very tough when key initiators and founders of a technical project withdraw for non-technical, but political/commercial reasons. Reading you all is always a pleasure. On Sat, Jan 15, 2011 at 3:14 PM, Morgaine wrote: > That's well said. > All we ever needed was a means of > associating an agent ID with a protected credential, yup > On Sat, Jan 15, 2011 at 1:23 AM, Cristina Videira Lopes > wrote: >> >> I'm leaning towards #2 and #3 simultaneously :) >> Let me explain. yup From ohmeadhbh@gmail.com Sat Jan 15 08:15: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 3F89D3A6929 for ; Sat, 15 Jan 2011 08:15:16 -0800 (PST) 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 JvdJwLR0jONs for ; Sat, 15 Jan 2011 08:15:15 -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 C235A3A6805 for ; Sat, 15 Jan 2011 08:15:14 -0800 (PST) Received: by qyk34 with SMTP id 34so470912qyk.10 for ; Sat, 15 Jan 2011 08:17:43 -0800 (PST) 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=/xxy57W36Bjxk2b8SsMS9T+Le2cUpURtlaBOTIJMc4s=; b=dBXLXRKd2Ntw720xbtOxIC8T7ZfNCdtuur5+siC8DISuco35s2rLidKbXcIl7gUv29 xOtcTauPObrUe5FE7HI1Re6E68dYPnfUf5Gz2Vl8dA7Kp7cQQ4BaMWxHhkCE75rnsQcu FBZns6B7NpNwvU8U03UyuuCIK6mpDl1J1EJcY= 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=O9yzfHJvLQfhHGA32bGA1QAR6Vwv1f7dWYVR3tl8Zi1KbrSNDKD/DI/Czny2UQBAC0 rzUeN0F/FQiPhkrOu3dU72fC89yUEDCdiz6sFBhoC46urMHppNsgLUAqYB+tceY1VcnF 0GqFEHtNWqjW5mo0J0Ym/opHkhydcdxi9coZI= Received: by 10.224.19.145 with SMTP id a17mr1965934qab.208.1295108261531; Sat, 15 Jan 2011 08:17:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 08:17:21 -0800 (PST) In-Reply-To: <4D30F6FE.4020805@ics.uci.edu> References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 08:17:21 -0800 Message-ID: To: Cristina Videira Lopes 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, 15 Jan 2011 16:15:16 -0000 On Fri, Jan 14, 2011 at 5:23 PM, Cristina Videira Lopes wrote: > I'm leaning towards #2 and #3 simultaneously :) > Let me explain. > > The goal of achieving virtual world interoperability always felt like a > niche goal to me, but one that, given the nature of these applications, > touched on a couple of more foundational issues: single sign ons and Web > services security -- in short, federations that cross enterprise boundari= es. > > There is a variety of implementations for SSOs out there, more recently t= he > one in the Hypergrid, and a variety of ways of securing Web services. But= no > standards that I know of -- apart from the SOAP stuff. Perhaps this group > should band with others who may be interested in standardizing these thin= gs > -- SSO seems like it's ripe for that. In other words, let's join with oth= ers > on common foundational issues, rather than separating from them along the > lines of application domains (VWs vs everything else). i'm sorry, i missed your counter-proposal to vwrap auth. where was it? > In that sense I'd argue for #3, because doing an IETF SSO working group > properly would require substantial change and outreach. There's a long > history in SSOs. The good news is that from what I read in [1], there is = now > some interest in the IETF on this. also. what the heck does SSO have to do with virtual worlds? vwrap auth was a small portion of the effort and was even considered non-core by the implementers. the more important bits was the trust model + service establishment (which is not part of an SSO i've been able to fine) + control messages and request formats for assets. > However, some issues are application-domain-specific -- e.g. avatars, > assets; =A0in the Web model, these are MIME type issues. They need > standardization too -- or at least generalized agreement on the data that > gets passed around. yeah. that's actually what we were working on. > In that sense I'd argue for #2. There are MIME type standards that this > group can define specifically for virtual worlds. That's one part of > interoperability that only ppl in the VW field can tackle. are you volunteering to write a new charter? > Crista / Diva > > [1] http://isoc.org/wp/ietfjournal/?p=3D1715 > > On 1/14/2011 9:13 AM, Barry Leiba wrote: >> >> Good day, all. >> The chairs and area directors have been talking about the status and >> future of the VWRAP working group. =A0Owing to changes in focus and >> commitment by both companies and individuals, things have been >> languishing, and it's not clear to us that we have what we need to get >> the chartered work done. =A0The introduction document looked close to >> ready, until some controversy on its content and direction brewed, and >> the result of that discussion was inconclusive. =A0The normative drafts >> that have seen some implementation (type system, launch message, etc.) >> also appear nearly technically complete, but some issues have been >> identified and not resolved by subsequent discussion, consensus, and >> editing. >> >> At this point, the mailing list has been too quiet for too long, all >> the draft documents have expired, and we need to make a decision about >> what to do. >> >> The chairs and ADs see three possibilities: >> >> 1. Find new document editors, pick up the chartered work with the >> existing document base, and get moving again. =A0Get the introduction >> document finished by the end of February, and make progress on the >> others. >> >> 2. Come to consensus on significant changes to the direction of the >> VWRAP specs, find new document editors, revamp the introduction >> document, and get that finished, or substantially so, by the end of >> February. =A0Have some clear consensus, clear direction, and enthusiasm >> to continue. =A0Consider rechartering, if the direction has changed >> enough to require that. >> >> 3. Accept that we no longer have enough core participation, consensus, >> and enthusiasm to make progress, and close the working group. =A0Future >> work in the virtual world area could charter a new working group >> later. >> >> Note that options 1 and 2 both require that we demonstrate sufficient >> energy and participation to really get work done and to demonstrate >> consensus. =A0That means that we need people to commit to >> writing/editing documents, actively discussing the technical issues >> with the goal of reaching consensus on the content of the documents, >> and, importantly, reviewing documents and showing that we have >> consensus. =A0Three or four participants isn't enough, and conflicting >> ideas that can't be resolved into a consensus-based position won't >> work. >> >> What say you, VWRAP participants? =A0Can we pick up the work and make >> progress? =A0Shall we close the working group, and perhaps consider >> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you s= ee >> an alternative option you'd like to bring up? >> >> Barry and Joshua, VWRAP chairs >> _______________________________________________ >> 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 Jan 15 08:24: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 4066F3A6DB9 for ; Sat, 15 Jan 2011 08:24:02 -0800 (PST) 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 Xv2WWVMuBt2Z for ; Sat, 15 Jan 2011 08:24: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 6E7683A6DB8 for ; Sat, 15 Jan 2011 08:24:00 -0800 (PST) Received: by qwi2 with SMTP id 2so3768220qwi.31 for ; Sat, 15 Jan 2011 08:26:29 -0800 (PST) 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=wy1WlwKX1U4Qk1oeZSCnlgayiyRSvc+RvTAwFljFBpg=; b=j1qtXHZAF0/KpCpiFZwvMtZhP3lSAwP0hEDts7DsAswFdCOHkMMOuETyDjUET7UDjn OLTh+KhLzAgRoK6TlFKcw62dW6WfYnVA1+RNz1rP8XGu58SCKhfbpRTUWYvdq+AKF/cC o4Wresc0YUlhGPDDmvYkCPQTaik0CL9iPooQs= 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=j9Wv8OEZaPoTrcrO62jErc3fYLaVHAGQV7PHZC/o9vk1wWIBv3tTjkHSdpmWoW+35/ oIpFLgfRj192+3ih4Tp1zEcyGWX26t+vDTxi7D9o0/CQBcsfsVSnGd+snMQmxcqF7QM1 Z97PV9PqtYyW3Lp3lxN4gwlkeD3siCKJEY+bM= Received: by 10.224.67.78 with SMTP id q14mr1964482qai.258.1295108787909; Sat, 15 Jan 2011 08:26:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 08:26:07 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 08:26:07 -0800 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] 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, 15 Jan 2011 16:24:02 -0000 Hey Barry, so it seems like there's at least some interest for rechartering. what's the mechanics for that? do we call for a new BoF or just hash out a new charter on the mailing list? -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca wr= ote: > Although i have only been operating in the fringe of this group, i > would like to argue for #2 > > It clear that some refocussing and consensus building is needed, but > we should at least =A0give that a try. To me it seems definitely to > early to give up. If we try #2 =A0it will become clear if =A0#3 can > indedeed be avoided. > > I see christina's point of starting at the basis, and fixing SSO > first. However, I feel that from the perspective of VWRAP SSO is > actually a well described sub-problem that can be left to others to > solve, while we focus on the specific =A0of avatars and assets. > > In =A0terms of actual commitment, i think the wiki idea is great, and i > will try to free some time to contribute there in the near future. > > --Vaughn > > On 1/15/11, Cristina Videira Lopes wrote: >> I'm leaning towards #2 and #3 simultaneously :) >> Let me explain. >> >> The goal of achieving virtual world interoperability always felt like a >> niche goal to me, but one that, given the nature of these applications, >> touched on a couple of more foundational issues: single sign ons and Web >> services security -- in short, federations that cross enterprise boundar= ies. >> >> There is a variety of implementations for SSOs out there, more recently >> the one in the Hypergrid, and a variety of ways of securing Web >> services. But no standards that I know of -- apart from the SOAP stuff. >> Perhaps this group should band with others who may be interested in >> standardizing these things -- SSO seems like it's ripe for that. In >> other words, let's join with others on common foundational issues, >> rather than separating from them along the lines of application domains >> (VWs vs everything else). >> >> In that sense I'd argue for #3, because doing an IETF SSO working group >> properly would require substantial change and outreach. There's a long >> history in SSOs. The good news is that from what I read in [1], there is >> now some interest in the IETF on this. >> >> However, some issues are application-domain-specific -- e.g. avatars, >> assets; =A0in the Web model, these are MIME type issues. They need >> standardization too -- or at least generalized agreement on the data >> that gets passed around. >> >> In that sense I'd argue for #2. There are MIME type standards that this >> group can define specifically for virtual worlds. That's one part of >> interoperability that only ppl in the VW field can tackle. >> >> Crista / Diva >> >> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >> >> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>> Good day, all. >>> The chairs and area directors have been talking about the status and >>> future of the VWRAP working group. =A0Owing to changes in focus and >>> commitment by both companies and individuals, things have been >>> languishing, and it's not clear to us that we have what we need to get >>> the chartered work done. =A0The introduction document looked close to >>> ready, until some controversy on its content and direction brewed, and >>> the result of that discussion was inconclusive. =A0The normative drafts >>> that have seen some implementation (type system, launch message, etc.) >>> also appear nearly technically complete, but some issues have been >>> identified and not resolved by subsequent discussion, consensus, and >>> editing. >>> >>> At this point, the mailing list has been too quiet for too long, all >>> the draft documents have expired, and we need to make a decision about >>> what to do. >>> >>> The chairs and ADs see three possibilities: >>> >>> 1. Find new document editors, pick up the chartered work with the >>> existing document base, and get moving again. =A0Get the introduction >>> document finished by the end of February, and make progress on the >>> others. >>> >>> 2. Come to consensus on significant changes to the direction of the >>> VWRAP specs, find new document editors, revamp the introduction >>> document, and get that finished, or substantially so, by the end of >>> February. =A0Have some clear consensus, clear direction, and enthusiasm >>> to continue. =A0Consider rechartering, if the direction has changed >>> enough to require that. >>> >>> 3. Accept that we no longer have enough core participation, consensus, >>> and enthusiasm to make progress, and close the working group. =A0Future >>> work in the virtual world area could charter a new working group >>> later. >>> >>> Note that options 1 and 2 both require that we demonstrate sufficient >>> energy and participation to really get work done and to demonstrate >>> consensus. =A0That means that we need people to commit to >>> writing/editing documents, actively discussing the technical issues >>> with the goal of reaching consensus on the content of the documents, >>> and, importantly, reviewing documents and showing that we have >>> consensus. =A0Three or four participants isn't enough, and conflicting >>> ideas that can't be resolved into a consensus-based position won't >>> work. >>> >>> What say you, VWRAP participants? =A0Can we pick up the work and make >>> progress? =A0Shall we close the working group, and perhaps consider >>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you = see >>> an alternative option you'd like to bring up? >>> >>> Barry and Joshua, VWRAP chairs >>> _______________________________________________ >>> 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 Jan 15 10:09: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 BC0E83A6DE1 for ; Sat, 15 Jan 2011 10:09:06 -0800 (PST) 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 ifq6znVvZuKW for ; Sat, 15 Jan 2011 10:09:05 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A60BE3A6DDF for ; Sat, 15 Jan 2011 10:09:04 -0800 (PST) Received: by ewy8 with SMTP id 8so2088504ewy.31 for ; Sat, 15 Jan 2011 10:11:32 -0800 (PST) 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=Ml98xj3e9U147oldkax/6VbDJoGRUakvfs/Eq3Gf5bY=; b=W7MK9y5c+Jr4FQHTDRL0LoPjUoDSFRbPl3f6S/OWd3bZkyQPNisiORD125BjugvbvD 3T6rHcCJsGL9h3tQ8LkJbm3XUCp0iV0+J0sLMkQeGzb/tOeV4jzIApubD/mCOVndniPQ e3ZzBOt1QlckyUFRnHDkcijPnd3DJ8cNb+pso= 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=xkqDdWK9ctgizITjZOamB7yHRU5/Lf2D8/DJq+dToCFix2Gld58z2SlRFp4mHVL94C 8YF2WpTQAo6hIRZ8OjKiWhxYCd6vFplJnvvc08Rm3GgVfh/Ef3SSqL1w4s+Vt/C/Yqiw PiHiRXL0/NwjpIp2QtAjKqdfrn/YbLsKXk5aE= MIME-Version: 1.0 Received: by 10.213.34.142 with SMTP id l14mr867617ebd.39.1295115091583; Sat, 15 Jan 2011 10:11:31 -0800 (PST) Received: by 10.213.8.78 with HTTP; Sat, 15 Jan 2011 10:11:31 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 19:11:31 +0100 Message-ID: From: Vaughn Deluca 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: Sat, 15 Jan 2011 18:09:06 -0000 I am not convinced rechartering is actually needed. The introduction document certainly needs an overhaul, and we to need to reaffirm we are all on the same track, but I think that the existing charter might still work for us. I suggest we work with it, at least until it becomes the obvious obstacle for progress. -- Vaughn On 1/15/11, Meadhbh Hamrick wrote: > Hey Barry, > > so it seems like there's at least some interest for rechartering. > what's the mechanics for that? do we call for a new BoF or just hash > out a new charter on the mailing list? > > -cheers > -meadhbh > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca > wrote: >> Although i have only been operating in the fringe of this group, i >> would like to argue for #2 >> >> It clear that some refocussing and consensus building is needed, but >> we should at least =A0give that a try. To me it seems definitely to >> early to give up. If we try #2 =A0it will become clear if =A0#3 can >> indedeed be avoided. >> >> I see christina's point of starting at the basis, and fixing SSO >> first. However, I feel that from the perspective of VWRAP SSO is >> actually a well described sub-problem that can be left to others to >> solve, while we focus on the specific =A0of avatars and assets. >> >> In =A0terms of actual commitment, i think the wiki idea is great, and i >> will try to free some time to contribute there in the near future. >> >> --Vaughn >> >> On 1/15/11, Cristina Videira Lopes wrote: >>> I'm leaning towards #2 and #3 simultaneously :) >>> Let me explain. >>> >>> The goal of achieving virtual world interoperability always felt like a >>> niche goal to me, but one that, given the nature of these applications, >>> touched on a couple of more foundational issues: single sign ons and We= b >>> services security -- in short, federations that cross enterprise >>> boundaries. >>> >>> There is a variety of implementations for SSOs out there, more recently >>> the one in the Hypergrid, and a variety of ways of securing Web >>> services. But no standards that I know of -- apart from the SOAP stuff. >>> Perhaps this group should band with others who may be interested in >>> standardizing these things -- SSO seems like it's ripe for that. In >>> other words, let's join with others on common foundational issues, >>> rather than separating from them along the lines of application domains >>> (VWs vs everything else). >>> >>> In that sense I'd argue for #3, because doing an IETF SSO working group >>> properly would require substantial change and outreach. There's a long >>> history in SSOs. The good news is that from what I read in [1], there i= s >>> now some interest in the IETF on this. >>> >>> However, some issues are application-domain-specific -- e.g. avatars, >>> assets; =A0in the Web model, these are MIME type issues. They need >>> standardization too -- or at least generalized agreement on the data >>> that gets passed around. >>> >>> In that sense I'd argue for #2. There are MIME type standards that this >>> group can define specifically for virtual worlds. That's one part of >>> interoperability that only ppl in the VW field can tackle. >>> >>> Crista / Diva >>> >>> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >>> >>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>> Good day, all. >>>> The chairs and area directors have been talking about the status and >>>> future of the VWRAP working group. =A0Owing to changes in focus and >>>> commitment by both companies and individuals, things have been >>>> languishing, and it's not clear to us that we have what we need to get >>>> the chartered work done. =A0The introduction document looked close to >>>> ready, until some controversy on its content and direction brewed, and >>>> the result of that discussion was inconclusive. =A0The normative draft= s >>>> that have seen some implementation (type system, launch message, etc.) >>>> also appear nearly technically complete, but some issues have been >>>> identified and not resolved by subsequent discussion, consensus, and >>>> editing. >>>> >>>> At this point, the mailing list has been too quiet for too long, all >>>> the draft documents have expired, and we need to make a decision about >>>> what to do. >>>> >>>> The chairs and ADs see three possibilities: >>>> >>>> 1. Find new document editors, pick up the chartered work with the >>>> existing document base, and get moving again. =A0Get the introduction >>>> document finished by the end of February, and make progress on the >>>> others. >>>> >>>> 2. Come to consensus on significant changes to the direction of the >>>> VWRAP specs, find new document editors, revamp the introduction >>>> document, and get that finished, or substantially so, by the end of >>>> February. =A0Have some clear consensus, clear direction, and enthusias= m >>>> to continue. =A0Consider rechartering, if the direction has changed >>>> enough to require that. >>>> >>>> 3. Accept that we no longer have enough core participation, consensus, >>>> and enthusiasm to make progress, and close the working group. =A0Futur= e >>>> work in the virtual world area could charter a new working group >>>> later. >>>> >>>> Note that options 1 and 2 both require that we demonstrate sufficient >>>> energy and participation to really get work done and to demonstrate >>>> consensus. =A0That means that we need people to commit to >>>> writing/editing documents, actively discussing the technical issues >>>> with the goal of reaching consensus on the content of the documents, >>>> and, importantly, reviewing documents and showing that we have >>>> consensus. =A0Three or four participants isn't enough, and conflicting >>>> ideas that can't be resolved into a consensus-based position won't >>>> work. >>>> >>>> What say you, VWRAP participants? =A0Can we pick up the work and make >>>> progress? =A0Shall we close the working group, and perhaps consider >>>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do you= see >>>> an alternative option you'd like to bring up? >>>> >>>> Barry and Joshua, VWRAP chairs >>>> _______________________________________________ >>>> 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 ohmeadhbh@gmail.com Sat Jan 15 10:46: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 2F7503A6E05 for ; Sat, 15 Jan 2011 10:46:21 -0800 (PST) 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 jwxaZUzWLF5Q for ; Sat, 15 Jan 2011 10:46:19 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 5C1C23A6E04 for ; Sat, 15 Jan 2011 10:46:19 -0800 (PST) Received: by vws7 with SMTP id 7so1509193vws.31 for ; Sat, 15 Jan 2011 10:48:48 -0800 (PST) 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=2nIniAR12QLGJmhmjNHoVnlU69mP9LHbqdbmCcI42nU=; b=a8tVPEsjLtSz0TycG4TYzSgLr0zju4R/GaFikmMjVpGBi6yQO0sRRB1KF5zLOYzQZl LOFg6of+pulkkRVrr3C9dremmVBxs1XO1MaD+Eu/zli+0gQCyBslo4yErRfZM2rGzUIR J4ivYl8RpiERuIfdDO3+EW+qkNMTWQKVUqTw4= 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=LNbVBcLLY0pCu0yYKg1uF+EB7NfbVssCg2mE1m//Jh384b3Jtjb3GfkxmwgQ/5C/zu rpHmiSJmsP+4niq+2wBE8eFdbPs+qhNvCfFI5i5SF5hISFPZT180GycvXieTcrIYqzba jSCSDmki7WkjQuSg+RjKUTQgFyVGewsqrDILw= Received: by 10.220.202.8 with SMTP id fc8mr677809vcb.104.1295117326066; Sat, 15 Jan 2011 10:48:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 10:48:25 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 10:48:25 -0800 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] 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, 15 Jan 2011 18:46:21 -0000 you're voting for option 1 then, but are you volunteering to do the work? the current intro XML is in SVN at http://svn.tools.ietf.org/svn/wg/vwrap/ you can check them out with the command: svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents if there's interest, i'm happy to put on a 30 minute "how to edit, write and publish an internet draft" presentation in world somewhere. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Jan 15, 2011 at 10:11 AM, Vaughn Deluca w= rote: > I am not convinced rechartering is actually needed. The introduction > document certainly needs an overhaul, and we to need to reaffirm we > are all on the same track, but I think that the existing charter might > still work for us. I suggest we work with it, at least until it > becomes the obvious obstacle for progress. > > -- Vaughn > > > > On 1/15/11, Meadhbh Hamrick wrote: >> Hey Barry, >> >> so it seems like there's at least some interest for rechartering. >> what's the mechanics for that? do we call for a new BoF or just hash >> out a new charter on the mailing list? >> >> -cheers >> -meadhbh >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca >> wrote: >>> Although i have only been operating in the fringe of this group, i >>> would like to argue for #2 >>> >>> It clear that some refocussing and consensus building is needed, but >>> we should at least =A0give that a try. To me it seems definitely to >>> early to give up. If we try #2 =A0it will become clear if =A0#3 can >>> indedeed be avoided. >>> >>> I see christina's point of starting at the basis, and fixing SSO >>> first. However, I feel that from the perspective of VWRAP SSO is >>> actually a well described sub-problem that can be left to others to >>> solve, while we focus on the specific =A0of avatars and assets. >>> >>> In =A0terms of actual commitment, i think the wiki idea is great, and i >>> will try to free some time to contribute there in the near future. >>> >>> --Vaughn >>> >>> On 1/15/11, Cristina Videira Lopes wrote: >>>> I'm leaning towards #2 and #3 simultaneously :) >>>> Let me explain. >>>> >>>> The goal of achieving virtual world interoperability always felt like = a >>>> niche goal to me, but one that, given the nature of these applications= , >>>> touched on a couple of more foundational issues: single sign ons and W= eb >>>> services security -- in short, federations that cross enterprise >>>> boundaries. >>>> >>>> There is a variety of implementations for SSOs out there, more recentl= y >>>> the one in the Hypergrid, and a variety of ways of securing Web >>>> services. But no standards that I know of -- apart from the SOAP stuff= . >>>> Perhaps this group should band with others who may be interested in >>>> standardizing these things -- SSO seems like it's ripe for that. In >>>> other words, let's join with others on common foundational issues, >>>> rather than separating from them along the lines of application domain= s >>>> (VWs vs everything else). >>>> >>>> In that sense I'd argue for #3, because doing an IETF SSO working grou= p >>>> properly would require substantial change and outreach. There's a long >>>> history in SSOs. The good news is that from what I read in [1], there = is >>>> now some interest in the IETF on this. >>>> >>>> However, some issues are application-domain-specific -- e.g. avatars, >>>> assets; =A0in the Web model, these are MIME type issues. They need >>>> standardization too -- or at least generalized agreement on the data >>>> that gets passed around. >>>> >>>> In that sense I'd argue for #2. There are MIME type standards that thi= s >>>> group can define specifically for virtual worlds. That's one part of >>>> interoperability that only ppl in the VW field can tackle. >>>> >>>> Crista / Diva >>>> >>>> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >>>> >>>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>>> Good day, all. >>>>> The chairs and area directors have been talking about the status and >>>>> future of the VWRAP working group. =A0Owing to changes in focus and >>>>> commitment by both companies and individuals, things have been >>>>> languishing, and it's not clear to us that we have what we need to ge= t >>>>> the chartered work done. =A0The introduction document looked close to >>>>> ready, until some controversy on its content and direction brewed, an= d >>>>> the result of that discussion was inconclusive. =A0The normative draf= ts >>>>> that have seen some implementation (type system, launch message, etc.= ) >>>>> also appear nearly technically complete, but some issues have been >>>>> identified and not resolved by subsequent discussion, consensus, and >>>>> editing. >>>>> >>>>> At this point, the mailing list has been too quiet for too long, all >>>>> the draft documents have expired, and we need to make a decision abou= t >>>>> what to do. >>>>> >>>>> The chairs and ADs see three possibilities: >>>>> >>>>> 1. Find new document editors, pick up the chartered work with the >>>>> existing document base, and get moving again. =A0Get the introduction >>>>> document finished by the end of February, and make progress on the >>>>> others. >>>>> >>>>> 2. Come to consensus on significant changes to the direction of the >>>>> VWRAP specs, find new document editors, revamp the introduction >>>>> document, and get that finished, or substantially so, by the end of >>>>> February. =A0Have some clear consensus, clear direction, and enthusia= sm >>>>> to continue. =A0Consider rechartering, if the direction has changed >>>>> enough to require that. >>>>> >>>>> 3. Accept that we no longer have enough core participation, consensus= , >>>>> and enthusiasm to make progress, and close the working group. =A0Futu= re >>>>> work in the virtual world area could charter a new working group >>>>> later. >>>>> >>>>> Note that options 1 and 2 both require that we demonstrate sufficient >>>>> energy and participation to really get work done and to demonstrate >>>>> consensus. =A0That means that we need people to commit to >>>>> writing/editing documents, actively discussing the technical issues >>>>> with the goal of reaching consensus on the content of the documents, >>>>> and, importantly, reviewing documents and showing that we have >>>>> consensus. =A0Three or four participants isn't enough, and conflictin= g >>>>> ideas that can't be resolved into a consensus-based position won't >>>>> work. >>>>> >>>>> What say you, VWRAP participants? =A0Can we pick up the work and make >>>>> progress? =A0Shall we close the working group, and perhaps consider >>>>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do yo= u see >>>>> an alternative option you'd like to bring up? >>>>> >>>>> Barry and Joshua, VWRAP chairs >>>>> _______________________________________________ >>>>> 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 Jan 15 12:09: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 2C3ED28C0D8 for ; Sat, 15 Jan 2011 12:09:55 -0800 (PST) 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 q0TI1ZbBtJCU for ; Sat, 15 Jan 2011 12:09:53 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 102F928B56A for ; Sat, 15 Jan 2011 12:09:52 -0800 (PST) Received: by eyd10 with SMTP id 10so2134862eyd.31 for ; Sat, 15 Jan 2011 12:12:21 -0800 (PST) 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=S3W2FbxuYyZtp5KK6Ixi51h/5zrUyruJUWwsFjB2jPg=; b=Z7aQ5KXcuLxxDQUJqxCy5APodRGHZ2XPtt6DlzQzGrJ4NcKRxF48xf+Tn5TIheOhIZ oLGOUo3NbKg1ekEji3qgr+Tvc6HKGyx+6VTsUwe/tr4WASG9cEj69ZfTErl4CmOVS2Sb RV7mSbhRRnY5suLg3J239NzLBRWAY+yogq7kY= 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=eAWaCor+s32H5lUjQHYZCeEgyJ4DLb+jvvVWfmnH0PH1sAkH3PoalvEruR8Bh+fd9l zPJWVYM11WCUUpxM/1p6m3YVODdIfmMXW78Vts1Suu7Ty6KyGdvgLiJLalyp8hePea6H EOrxp1+2gvg/KM0JwiIXpIuremOzPQ2eFi3/A= MIME-Version: 1.0 Received: by 10.213.28.69 with SMTP id l5mr2148051ebc.13.1295122340169; Sat, 15 Jan 2011 12:12:20 -0800 (PST) Received: by 10.213.8.78 with HTTP; Sat, 15 Jan 2011 12:12:20 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sat, 15 Jan 2011 21:12:20 +0100 Message-ID: From: Vaughn Deluca 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: Sat, 15 Jan 2011 20:09:55 -0000 No, i am voting for option 2. Barry wrote: "2. Come to consensus on significant changes to the direction of the VWRAP specs[...] Consider rechartering, if the direction has changed enough to require that." All i am saying is that i don't see the need for rechartering *yet*. --Vaughn On 1/15/11, Meadhbh Hamrick wrote: > you're voting for option 1 then, but are you volunteering to do the work? > > the current intro XML is in SVN at http://svn.tools.ietf.org/svn/wg/vwrap= / > > you can check them out with the command: > > svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents > > if there's interest, i'm happy to put on a 30 minute "how to edit, > write and publish an internet draft" presentation in world somewhere. > > -cheers > -meadhbh > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Jan 15, 2011 at 10:11 AM, Vaughn Deluca > wrote: >> I am not convinced rechartering is actually needed. The introduction >> document certainly needs an overhaul, and we to need to reaffirm we >> are all on the same track, but I think that the existing charter might >> still work for us. I suggest we work with it, at least until it >> becomes the obvious obstacle for progress. >> >> -- Vaughn >> >> >> >> On 1/15/11, Meadhbh Hamrick wrote: >>> Hey Barry, >>> >>> so it seems like there's at least some interest for rechartering. >>> what's the mechanics for that? do we call for a new BoF or just hash >>> out a new charter on the mailing list? >>> >>> -cheers >>> -meadhbh >>> >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca >>> wrote: >>>> Although i have only been operating in the fringe of this group, i >>>> would like to argue for #2 >>>> >>>> It clear that some refocussing and consensus building is needed, but >>>> we should at least =A0give that a try. To me it seems definitely to >>>> early to give up. If we try #2 =A0it will become clear if =A0#3 can >>>> indedeed be avoided. >>>> >>>> I see christina's point of starting at the basis, and fixing SSO >>>> first. However, I feel that from the perspective of VWRAP SSO is >>>> actually a well described sub-problem that can be left to others to >>>> solve, while we focus on the specific =A0of avatars and assets. >>>> >>>> In =A0terms of actual commitment, i think the wiki idea is great, and = i >>>> will try to free some time to contribute there in the near future. >>>> >>>> --Vaughn >>>> >>>> On 1/15/11, Cristina Videira Lopes wrote: >>>>> I'm leaning towards #2 and #3 simultaneously :) >>>>> Let me explain. >>>>> >>>>> The goal of achieving virtual world interoperability always felt like= a >>>>> niche goal to me, but one that, given the nature of these application= s, >>>>> touched on a couple of more foundational issues: single sign ons and >>>>> Web >>>>> services security -- in short, federations that cross enterprise >>>>> boundaries. >>>>> >>>>> There is a variety of implementations for SSOs out there, more recent= ly >>>>> the one in the Hypergrid, and a variety of ways of securing Web >>>>> services. But no standards that I know of -- apart from the SOAP stuf= f. >>>>> Perhaps this group should band with others who may be interested in >>>>> standardizing these things -- SSO seems like it's ripe for that. In >>>>> other words, let's join with others on common foundational issues, >>>>> rather than separating from them along the lines of application domai= ns >>>>> (VWs vs everything else). >>>>> >>>>> In that sense I'd argue for #3, because doing an IETF SSO working gro= up >>>>> properly would require substantial change and outreach. There's a lon= g >>>>> history in SSOs. The good news is that from what I read in [1], there >>>>> is >>>>> now some interest in the IETF on this. >>>>> >>>>> However, some issues are application-domain-specific -- e.g. avatars, >>>>> assets; =A0in the Web model, these are MIME type issues. They need >>>>> standardization too -- or at least generalized agreement on the data >>>>> that gets passed around. >>>>> >>>>> In that sense I'd argue for #2. There are MIME type standards that th= is >>>>> group can define specifically for virtual worlds. That's one part of >>>>> interoperability that only ppl in the VW field can tackle. >>>>> >>>>> Crista / Diva >>>>> >>>>> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >>>>> >>>>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>>>> Good day, all. >>>>>> The chairs and area directors have been talking about the status and >>>>>> future of the VWRAP working group. =A0Owing to changes in focus and >>>>>> commitment by both companies and individuals, things have been >>>>>> languishing, and it's not clear to us that we have what we need to g= et >>>>>> the chartered work done. =A0The introduction document looked close t= o >>>>>> ready, until some controversy on its content and direction brewed, a= nd >>>>>> the result of that discussion was inconclusive. =A0The normative dra= fts >>>>>> that have seen some implementation (type system, launch message, etc= .) >>>>>> also appear nearly technically complete, but some issues have been >>>>>> identified and not resolved by subsequent discussion, consensus, and >>>>>> editing. >>>>>> >>>>>> At this point, the mailing list has been too quiet for too long, all >>>>>> the draft documents have expired, and we need to make a decision abo= ut >>>>>> what to do. >>>>>> >>>>>> The chairs and ADs see three possibilities: >>>>>> >>>>>> 1. Find new document editors, pick up the chartered work with the >>>>>> existing document base, and get moving again. =A0Get the introductio= n >>>>>> document finished by the end of February, and make progress on the >>>>>> others. >>>>>> >>>>>> 2. Come to consensus on significant changes to the direction of the >>>>>> VWRAP specs, find new document editors, revamp the introduction >>>>>> document, and get that finished, or substantially so, by the end of >>>>>> February. =A0Have some clear consensus, clear direction, and enthusi= asm >>>>>> to continue. =A0Consider rechartering, if the direction has changed >>>>>> enough to require that. >>>>>> >>>>>> 3. Accept that we no longer have enough core participation, consensu= s, >>>>>> and enthusiasm to make progress, and close the working group. =A0Fut= ure >>>>>> work in the virtual world area could charter a new working group >>>>>> later. >>>>>> >>>>>> Note that options 1 and 2 both require that we demonstrate sufficien= t >>>>>> energy and participation to really get work done and to demonstrate >>>>>> consensus. =A0That means that we need people to commit to >>>>>> writing/editing documents, actively discussing the technical issues >>>>>> with the goal of reaching consensus on the content of the documents, >>>>>> and, importantly, reviewing documents and showing that we have >>>>>> consensus. =A0Three or four participants isn't enough, and conflicti= ng >>>>>> ideas that can't be resolved into a consensus-based position won't >>>>>> work. >>>>>> >>>>>> What say you, VWRAP participants? =A0Can we pick up the work and mak= e >>>>>> progress? =A0Shall we close the working group, and perhaps consider >>>>>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do y= ou see >>>>>> an alternative option you'd like to bring up? >>>>>> >>>>>> Barry and Joshua, VWRAP chairs >>>>>> _______________________________________________ >>>>>> 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 ohmeadhbh@gmail.com Sat Jan 15 13:25: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 0DD553A6D6E for ; Sat, 15 Jan 2011 13:25:37 -0800 (PST) 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 X5G4llO9RrFH for ; Sat, 15 Jan 2011 13:25:35 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E64363A6D0A for ; Sat, 15 Jan 2011 13:25:34 -0800 (PST) Received: by vws7 with SMTP id 7so1544840vws.31 for ; Sat, 15 Jan 2011 13:28:04 -0800 (PST) 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=tYwvv/lXcchYKrKuBLUbZUxVT3xpJ/Cw8z28WIPrqdM=; b=TkMu21jbsUg4yyi6itFhaH39OLcISo4fiaAx379jV7z0Fi5cnsJB4H1TizAn+MITBr awL7ZI92qbSBh1eMVLxsp7OeyNu5l2j8c3NM++BAnwF3WuU9x+Kspfpw/q/4i4TNTKtw ObzvfSL6jQh94swFcm9KB4yPFXoLt7t9k2kjg= 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=UcFAV8FZX5gsoSuhCW4ZR+Eg2Pxz/A2qDL3ZdYgANhONNQlwl58+OnOMWJtjl9rfQR xaSHiWSB8DLjo9E3LGwpnqzZM68j+YqJUgiM+c4TCFGuWogyfz5kbQ4xJSqwExsU87PV Lx//8LXNHhvadUrdySsEPOO/Zn9OuwshZa1T0= Received: by 10.220.202.8 with SMTP id fc8mr714568vcb.104.1295126883412; Sat, 15 Jan 2011 13:28:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 13:27:42 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 13:27:42 -0800 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] 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, 15 Jan 2011 21:25:37 -0000 whoops. yes. meant to say "you're voting for option #2" but my original point was that there's a fair amount of work to be done, and i was asking if you were going to re-write the intro. if we can't find anyone willing to do the work, we might have to go with option #3. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Jan 15, 2011 at 12:12 PM, Vaughn Deluca w= rote: > No, i am voting for option 2. Barry wrote: > > "2. Come to consensus on significant changes to the direction of the > VWRAP specs[...] =A0Consider rechartering, if the direction has changed > enough to require that." > > All i am saying is that i don't see the need for rechartering *yet*. > > --Vaughn > > On 1/15/11, Meadhbh Hamrick wrote: >> you're voting for option 1 then, but are you volunteering to do the work= ? >> >> the current intro XML is in SVN at http://svn.tools.ietf.org/svn/wg/vwra= p/ >> >> you can check them out with the command: >> >> svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents >> >> if there's interest, i'm happy to put on a 30 minute "how to edit, >> write and publish an internet draft" presentation in world somewhere. >> >> -cheers >> -meadhbh >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Jan 15, 2011 at 10:11 AM, Vaughn Deluca >> wrote: >>> I am not convinced rechartering is actually needed. The introduction >>> document certainly needs an overhaul, and we to need to reaffirm we >>> are all on the same track, but I think that the existing charter might >>> still work for us. I suggest we work with it, at least until it >>> becomes the obvious obstacle for progress. >>> >>> -- Vaughn >>> >>> >>> >>> On 1/15/11, Meadhbh Hamrick wrote: >>>> Hey Barry, >>>> >>>> so it seems like there's at least some interest for rechartering. >>>> what's the mechanics for that? do we call for a new BoF or just hash >>>> out a new charter on the mailing list? >>>> >>>> -cheers >>>> -meadhbh >>>> >>>> -- >>>> meadhbh hamrick * it's pronounced "maeve" >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>> >>>> >>>> >>>> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca >>>> wrote: >>>>> Although i have only been operating in the fringe of this group, i >>>>> would like to argue for #2 >>>>> >>>>> It clear that some refocussing and consensus building is needed, but >>>>> we should at least =A0give that a try. To me it seems definitely to >>>>> early to give up. If we try #2 =A0it will become clear if =A0#3 can >>>>> indedeed be avoided. >>>>> >>>>> I see christina's point of starting at the basis, and fixing SSO >>>>> first. However, I feel that from the perspective of VWRAP SSO is >>>>> actually a well described sub-problem that can be left to others to >>>>> solve, while we focus on the specific =A0of avatars and assets. >>>>> >>>>> In =A0terms of actual commitment, i think the wiki idea is great, and= i >>>>> will try to free some time to contribute there in the near future. >>>>> >>>>> --Vaughn >>>>> >>>>> On 1/15/11, Cristina Videira Lopes wrote: >>>>>> I'm leaning towards #2 and #3 simultaneously :) >>>>>> Let me explain. >>>>>> >>>>>> The goal of achieving virtual world interoperability always felt lik= e a >>>>>> niche goal to me, but one that, given the nature of these applicatio= ns, >>>>>> touched on a couple of more foundational issues: single sign ons and >>>>>> Web >>>>>> services security -- in short, federations that cross enterprise >>>>>> boundaries. >>>>>> >>>>>> There is a variety of implementations for SSOs out there, more recen= tly >>>>>> the one in the Hypergrid, and a variety of ways of securing Web >>>>>> services. But no standards that I know of -- apart from the SOAP stu= ff. >>>>>> Perhaps this group should band with others who may be interested in >>>>>> standardizing these things -- SSO seems like it's ripe for that. In >>>>>> other words, let's join with others on common foundational issues, >>>>>> rather than separating from them along the lines of application doma= ins >>>>>> (VWs vs everything else). >>>>>> >>>>>> In that sense I'd argue for #3, because doing an IETF SSO working gr= oup >>>>>> properly would require substantial change and outreach. There's a lo= ng >>>>>> history in SSOs. The good news is that from what I read in [1], ther= e >>>>>> is >>>>>> now some interest in the IETF on this. >>>>>> >>>>>> However, some issues are application-domain-specific -- e.g. avatars= , >>>>>> assets; =A0in the Web model, these are MIME type issues. They need >>>>>> standardization too -- or at least generalized agreement on the data >>>>>> that gets passed around. >>>>>> >>>>>> In that sense I'd argue for #2. There are MIME type standards that t= his >>>>>> group can define specifically for virtual worlds. That's one part of >>>>>> interoperability that only ppl in the VW field can tackle. >>>>>> >>>>>> Crista / Diva >>>>>> >>>>>> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >>>>>> >>>>>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>>>>> Good day, all. >>>>>>> The chairs and area directors have been talking about the status an= d >>>>>>> future of the VWRAP working group. =A0Owing to changes in focus and >>>>>>> commitment by both companies and individuals, things have been >>>>>>> languishing, and it's not clear to us that we have what we need to = get >>>>>>> the chartered work done. =A0The introduction document looked close = to >>>>>>> ready, until some controversy on its content and direction brewed, = and >>>>>>> the result of that discussion was inconclusive. =A0The normative dr= afts >>>>>>> that have seen some implementation (type system, launch message, et= c.) >>>>>>> also appear nearly technically complete, but some issues have been >>>>>>> identified and not resolved by subsequent discussion, consensus, an= d >>>>>>> editing. >>>>>>> >>>>>>> At this point, the mailing list has been too quiet for too long, al= l >>>>>>> the draft documents have expired, and we need to make a decision ab= out >>>>>>> what to do. >>>>>>> >>>>>>> The chairs and ADs see three possibilities: >>>>>>> >>>>>>> 1. Find new document editors, pick up the chartered work with the >>>>>>> existing document base, and get moving again. =A0Get the introducti= on >>>>>>> document finished by the end of February, and make progress on the >>>>>>> others. >>>>>>> >>>>>>> 2. Come to consensus on significant changes to the direction of the >>>>>>> VWRAP specs, find new document editors, revamp the introduction >>>>>>> document, and get that finished, or substantially so, by the end of >>>>>>> February. =A0Have some clear consensus, clear direction, and enthus= iasm >>>>>>> to continue. =A0Consider rechartering, if the direction has changed >>>>>>> enough to require that. >>>>>>> >>>>>>> 3. Accept that we no longer have enough core participation, consens= us, >>>>>>> and enthusiasm to make progress, and close the working group. =A0Fu= ture >>>>>>> work in the virtual world area could charter a new working group >>>>>>> later. >>>>>>> >>>>>>> Note that options 1 and 2 both require that we demonstrate sufficie= nt >>>>>>> energy and participation to really get work done and to demonstrate >>>>>>> consensus. =A0That means that we need people to commit to >>>>>>> writing/editing documents, actively discussing the technical issues >>>>>>> with the goal of reaching consensus on the content of the documents= , >>>>>>> and, importantly, reviewing documents and showing that we have >>>>>>> consensus. =A0Three or four participants isn't enough, and conflict= ing >>>>>>> ideas that can't be resolved into a consensus-based position won't >>>>>>> work. >>>>>>> >>>>>>> What say you, VWRAP participants? =A0Can we pick up the work and ma= ke >>>>>>> progress? =A0Shall we close the working group, and perhaps consider >>>>>>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or do = you see >>>>>>> an alternative option you'd like to bring up? >>>>>>> >>>>>>> Barry and Joshua, VWRAP chairs >>>>>>> _______________________________________________ >>>>>>> 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 ohmeadhbh@gmail.com Sat Jan 15 13:39: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 700693A6D64 for ; Sat, 15 Jan 2011 13:39:42 -0800 (PST) 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 aRoydCo73Zbi for ; Sat, 15 Jan 2011 13:39:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 36AAB3A6D63 for ; Sat, 15 Jan 2011 13:39:40 -0800 (PST) Received: by vws7 with SMTP id 7so1548271vws.31 for ; Sat, 15 Jan 2011 13:42:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=AcBit6rm6UFmy0+UPdG/VOIMAhlu7VreCDyIPr879mI=; b=xSU2lYTiZVuDgQLhnJcLPeAzxc7fIRjCj/6/1RwNmS/Zn37i0VJ925TIseFspmjVRK fEPHwNTaWQsgDd/De4Vjq6RGn4U0MoOsRd9Wjaq0hM88jKcMjqMzD/5lKrt0NL7+JZqH 64ktZ2n1pFxQdfTesqVORq3zRVLm8U7VQ7sTQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=JDjvbe/bmH96wPuLgmsgnwe8Bl1x/EzOcS3EOcf5Vq4dBghxX2+u/UlPsUfCwdtjr0 LrnxGyzw2CCzJJy8//Oh0842cNrwfW1br5zziG0CpTmA2kqBp4WgZC+L+1K+o/olTtNc 4PElPoq2mYUBA+rP7WrWbMv59s1I4aM9a0pw4= Received: by 10.220.202.8 with SMTP id fc8mr717967vcb.104.1295127728375; Sat, 15 Jan 2011 13:42:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 13:41:48 -0800 (PST) From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 13:41:48 -0800 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] completely unrelated to existing discussions... lessons from habitat 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, 15 Jan 2011 21:39:42 -0000 i just saw john lester (aka pathfinder) tweet a reference to this paper about the "lessons learned" from lucasfilm's habitat, an early virtual world. thought it would be interesting to list readers. http://www.fudco.com/chip/lessons.html -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From vaughn.deluca@gmail.com Sat Jan 15 15:15: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 2213F3A6BE3 for ; Sat, 15 Jan 2011 15:15:19 -0800 (PST) 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 VasnOML+WNdy for ; Sat, 15 Jan 2011 15:15:17 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 17DBB3A6B96 for ; Sat, 15 Jan 2011 15:15:16 -0800 (PST) Received: by ewy8 with SMTP id 8so2143014ewy.31 for ; Sat, 15 Jan 2011 15:17:46 -0800 (PST) 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=UeYQnyNBrXldqfmXoMyCfn0uQeSD6bPZuNGTw1D9S34=; b=uHOmFp13DdJS5u2626XPjIT4PDmFQoIrlvGDf5LsI4SgstRbxaJ5EQACwCim/go7yW G9/HC0xY4IRivZwrkc2X4A0AUsWgP80nPz9X2O+COgh/sh0QKzGJYVhSzj1aN9VaoMTy zCqjx6B27S+gXwMw4IiBCISSb1QZ6UF7olFgM= 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=VAjbmOF+aflUDNDqiSMm5HbnOBfyC8NtO0ChATldS6l5RSBuaACNUqWEcOTZDSWf0B sMu6csjBFuJQESsfBaHF/DBSzj+l1v8aggI7TWuxRasMVlM3H7EniGSnPSjPQsInzmUN RYMYKY7XUdrnLAXrx0iLCjnl6dOekOLDT2zA4= MIME-Version: 1.0 Received: by 10.213.28.69 with SMTP id l5mr2263838ebc.13.1295133465415; Sat, 15 Jan 2011 15:17:45 -0800 (PST) Received: by 10.213.8.78 with HTTP; Sat, 15 Jan 2011 15:17:45 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Sun, 16 Jan 2011 00:17:45 +0100 Message-ID: From: Vaughn Deluca To: Meadhbh Hamrick 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, 15 Jan 2011 23:15:19 -0000 Meadhbh, Meadhbh, As i stated a few mails back, i am certainly willing to help, but I am not a proffesional in this field, and my expertise is insufficient to play an editors role. -and to be honnest, i do not have the needed time for such a role either. But for sure i will be making contributions to intro document where possible. Option 3 is conflating core participation and consensus/enthusiasm. I am fairly optimistic about the possibility to (eventually) reach consensus, but we might indeed be critically low on core participation. Barry wrote "Three or four participants isn't enough" and he is right. This tread has only a handfull of responses, dangerously close to that level. Close, but not there yet, we will see what happens on the wiki. If *that* fails its time for option 3. --Vaughn On 1/15/11, Meadhbh Hamrick wrote: > whoops. yes. meant to say "you're voting for option #2" > > but my original point was that there's a fair amount of work to be > done, and i was asking if you were going to re-write the intro. if we > can't find anyone willing to do the work, we might have to go with > option #3. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Sat, Jan 15, 2011 at 12:12 PM, Vaughn Deluca > wrote: >> No, i am voting for option 2. Barry wrote: >> >> "2. Come to consensus on significant changes to the direction of the >> VWRAP specs[...] Consider rechartering, if the direction has changed >> enough to require that." >> >> All i am saying is that i don't see the need for rechartering *yet*. >> >> --Vaughn >> >> On 1/15/11, Meadhbh Hamrick wrote: >>> you're voting for option 1 then, but are you volunteering to do the work? >>> >>> the current intro XML is in SVN at >>> http://svn.tools.ietf.org/svn/wg/vwrap/ >>> >>> you can check them out with the command: >>> >>> svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents >>> >>> if there's interest, i'm happy to put on a 30 minute "how to edit, >>> write and publish an internet draft" presentation in world somewhere. >>> >>> -cheers >>> -meadhbh >>> >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Sat, Jan 15, 2011 at 10:11 AM, Vaughn Deluca >>> wrote: >>>> I am not convinced rechartering is actually needed. The introduction >>>> document certainly needs an overhaul, and we to need to reaffirm we >>>> are all on the same track, but I think that the existing charter might >>>> still work for us. I suggest we work with it, at least until it >>>> becomes the obvious obstacle for progress. >>>> >>>> -- Vaughn >>>> >>>> >>>> >>>> On 1/15/11, Meadhbh Hamrick wrote: >>>>> Hey Barry, >>>>> >>>>> so it seems like there's at least some interest for rechartering. >>>>> what's the mechanics for that? do we call for a new BoF or just hash >>>>> out a new charter on the mailing list? >>>>> >>>>> -cheers >>>>> -meadhbh >>>>> >>>>> -- >>>>> meadhbh hamrick * it's pronounced "maeve" >>>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>>> >>>>> >>>>> >>>>> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca >>>>> >>>>> wrote: >>>>>> Although i have only been operating in the fringe of this group, i >>>>>> would like to argue for #2 >>>>>> >>>>>> It clear that some refocussing and consensus building is needed, but >>>>>> we should at least give that a try. To me it seems definitely to >>>>>> early to give up. If we try #2 it will become clear if #3 can >>>>>> indedeed be avoided. >>>>>> >>>>>> I see christina's point of starting at the basis, and fixing SSO >>>>>> first. However, I feel that from the perspective of VWRAP SSO is >>>>>> actually a well described sub-problem that can be left to others to >>>>>> solve, while we focus on the specific of avatars and assets. >>>>>> >>>>>> In terms of actual commitment, i think the wiki idea is great, and i >>>>>> will try to free some time to contribute there in the near future. >>>>>> >>>>>> --Vaughn >>>>>> >>>>>> On 1/15/11, Cristina Videira Lopes wrote: >>>>>>> I'm leaning towards #2 and #3 simultaneously :) >>>>>>> Let me explain. >>>>>>> >>>>>>> The goal of achieving virtual world interoperability always felt like >>>>>>> a >>>>>>> niche goal to me, but one that, given the nature of these >>>>>>> applications, >>>>>>> touched on a couple of more foundational issues: single sign ons and >>>>>>> Web >>>>>>> services security -- in short, federations that cross enterprise >>>>>>> boundaries. >>>>>>> >>>>>>> There is a variety of implementations for SSOs out there, more >>>>>>> recently >>>>>>> the one in the Hypergrid, and a variety of ways of securing Web >>>>>>> services. But no standards that I know of -- apart from the SOAP >>>>>>> stuff. >>>>>>> Perhaps this group should band with others who may be interested in >>>>>>> standardizing these things -- SSO seems like it's ripe for that. In >>>>>>> other words, let's join with others on common foundational issues, >>>>>>> rather than separating from them along the lines of application >>>>>>> domains >>>>>>> (VWs vs everything else). >>>>>>> >>>>>>> In that sense I'd argue for #3, because doing an IETF SSO working >>>>>>> group >>>>>>> properly would require substantial change and outreach. There's a >>>>>>> long >>>>>>> history in SSOs. The good news is that from what I read in [1], there >>>>>>> is >>>>>>> now some interest in the IETF on this. >>>>>>> >>>>>>> However, some issues are application-domain-specific -- e.g. avatars, >>>>>>> assets; in the Web model, these are MIME type issues. They need >>>>>>> standardization too -- or at least generalized agreement on the data >>>>>>> that gets passed around. >>>>>>> >>>>>>> In that sense I'd argue for #2. There are MIME type standards that >>>>>>> this >>>>>>> group can define specifically for virtual worlds. That's one part of >>>>>>> interoperability that only ppl in the VW field can tackle. >>>>>>> >>>>>>> Crista / Diva >>>>>>> >>>>>>> [1] http://isoc.org/wp/ietfjournal/?p=1715 >>>>>>> >>>>>>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>>>>>> Good day, all. >>>>>>>> The chairs and area directors have been talking about the status and >>>>>>>> future of the VWRAP working group. Owing to changes in focus and >>>>>>>> commitment by both companies and individuals, things have been >>>>>>>> languishing, and it's not clear to us that we have what we need to >>>>>>>> get >>>>>>>> the chartered work done. The introduction document looked close to >>>>>>>> ready, until some controversy on its content and direction brewed, >>>>>>>> and >>>>>>>> the result of that discussion was inconclusive. The normative >>>>>>>> drafts >>>>>>>> that have seen some implementation (type system, launch message, >>>>>>>> etc.) >>>>>>>> also appear nearly technically complete, but some issues have been >>>>>>>> identified and not resolved by subsequent discussion, consensus, and >>>>>>>> editing. >>>>>>>> >>>>>>>> At this point, the mailing list has been too quiet for too long, all >>>>>>>> the draft documents have expired, and we need to make a decision >>>>>>>> about >>>>>>>> what to do. >>>>>>>> >>>>>>>> The chairs and ADs see three possibilities: >>>>>>>> >>>>>>>> 1. Find new document editors, pick up the chartered work with the >>>>>>>> existing document base, and get moving again. Get the introduction >>>>>>>> document finished by the end of February, and make progress on the >>>>>>>> others. >>>>>>>> >>>>>>>> 2. Come to consensus on significant changes to the direction of the >>>>>>>> VWRAP specs, find new document editors, revamp the introduction >>>>>>>> document, and get that finished, or substantially so, by the end of >>>>>>>> February. Have some clear consensus, clear direction, and >>>>>>>> enthusiasm >>>>>>>> to continue. Consider rechartering, if the direction has changed >>>>>>>> enough to require that. >>>>>>>> >>>>>>>> 3. Accept that we no longer have enough core participation, >>>>>>>> consensus, >>>>>>>> and enthusiasm to make progress, and close the working group. >>>>>>>> Future >>>>>>>> work in the virtual world area could charter a new working group >>>>>>>> later. >>>>>>>> >>>>>>>> Note that options 1 and 2 both require that we demonstrate >>>>>>>> sufficient >>>>>>>> energy and participation to really get work done and to demonstrate >>>>>>>> consensus. That means that we need people to commit to >>>>>>>> writing/editing documents, actively discussing the technical issues >>>>>>>> with the goal of reaching consensus on the content of the documents, >>>>>>>> and, importantly, reviewing documents and showing that we have >>>>>>>> consensus. Three or four participants isn't enough, and conflicting >>>>>>>> ideas that can't be resolved into a consensus-based position won't >>>>>>>> work. >>>>>>>> >>>>>>>> What say you, VWRAP participants? Can we pick up the work and make >>>>>>>> progress? Shall we close the working group, and perhaps consider >>>>>>>> something in future? Do you favour options 1, 2, or 3? Or do you >>>>>>>> see >>>>>>>> an alternative option you'd like to bring up? >>>>>>>> >>>>>>>> Barry and Joshua, VWRAP chairs >>>>>>>> _______________________________________________ >>>>>>>> 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 ohmeadhbh@gmail.com Sat Jan 15 16:03: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 68CEA3A6BA2 for ; Sat, 15 Jan 2011 16:03:38 -0800 (PST) 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 kWPrij1tro7j for ; Sat, 15 Jan 2011 16:03:36 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 3BB763A6BA0 for ; Sat, 15 Jan 2011 16:03:36 -0800 (PST) Received: by vws7 with SMTP id 7so1588060vws.31 for ; Sat, 15 Jan 2011 16:06:05 -0800 (PST) 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=lpawDYgyIAPF+T6Jc2L3SI6OyQCJ5EPcNFT+LKpmMbM=; b=JiH8PUaI/uPgjdyv3FSaCj0AJtfFfcG9rm/KsdCr/PVzeeoQnce1mt4riATaXdoJEC evpR5BNdS904fPXLmPgO0/GCH+Ek47dAu5KjksA/Fss6nGZ+1EVQ3qTjYK4lG/GkmL8f ZRiMTRslTg+NTVruy1s7FnNGggv79NBSfuq18= 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=hmYcU/WeNR/KHMXk8nB3adF7p3QD+VsCZvTeWpJFp42eHoeiWzT9oj2KPplXwi9RbX ZOsGhThBjfGx/07GVOpt9M9P+pKCH47LrDtNLytnjcGkg8Bt9FWA+FwYAkdpyEUc4MWP XTGYgjGv6qzwOr5Ml9M6C40r72xfHUDf/Xz4Q= Received: by 10.220.176.66 with SMTP id bd2mr751203vcb.139.1295136363869; Sat, 15 Jan 2011 16:06:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sat, 15 Jan 2011 16:05:43 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> From: Meadhbh Hamrick Date: Sat, 15 Jan 2011 16:05:43 -0800 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] 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, 16 Jan 2011 00:03:38 -0000 options 1 & 2 require someone to step up and volunteer to author new docs. any takers? if no one will step up, then i think option #3 is most appropriate. if i read barry's email correctly, euthanizing VWRAP now does not preclude rechartering in the future if there's renewed interest. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Jan 15, 2011 at 3:17 PM, Vaughn Deluca wr= ote: > Meadhbh, > Meadhbh, > > As i stated a few mails back, i am certainly willing to help, but I am > not =A0a proffesional in this field, and my expertise is insufficient to > play an editors role. -and to be honnest, i do not have the needed > time for such a role either. But for sure i will be making > contributions to intro document where possible. > > Option 3 is conflating core participation and consensus/enthusiasm. I > am fairly optimistic about the possibility to (eventually) reach > consensus, but we might indeed be critically low on core > participation. Barry wrote "Three or four participants isn't enough" > and he is right. This tread has only a handfull of responses, > dangerously close to that level. > > Close, but not there yet, we will see what happens on the wiki. If > *that* fails its time for option 3. > > --Vaughn > > On 1/15/11, Meadhbh Hamrick wrote: >> whoops. yes. =A0meant to say "you're voting for option #2" >> >> but my original point was that there's a fair amount of work to be >> done, and i was asking if you were going to re-write the intro. if we >> can't find anyone willing to do the work, we might have to go with >> option #3. >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Sat, Jan 15, 2011 at 12:12 PM, Vaughn Deluca >> wrote: >>> No, i am voting for option 2. Barry wrote: >>> >>> "2. Come to consensus on significant changes to the direction of the >>> VWRAP specs[...] =A0Consider rechartering, if the direction has changed >>> enough to require that." >>> >>> All i am saying is that i don't see the need for rechartering *yet*. >>> >>> --Vaughn >>> >>> On 1/15/11, Meadhbh Hamrick wrote: >>>> you're voting for option 1 then, but are you volunteering to do the wo= rk? >>>> >>>> the current intro XML is in SVN at >>>> http://svn.tools.ietf.org/svn/wg/vwrap/ >>>> >>>> you can check them out with the command: >>>> >>>> svn co http://svn.tools.ietf.org/svn/wg/vwrap/ vwrap_documents >>>> >>>> if there's interest, i'm happy to put on a 30 minute "how to edit, >>>> write and publish an internet draft" presentation in world somewhere. >>>> >>>> -cheers >>>> -meadhbh >>>> >>>> -- >>>> meadhbh hamrick * it's pronounced "maeve" >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>> >>>> >>>> >>>> On Sat, Jan 15, 2011 at 10:11 AM, Vaughn Deluca >>>> wrote: >>>>> I am not convinced rechartering is actually needed. The introduction >>>>> document certainly needs an overhaul, and we to need to reaffirm we >>>>> are all on the same track, but I think that the existing charter migh= t >>>>> still work for us. I suggest we work with it, at least until it >>>>> becomes the obvious obstacle for progress. >>>>> >>>>> -- Vaughn >>>>> >>>>> >>>>> >>>>> On 1/15/11, Meadhbh Hamrick wrote: >>>>>> Hey Barry, >>>>>> >>>>>> so it seems like there's at least some interest for rechartering. >>>>>> what's the mechanics for that? do we call for a new BoF or just hash >>>>>> out a new charter on the mailing list? >>>>>> >>>>>> -cheers >>>>>> -meadhbh >>>>>> >>>>>> -- >>>>>> meadhbh hamrick * it's pronounced "maeve" >>>>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Jan 15, 2011 at 2:49 AM, Vaughn Deluca >>>>>> >>>>>> wrote: >>>>>>> Although i have only been operating in the fringe of this group, i >>>>>>> would like to argue for #2 >>>>>>> >>>>>>> It clear that some refocussing and consensus building is needed, bu= t >>>>>>> we should at least =A0give that a try. To me it seems definitely to >>>>>>> early to give up. If we try #2 =A0it will become clear if =A0#3 can >>>>>>> indedeed be avoided. >>>>>>> >>>>>>> I see christina's point of starting at the basis, and fixing SSO >>>>>>> first. However, I feel that from the perspective of VWRAP SSO is >>>>>>> actually a well described sub-problem that can be left to others to >>>>>>> solve, while we focus on the specific =A0of avatars and assets. >>>>>>> >>>>>>> In =A0terms of actual commitment, i think the wiki idea is great, a= nd i >>>>>>> will try to free some time to contribute there in the near future. >>>>>>> >>>>>>> --Vaughn >>>>>>> >>>>>>> On 1/15/11, Cristina Videira Lopes wrote: >>>>>>>> I'm leaning towards #2 and #3 simultaneously :) >>>>>>>> Let me explain. >>>>>>>> >>>>>>>> The goal of achieving virtual world interoperability always felt l= ike >>>>>>>> a >>>>>>>> niche goal to me, but one that, given the nature of these >>>>>>>> applications, >>>>>>>> touched on a couple of more foundational issues: single sign ons a= nd >>>>>>>> Web >>>>>>>> services security -- in short, federations that cross enterprise >>>>>>>> boundaries. >>>>>>>> >>>>>>>> There is a variety of implementations for SSOs out there, more >>>>>>>> recently >>>>>>>> the one in the Hypergrid, and a variety of ways of securing Web >>>>>>>> services. But no standards that I know of -- apart from the SOAP >>>>>>>> stuff. >>>>>>>> Perhaps this group should band with others who may be interested i= n >>>>>>>> standardizing these things -- SSO seems like it's ripe for that. I= n >>>>>>>> other words, let's join with others on common foundational issues, >>>>>>>> rather than separating from them along the lines of application >>>>>>>> domains >>>>>>>> (VWs vs everything else). >>>>>>>> >>>>>>>> In that sense I'd argue for #3, because doing an IETF SSO working >>>>>>>> group >>>>>>>> properly would require substantial change and outreach. There's a >>>>>>>> long >>>>>>>> history in SSOs. The good news is that from what I read in [1], th= ere >>>>>>>> is >>>>>>>> now some interest in the IETF on this. >>>>>>>> >>>>>>>> However, some issues are application-domain-specific -- e.g. avata= rs, >>>>>>>> assets; =A0in the Web model, these are MIME type issues. They need >>>>>>>> standardization too -- or at least generalized agreement on the da= ta >>>>>>>> that gets passed around. >>>>>>>> >>>>>>>> In that sense I'd argue for #2. There are MIME type standards that >>>>>>>> this >>>>>>>> group can define specifically for virtual worlds. That's one part = of >>>>>>>> interoperability that only ppl in the VW field can tackle. >>>>>>>> >>>>>>>> Crista / Diva >>>>>>>> >>>>>>>> [1] http://isoc.org/wp/ietfjournal/?p=3D1715 >>>>>>>> >>>>>>>> On 1/14/2011 9:13 AM, Barry Leiba wrote: >>>>>>>>> Good day, all. >>>>>>>>> The chairs and area directors have been talking about the status = and >>>>>>>>> future of the VWRAP working group. =A0Owing to changes in focus a= nd >>>>>>>>> commitment by both companies and individuals, things have been >>>>>>>>> languishing, and it's not clear to us that we have what we need t= o >>>>>>>>> get >>>>>>>>> the chartered work done. =A0The introduction document looked clos= e to >>>>>>>>> ready, until some controversy on its content and direction brewed= , >>>>>>>>> and >>>>>>>>> the result of that discussion was inconclusive. =A0The normative >>>>>>>>> drafts >>>>>>>>> that have seen some implementation (type system, launch message, >>>>>>>>> etc.) >>>>>>>>> also appear nearly technically complete, but some issues have bee= n >>>>>>>>> identified and not resolved by subsequent discussion, consensus, = and >>>>>>>>> editing. >>>>>>>>> >>>>>>>>> At this point, the mailing list has been too quiet for too long, = all >>>>>>>>> the draft documents have expired, and we need to make a decision >>>>>>>>> about >>>>>>>>> what to do. >>>>>>>>> >>>>>>>>> The chairs and ADs see three possibilities: >>>>>>>>> >>>>>>>>> 1. Find new document editors, pick up the chartered work with the >>>>>>>>> existing document base, and get moving again. =A0Get the introduc= tion >>>>>>>>> document finished by the end of February, and make progress on th= e >>>>>>>>> others. >>>>>>>>> >>>>>>>>> 2. Come to consensus on significant changes to the direction of t= he >>>>>>>>> VWRAP specs, find new document editors, revamp the introduction >>>>>>>>> document, and get that finished, or substantially so, by the end = of >>>>>>>>> February. =A0Have some clear consensus, clear direction, and >>>>>>>>> enthusiasm >>>>>>>>> to continue. =A0Consider rechartering, if the direction has chang= ed >>>>>>>>> enough to require that. >>>>>>>>> >>>>>>>>> 3. Accept that we no longer have enough core participation, >>>>>>>>> consensus, >>>>>>>>> and enthusiasm to make progress, and close the working group. >>>>>>>>> =A0Future >>>>>>>>> work in the virtual world area could charter a new working group >>>>>>>>> later. >>>>>>>>> >>>>>>>>> Note that options 1 and 2 both require that we demonstrate >>>>>>>>> sufficient >>>>>>>>> energy and participation to really get work done and to demonstra= te >>>>>>>>> consensus. =A0That means that we need people to commit to >>>>>>>>> writing/editing documents, actively discussing the technical issu= es >>>>>>>>> with the goal of reaching consensus on the content of the documen= ts, >>>>>>>>> and, importantly, reviewing documents and showing that we have >>>>>>>>> consensus. =A0Three or four participants isn't enough, and confli= cting >>>>>>>>> ideas that can't be resolved into a consensus-based position won'= t >>>>>>>>> work. >>>>>>>>> >>>>>>>>> What say you, VWRAP participants? =A0Can we pick up the work and = make >>>>>>>>> progress? =A0Shall we close the working group, and perhaps consid= er >>>>>>>>> something in future? =A0Do you favour options 1, 2, or 3? =A0Or d= o you >>>>>>>>> see >>>>>>>>> an alternative option you'd like to bring up? >>>>>>>>> >>>>>>>>> Barry and Joshua, VWRAP chairs >>>>>>>>> _______________________________________________ >>>>>>>>> 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 zenmondo@gmail.com Sat Jan 15 20:52: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 35CE33A6C44 for ; Sat, 15 Jan 2011 20:52:28 -0800 (PST) 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 fiey15UxOp5D for ; Sat, 15 Jan 2011 20:52:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 337423A6818 for ; Sat, 15 Jan 2011 20:52:26 -0800 (PST) Received: by wwa36 with SMTP id 36so4059389wwa.13 for ; Sat, 15 Jan 2011 20:54:56 -0800 (PST) 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; bh=vW4T1oDNu+8OlJtYPRT1GpbSZQb2CFnYfuMzXqwlNPo=; b=Mw+aMVxuEz7FM2TehU53A2gLAADOYHTSu4fakdFWezaREru6nhuomRtJzSbUO8FCJT AKO6AS4dI6X3eH/4aap9Z+Am002tLFMmTBTrj1ynNk1eJUhl/cW4NtDSnYr3zx9SiSni +im0yjqV62cJHzzYHj6PSvyZ383ssRxtwW7NE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Ze1yyoqKwaH/qKLNGCwrSZ2dmgUm087b3WOfN9kucQwu3gQ+09S9JSH3gc1h5HqKmw B7S3wq/dDavQVQLn+g9w5IGO2DPk5yRJ9nWt9TObYgjGwzrOWMZl6SKkPEQHuUupbT6j SFI7yH6cYwVsBlDh4h8gFOY/fsRORBjkWtUs8= MIME-Version: 1.0 Received: by 10.216.181.76 with SMTP id k54mr1093216wem.58.1295153695566; Sat, 15 Jan 2011 20:54:55 -0800 (PST) Received: by 10.216.72.69 with HTTP; Sat, 15 Jan 2011 20:54:55 -0800 (PST) Date: Sat, 15 Jan 2011 21:54:55 -0700 Message-ID: From: "L. Christopher Bird" To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016363ba5abf42c0f0499ef7751 Subject: [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: Sun, 16 Jan 2011 04:52:28 -0000 --0016363ba5abf42c0f0499ef7751 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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= .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 grid= s 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) --0016363ba5abf42c0f0499ef7751 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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://flynnos.org/Networke= d%20Communication%20of%20Second%20Life%20Objects.pdf Its short so I wil= l 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)
--0016363ba5abf42c0f0499ef7751-- From ohmeadhbh@gmail.com Sun Jan 16 08: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 329EA3A6BCD for ; Sun, 16 Jan 2011 08:09:33 -0800 (PST) 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 Zy0wbMQbs760 for ; Sun, 16 Jan 2011 08:09:32 -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 D26853A6A86 for ; Sun, 16 Jan 2011 08:09:31 -0800 (PST) Received: by qwi2 with SMTP id 2so4243467qwi.31 for ; Sun, 16 Jan 2011 08:12:03 -0800 (PST) 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=qkvAuW0+SFwN2xgB2TQOYCEzwBNG7Z2RHzivt8qvHgU=; b=wIsnczeIV1VaOOGq0aILIKt0Hhv6XWCouNcxyLMIVvHU2SRJy15wNC313TIJqF7XWc GwdwvTjwA7AIWbJv0ShJxuSHw+sPSt3NcAlfRM2xsiEGIFCXm9t/DF4bbTM4r5rcWIOH Vke+pljBYWagDYpWlGReezl82kkuK6hetOO2I= 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=ituXNgv+v7EYryaDBDzsIJTc5U/mKLqnp30c6hYv5D3zE+uGD+Ov9/pRi3kKbxYGT1 Yuw56nU2ZnXjqvBclKK0k8tKmJyEULDyBsYnhQva+uhqS8gwWz4W/xWnbaDHu5LfCriE /n6S2iX02ZI61CwK6paJSjjefsY0EjJKEe6kc= Received: by 10.229.95.81 with SMTP id c17mr2699568qcn.99.1295194322866; Sun, 16 Jan 2011 08:12:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sun, 16 Jan 2011 08:11:42 -0800 (PST) In-Reply-To: References: From: Meadhbh Hamrick Date: Sun, 16 Jan 2011 08:11:42 -0800 Message-ID: To: "L. Christopher Bird" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org 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: Sun, 16 Jan 2011 16:09:33 -0000 well... if you're interested in documenting it and other people are interested in implementing it, more power to you. i would offer the following criticizms though: a. the IETF tends to be focused on the format of things that go across a wire (i.e. - "wire protocols".) and while the technique you document has the benefit that it works in an existing environment with little trouble, it doesn't really talk too much about the format of messages on the wire. b. it requires MySQL & LSL. again, that's great for the existing environments like SL & OpenSim that speak more or less the same dialect of LSL, but one of the objectives of specifying wire protocols is you get to implement things in whatever language you want. so for example, the OpenSim diehards can implement things in C# while i implement things in JavaScript/NodeJS with occasional lapses into PHP. c. LSL is a pox upon humanity that should be driven from the face of the earths (both physically manifest and virtual.) which is my way of saying, "enh. LSL has some issues as an implementation language, and if we're doing something new, let's try to learn from LSL's mistakes and apply the "cool bits" of LSL to a less horked environment." being a JavaScript partisian, i would simply say "take the concept of states from LSL and add it to a javascript implementation, then create a DOM like structure representing the things a script can interact with." i think what i'm trying to say is, "this is cool, but VWRAP is the wrong forum." or maybe even, "i see a kernel of something in there that would be useful for transition from old school SecondLife to whatever comes next, but i have to play with it a little more before i can figure out how it applies to my mental map of what VWRAP was going to be." seriously though, i liked the paper, it should get more distribution. did you send it to opensource-dev (or whatever they're calling sldev these days?) -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sat, Jan 15, 2011 at 8:54 PM, L. Christopher Bird w= rote: > 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.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 gr= ids > 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 (w= hich > 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=A0 in any virtual world to implement something like this is an HTT= P > channel to your virtual object. > > Thoughts? Criticisms? Comments? > > -- Christopher (ZenMondo) > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From zenmondo@gmail.com Sun Jan 16 08:17: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 C731A3A6BC4 for ; Sun, 16 Jan 2011 08:17:15 -0800 (PST) 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 XfK00WQy1pHF for ; Sun, 16 Jan 2011 08:17:15 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C1F093A6A86 for ; Sun, 16 Jan 2011 08:17:14 -0800 (PST) Received: by wyf23 with SMTP id 23so4593391wyf.31 for ; Sun, 16 Jan 2011 08:19:45 -0800 (PST) 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=Lf+XfVZCzVrkFuXPtUjPMMrp7V4RV5qYid+IVa6Mk3w=; b=vRHPPmvZrAK6r7mebFp4DAo7B0NoeqcsB0PUbuzMw4gsTCvJctksp67u9LcIg33IXb O+ukdjjlsI5sPyszEBPjIdOkRjQXXgG3ckyjIY/KZEh+Oy/eb+HZuz6CWGDSvHaDpXhr rw5BnlSDM7e7cF+vAhU9BXM35fRzb1oclfeTg= 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=tlEEktBCkDvqzH7vVZh9NPZBl7MHMo7Lz/e8ynwPNoPj8t6xtGCixba6647cJ2zxwA l+P7wpBvfaZNroLHgK/0ceKXJhFIDcX5C9pf13EyRdi3ity3a0pEApEomGSBOHu57ufZ 9ksLu9oCi4eHxSf22r4ynIjaNXhmjhJwF1tvc= MIME-Version: 1.0 Received: by 10.216.150.164 with SMTP id z36mr1469529wej.43.1295194785877; Sun, 16 Jan 2011 08:19:45 -0800 (PST) Received: by 10.216.72.69 with HTTP; Sun, 16 Jan 2011 08:19:45 -0800 (PST) In-Reply-To: References: Date: Sun, 16 Jan 2011 09:19:45 -0700 Message-ID: From: "L. Christopher Bird" To: Meadhbh Hamrick Content-Type: multipart/alternative; boundary=0016e6de0380208f300499f90962 Cc: vwrap@ietf.org 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: Sun, 16 Jan 2011 16:17:15 -0000 --0016e6de0380208f300499f90962 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Jan 16, 2011 at 9:11 AM, Meadhbh Hamrick wrote: > > > seriously though, i liked the paper, it should get more distribution. > did you send it to opensource-dev (or whatever they're calling sldev > these days?) > > -cheers > -meadhbh > Thanks. One of the things is I do not know WHERE to share this. opensource-dev pretty much is snowglobe development these days and anything else is quickly shouted down as off topic the recent spat of activity on this list made me think "oh maybe they will like it" Thank you for the feedback and consideration. -- Zen --0016e6de0380208f300499f90962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Jan 16, 2011 at 9:11 AM, Meadhbh= Hamrick <ohmea= dhbh@gmail.com> wrote:


seriously though, i liked the paper, it should get more distribution.
did you send it to opensource-dev (or whatever they're calling sldev these days?)

-cheers
-meadhbh

Thanks. One of the things is I do not kn= ow WHERE to share this. opensource-dev pretty much is snowglobe development= these days and anything else is quickly shouted down as off topic the rece= nt spat of activity on this list made me think "oh maybe they will lik= e it"

Thank you for the feedback and consideration.


-- Zen
--0016e6de0380208f300499f90962-- From ohmeadhbh@gmail.com Sun Jan 16 10:02: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 0D0A63A6DC8 for ; Sun, 16 Jan 2011 10:02:02 -0800 (PST) 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_14=0.6, J_CHICKENPOX_41=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 Selw8OBnjm8Z for ; Sun, 16 Jan 2011 10:02: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 62ECC3A6C6D for ; Sun, 16 Jan 2011 10:02:00 -0800 (PST) Received: by qwi2 with SMTP id 2so4299319qwi.31 for ; Sun, 16 Jan 2011 10:04:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=VurRTAXtGYfpHcj1QAg9AEuz8YLXf3PiYpLkMY5QciY=; b=LpcxZ0Wa8JefU/Zv1NiqLJKAiId0jD52afpPqDKCzYRvDW0dfUPJZ4qCm75jvR6smw 1Mv09P1+zDdUbSldcEVjsEPSE4MC8yCs1EYG+QbUTeOIJV635kYlY4KkcvIFnFKYS/YJ 3zzGeT7gcSpRnOKzqe7snw3AIrfSWcTM+lNeI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=a9vqzcZYz4SvJZIvEWhJco/lOP5oXz9ue/7JmD2/VvkZxTb579h8MR/IvoFv0za+dq KZYQ1UzekM72BbPdbX6k0dOnQmbNc8O8YUfrFJgefAEMEBxyer2qGxaYlfxM7EBh17FW Ljgs4i92DlkOgpku0pVZcwPUGvuTOl8SCMH34= Received: by 10.229.91.72 with SMTP id l8mr2179659qcm.137.1295201071713; Sun, 16 Jan 2011 10:04:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sun, 16 Jan 2011 10:04:11 -0800 (PST) From: Meadhbh Hamrick Date: Sun, 16 Jan 2011 10:04:11 -0800 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [vwrap] text serialization of DSD objects (the application/dsd+text content type) 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, 16 Jan 2011 18:02:02 -0000 hey peeps, reading ZenMondo's LSL+HTTP+MySQL object transfer paper reminded me that when i was deploying sl8.us, i needed a serialization format that was MUCH easier to parse in LSL. i'm not going to argue the merits of LSL vs. some hypothetical future where we've moved to something better. i think we all know LSL has it's limitations, but it has the benefit of having been deployed in both SL and in a slightly different format in OpenSim. so the purpose of this serialization scheme is to allow objects in existing SL or OpenSim instances to more easily participate in VWRAP services. yeah, this is all pretty much moot since it looks like VWRAP will either be taken round back and put out of its misery or will turn into a group to document and bless HyperGrid. but fwiw,i'm building loosely coupled services based on the stuff documented in previous IDs from this group, and if you hooked up wireshark or pcap to the sl8.us servers, grabbed the session keys for the process out of /dev/mem, this is what you would see. i'm assuming you've read the LLDS drafts(s) and understand it's purpose. more specifically, you should understand the role serialization schemes play in LLSD. this is obviously preliminary information. it will eventually be included as part of a forthcoming internet draft. intro: the "text serialization scheme" for DSD is intended to be used in environments that are computationally constrained. specifically environments where parsing and producing JSON, XML and Binary data is impractical. the author has successfully used this scheme with 8 and 16 bit microcontrollers and with LSL scripts inside Second Life. mime type & file extension : in systems where an object serialization is carried across a transport that understands MIME types (like S/MIME or HTTP(S)), two serializations may be used. application/dsd+text is preferred, but text/plain is also acceptable. the "canonical" file extension for text serialized objects is ".dsdt" (so update your desktop software now!) service endpoints that receive messages without a mime type, or with the mime type 'text/plain' SHOULD interpret the contents as being serialized with this scheme. in other words, we're optimizing for the condition where "constrained" devices can't use typed transports. the serialization: text serialization encodes information into "human readable" UTF-8 contents. it borrows XML's conception of valid code-points. that is, only a couple control characters are valid in text encoding. the XML entry from the wikipedia says it best. from http://en.wikipedia.org/wiki/XML : Unicode code points in the following ranges are valid in XML 1.0 document= s: * U+0009, U+000A, U+000D: these are the only C0 controls accepted in XML = 1.0; * U+0020=96U+D7FF, U+E000=96U+FFFD: this excludes some (not all) non-characters in the BMP (all surrogates, U+FFFE and U+FFFF are forbidden); * U+10000=96U+10FFFF: this includes all code points in supplementary planes, including non-characters. the text serialization scheme encodes information into discrete "text lines." a "text line" is an arbitrary length sequence of UTF-8 codepoints that ends with a CR, LF or CR LF. where CR is a "carriage return" or %x000D, LF is a "line feed" or %x000A, and a CR LF is a carriage return followed by a line feed. in general, each scalar value is encoded into in a single text line. the beginning and end of vector values (maps, arrays) are encoded into single text lines. text lines have the format of: : : where is a text key value used in maps. is a single character identifying the type of the that follows. is a CR, LF, or CR LF. there are also tags for "beginning of document" and "version." and here's the list of tags: * - start of document document - all text serialized documents MUST begin with a "start of document" line that looks like: ":*:" + . this is useful for systems that use "magic numbers" to identify content types. v - version - the version tag is an optional tag used to identify documents encoded by future versions of this specification. the is a simple string representing the version of the spec. this spec uses the version tag "1" - thus a version line from a document encoded using rules described here would look like ":v:1" + u - undefined - represents the "undefined" scalar. example: ":u:" + b - boolean - represents the "boolean" scalar. encodes one of two values: true or false. true is represented with the value "T" while false is represented with any value other than "T" or the lack of a value. for clarity, implementaions SHOULD use the character "F". examples: ":b:T" + , ":b:F" + , ":b:" + " or ":b:i actually represent a valid false value" + i - integer - represents the "integer" scalar. example: ":i:9" + r - real - represents the "real" scalar. example: ":r:3.14159" + s - string - represents a string. the colon character (':'), the back-slash character ('\') and characters that are not allowed in the XML encoding are escaped with the sequence backslash, u and four hex digits. ergo, you can represent the escape character with "\u001B". a colon would be represented with "\u003A". example: ":s:i am an example string" + d - date - represents a date string. example: ":d:2011-01-16T09:42:00Z" + <= EOL> w - UUID - represents a uuid scalar. example: ":w:f1828128-0ab2-4a24-b6c9-b567ea875d4d" + x - URI - represents a URI. example: ":x:http\u003A//example.org/whatever.php" + n - binary - represents a binary encoded string. no newlines allowed. example: ":n:aGVsbG8uCg=3D=3D" [ - array (open) - this represents the beginning of an array. example: ":[:" + ] - array (close) - this represents the end of an array. { - map (open) - represents the beginning of a map. } - map (close) - represents the end of a map. here's an example text encoding: :*: :v:1 :{: description:s:this is a point in 3 space point:[: :r:0.0 :r:14.9 :r:17.0 :]: control:x:http\u003A//example.org/c/a0b53baa-db54-4257-b9bc-ea15069f3adc :}: anyway, if you're familiar with other serialization schemes, this should be pretty straight forward to implement. if anyone's interested, i'll dig up and sanitize the LSL implementation i'm using for the in-world sl8.us tools. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From ohmeadhbh@gmail.com Sun Jan 16 10:04: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 74B113A6C6D for ; Sun, 16 Jan 2011 10:04:08 -0800 (PST) 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 N5syf7iFLWLp for ; Sun, 16 Jan 2011 10:04:07 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 9EF6F3A6DC9 for ; Sun, 16 Jan 2011 10:04:07 -0800 (PST) Received: by vws7 with SMTP id 7so1816127vws.31 for ; Sun, 16 Jan 2011 10:06:39 -0800 (PST) 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=szDBL51KOYwOJeNkid/Zyp9zNH1OonNsZBWmVpGM8Io=; b=JeG7skRj0EfPMDJIXJBBOs7Kgny4hummYj5ZSR+EGoccAol/H0YE7ywsM94dPWxOvH GfzoLwPznbxiS51D1DGFSc5nYpDekz1ypIdiro7IePyQ6AFuZ0xN9FQ0a0Et32i7weAY HkHuKhUMqZJoN4/PNDZN2cWf8316l35R/0be8= 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=HxaOytx3jWNH4/oBgkko7CfjVDCDmA+MSIDDzEwzGzqX8NeJuU/JszRHYIikDJ0ndT 28UuJQD2GKpCmpGq+LAeele9FZc0nFep+AoQgYHrVkHmQbdHdN4Q/1xrjaQ7B1Hrc5fe qH0ZHXyya/TYkxVg4aPJAazQ2MFGIU7Ko+H1I= Received: by 10.220.176.66 with SMTP id bd2mr1019207vcb.139.1295201197573; Sun, 16 Jan 2011 10:06:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sun, 16 Jan 2011 10:06:17 -0800 (PST) In-Reply-To: References: From: Meadhbh Hamrick Date: Sun, 16 Jan 2011 10:06:17 -0800 Message-ID: To: "L. Christopher Bird" Content-Type: text/plain; charset=ISO-8859-1 Cc: vwrap@ietf.org 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: Sun, 16 Jan 2011 18:04:08 -0000 hmm.. isn't there a LSL users group somewhere with a mailing list? if not, maybe we could start one. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Sun, Jan 16, 2011 at 8:19 AM, L. Christopher Bird wrote: > > > On Sun, Jan 16, 2011 at 9:11 AM, Meadhbh Hamrick > wrote: >> >> >> seriously though, i liked the paper, it should get more distribution. >> did you send it to opensource-dev (or whatever they're calling sldev >> these days?) >> >> -cheers >> -meadhbh > > Thanks. One of the things is I do not know WHERE to share this. > opensource-dev pretty much is snowglobe development these days and anything > else is quickly shouted down as off topic the recent spat of activity on > this list made me think "oh maybe they will like it" > > Thank you for the feedback and consideration. > > > -- Zen > From ohmeadhbh@gmail.com Sun Jan 16 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 46CA328C0CF for ; Sun, 16 Jan 2011 13:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.11 X-Spam-Level: X-Spam-Status: No, score=-3.11 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 Y1ai27niekYN for ; Sun, 16 Jan 2011 13:31:58 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0C2CF28C0DE for ; Sun, 16 Jan 2011 13:31:57 -0800 (PST) Received: by vws7 with SMTP id 7so1857129vws.31 for ; Sun, 16 Jan 2011 13:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=beu7o887s5NQtL4s39ohuVzN0gYpK1D91IuDYDnSvNg=; b=srFC2Hz6lPuFxqKvW+kZcw3DxHRBz6Wrk0vjzVgcAivSOnXgdJDdwZhy3AHRRGmWRv 5sHeR9iwVytxd5zoDwv0Qp823Fi4/YKKY+AIkuwqrz26+vsH+4BUynbFozJnYOnD9kcQ 0frL94HVHH0ESWOoG/5+s8GPtAlUPCPpnkpeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=D/6cSBjoYnj1US/cMfJSPJbLRM7OltUnqHRn/N4sKv+S8gcwMFaWHAluvWnvJwehpo D/QpoZoXQU40obwyDj0OMj3J4PO6XpyZTGe4+264oxtaQ4u5JyCFSosMI2BwQrC8TfAm rn7Mjb5VU0weABCIKY52EZFk0iBASyn+qXU9c= Received: by 10.220.176.66 with SMTP id bd2mr1067689vcb.139.1295213668865; Sun, 16 Jan 2011 13:34:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.202.141 with HTTP; Sun, 16 Jan 2011 13:34:08 -0800 (PST) From: Meadhbh Hamrick Date: Sun, 16 Jan 2011 13:34:08 -0800 Message-ID: To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=90e6ba53a24ca416a10499fd6e8e Subject: [vwrap] informal description of the DSD interface description language 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, 16 Jan 2011 21:32:00 -0000 --90e6ba53a24ca416a10499fd6e8e Content-Type: text/plain; charset=ISO-8859-1 hey peeps, it shouldn't be shocking to anyone i'm not a big fan of lentczner's "little" interface description language, llidl. while it can be argued it's "condensed" format is easy enough to use, once mastered, i prefer something mildly more expressive. when i was working on the last version of the LLSD draft, i solicited comments from several implementers inside and outside Linden, and they all said the same thing: "LLIDL is cool enough, but it looks like line noise if you don't know what you're looking at." i came up with the following interface description language to address the "looks like line noise" critique. this is the IDL that's going in the DSD draft, since that's what we're using at sl8.us and various sensor projects that are using DSD. i'm assuming you've read and understand the LLIDL section of the most recent type system draft. again, i have no idea if this will be relevant since no one's stepped up to be an document author for future revisions of this group's docs or an editor to re-draft a new charter. but on the off chance people do this and still want to work on the type system, these are the changes recommended by several LLIDL users and implementers. *item 0 : disentangling resources from interfaces.* LLIDL sort of conflated a resource (something to be accessed) with the method of accessing it. there was no way to "officially" define a "resource" independent of the semantics to access it. DSD says that RESOURCEs are just data definitions. INTERFACEs define how they're used. *item 1 : say good-bye to the di-graphs.* several people noted that LLIDL, at first glance, looks like line noise. this is because of the use of digraphs to represent messaging semantics. cast your memory back to the LLIDL resource description for the seed cap: %% seed -> { capabilities: [ string, ... ] } <- { capabilities: { $: uri } } the '%%' digraph means 'start of resource description'. the '->' means 'this is what i'm going to send you' and the '<-' digraph means 'i expect you to send me this back'. instead of digraphs, the DSD resource description language uses the keyword "RESOURCE" to begin a resource. it also terminates the resource definition with a semi colon. so a resource declaration would look something like this: RESOURCE [resource definition] ; resource DEFINITIONs look more or less like they used to. for example, here's a RESOURCE definition for a typical error response: # Resource description for a typical error resource RESOURCE error_simple { success : false, # clients check the success element to see if there was an error errno : integer, # this is a numeric code representing the error error : string, # this is a text description of the error description : uri # this is a URL that points to a HTML web page describing the error }; *item 2 : the use of type literals instead of type names* in the example above, we used 'false' instead of 'boolean' as the type definition for the 'success' element of the error resource. DSD resource definitions can use type literals to imply that the element should exist, and should have a specific value. so if you wanted to define a resource that represented the origin of a 3d space, you could use: # Point in a 3D rectangular space RESOURCE cartesian_point [ real, # x coordinate real, # y coordinate real # z coordinate ]; # Origin of a rectangular (cartesian) space RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ]; *item 3 : type specifiers use the same names as the elements inside the XML serialization.* instead of using "int", we use "integer." ditto for other types. so the resource definition. here's a resource definition for something with an integer in it: # Random resource definition of a map with an integer in it RESOURCE whatever { element : integer }; *item 4 : DSD variant declarations don't suck for beginners* i always thought repeated '&' definitions to denote variants was sort of snobbish. it makes sense to peeps who've sat through classes on regular grammars and ABNF, but i wouldn't mind it too much if someone with a basic understanding of procedural coding could understand what was going on. so i came up with the VARIANT keyword. it looks like this: VARIANT : { } so here's an example: # Enhanced Error resource RESOURCE error_enhanced VARIANT error_type : string { 'number' : { success : false, errno : integer }, 'string' : { success : false, error : string }, 'url' : { success : false, description : uri } }; what this means is that the "error_enhanced" resource has three valid forms, that look like: RESOURCE error_enhanced { error_type : 'number', success : false, errno : integer }; RESOURCE error_enhanced { error_type : 'string', success : false, error : string } RESOURCE error_enhanced { error_type : 'url', success : false, description : uri } so the shows up as an element in each of the valid forms as an literal element of type . *item 5 : say good by to HTTP verbs.* LLIDL as specified is pretty much intertwined with HTTP. many people thought that was a bad idea. In creating an interface, DSD uses five abstract "interaction semantics": CREATE, READ, UPDATE, DELETE and EVENT. the first four do what you expect them to do while the last one describes the form or "shape" of an unsolicited message coming from the event queue. so if you wanted to login, you might use the following interface INTERFACE CREATE session_factory { username : string, secret : binary } RESPONSE VARIANT success : boolean { false : { errno : integer, err : string, description : uri }, true : { seed : uri } }; or, you could do the following: RESOURCE error { errno : integer, err : string, description : uri }; INTERFACE CREATE session_factory { username : string, secret : binary } RESPONSE VARIANT success : boolean { false : error, true : { seed : uri } }; so anyway, i'm writing up this stuff in the DSD type system draft. feel free to comment. as things stand, if VWRAP continues as a working group, i'll integrate your comments on the draft. if not, i'll modify the draft so as to remain compatibility with existing DSD implementations and publish it a an individual / informational draft for the purpose of registering the mime types. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com --90e6ba53a24ca416a10499fd6e8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hey peeps, it shouldn't be shocking to anyone i'm not a big fan of = lentczner's "little" interface description language, llidl. w= hile it can be argued it's "condensed" format is easy enough = to use, once mastered, i prefer something mildly more expressive. when i wa= s working on the last version of the LLSD draft, i solicited comments from = several implementers inside and outside Linden, and they all said the same = thing: "LLIDL is cool enough, but it looks like line noise if you don&= #39;t know what you're looking at."

i came up with the following interface description language to address = the "looks like line noise" critique. this is the IDL that's = going in the DSD draft, since that's what we're using at sl8.us and various sensor projects that are using DSD. = i'm assuming you've read and understand the LLIDL section of the mo= st recent type system draft.

again, i have no idea if this will be relevant since no one's stepp= ed up to be an document author for future revisions of this group's doc= s or an editor to re-draft a new charter. but on the off chance people do t= his and still want to work on the type system, these are the changes recomm= ended by several LLIDL users and implementers.

item 0 : disentangling resources from interfaces.

LLIDL s= ort of conflated a resource (something to be accessed) with the method of a= ccessing it. there was no way to "officially" define a "reso= urce" independent of the semantics to access it. DSD says that RESOURC= Es are just data definitions. INTERFACEs define how they're used.

item 1 : say good-bye to the di-graphs.

several people no= ted that LLIDL, at first glance, looks like line noise. this is because of = the use of digraphs to represent messaging semantics. cast your memory back= to the LLIDL resource description for the seed cap:

%% seed
=A0 -> { capabilities: [ s= tring, ... ] }
=A0 <- { capabilities: { $: uri } }

the '%%&= #39; digraph means 'start of resource description'. the '->&= #39; means 'this is what i'm going to send you' and the '&l= t;-' digraph means 'i expect you to send me this back'.

instead of digraphs, the DSD resource description language uses the key= word "RESOURCE" to begin a resource. it also terminates the resou= rce definition with a semi colon. so a resource declaration would look some= thing like this:

RESOURCE <resource name> [resource definition] ;

resource = DEFINITIONs look more or less like they used to. for example, here's a = RESOURCE definition for a typical error response:

= # Resource description for a typical error resource
RESOURCE error_simpl= e {
=A0 =A0success =A0 =A0 : false, =A0 =A0# clients check the success = element to see if there was an error
=A0 =A0errno =A0 =A0 =A0 : integer, =A0# this is a numeric code representi= ng the error
=A0 =A0error =A0 =A0 =A0 : string, =A0 # this is a text de= scription of the error
=A0=A0 description : uri =A0 =A0 =A0 # this is a = URL that points to a HTML web page describing the error
};

item 2 : the use of type liter= als instead of type names

in the example above= , we used 'false' instead of 'boolean' as the type definiti= on for the 'success' element of the error resource. DSD resource de= finitions can use type literals to imply that the element should exist, and= should have a specific value. so if you wanted to define a resource that r= epresented the origin of a 3d space, you could use:

# Point in a 3D rectangul= ar space=A0
RESOURCE cartesian_point [
=A0=A0 real, =A0# x coordi= nate
=A0=A0 real, =A0# y coordinate
=A0=A0 real =A0 # z co= ordinate
];

# Origin of a rectangular (c= artesian) space
RESOURCE cartesian_origin [ 0.0, 0.0, 0.0 ];
=

item 3 : type specifiers use the same names as the e= lements inside the XML serialization.

instead of using "int", we use "integer." ditto for= other types. so the resource definition. here's a resource definition = for something with an integer in it:

# Random resource definition of a map with an integer in it
RESOURCE whatever {
=A0=A0 element : integer
};
=

item 4 : DSD variant declarations don't suck for beginners
=

i always thought repeated '&' definitions t= o denote variants was sort of snobbish. it makes sense to peeps who've = sat through classes on regular grammars and ABNF, but i wouldn't mind i= t too much if someone with a basic understanding of procedural coding could= understand what was going on. so i came up with the VARIANT keyword. it lo= oks like this:

VARIANT <variant-name> : <variant-type> { &= lt;variants> }

so here's an example:
<= div>
# Enhanced Error resource

RESOURCE error_enhanced VARIANT error_type : string {
=A0=A0 =A0'number' : {
=A0=A0 =A0 =A0success : false,
=A0=A0 =A0 =A0errno : = integer
=A0=A0 },
=A0=A0 'string' : {
=A0=A0 =A0 =A0error : string
=A0=A0 },
=A0=A0 'url' : {
=A0=A0 =A0 =A0success : false,
=A0=A0 =A0 =A0descript= ion : uri
=A0=A0 }
};

<= div>what this means is that the "error_enhanced" resource has thr= ee valid forms, that look like:

RESOURCE error_enhanced {=
=A0=A0 error_type : 'number',
=A0=A0 success = : false,
=A0=A0 errno : integer
};

RESOURCE error_enhanced {
=A0=A0 error_t= ype : 'string',
=A0=A0 success : false,
=A0=A0 error : string<= /div>
}

RESOURCE error_enhanced {
=A0= =A0 error_type : 'url',
=A0=A0 success : false,
=A0=A0 description : uri
= }

so the <variant name> = shows up as an element in each of the valid forms as an literal element of = type <variant-type>.

item 5 : say good by to HTTP verbs.

LLIDL= as specified is pretty much intertwined with HTTP. many people thought tha= t was a bad idea. In creating an interface, DSD uses five abstract "in= teraction semantics": CREATE, READ, UPDATE, DELETE and EVENT.

the first four do what you expect them to do while the = last one describes the form or "shape" of an unsolicited message = coming from the event queue.

so if you wanted to l= ogin, you might use the following interface

INTERFACE CREATE session_= factory {
=A0=A0 username : string,
=A0=A0 secret : binary
= } RESPONSE VARIANT success : boolean {
=A0=A0 false : {
=A0=A0 =A0 =A0errno : integer,
=A0=A0 =A0 =A0err : st= ring,
= =A0=A0 =A0 =A0description : uri
=A0=A0 },
=A0=A0 true : {
=A0=A0 =A0 =A0seed : uri
=A0=A0 }
};=

or, you could do the following:
=
RESOURCE error {
=A0=A0 errno : integer,
=A0=A0 err : string,
=A0=A0 description : uri
};

INTERFACE CREATE session_fac= tory {
=A0=A0 username : string,
=A0=A0 secret : binary
= } RESPONSE VARIANT success : boolean {
=A0=A0 false : erro= r,
=A0=A0 true : {
=A0=A0 =A0 =A0seed : uri
=
=A0=A0 }
};

so anyway, i'm wri= ting up this stuff in the DSD type system draft. feel free to comment. as t= hings stand, if VWRAP continues as a working group, i'll integrate your= comments on the draft. if not, i'll modify the draft so as to remain c= ompatibility with existing DSD implementations and publish it a an individu= al / informational draft for the purpose of registering the mime types.

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

--90e6ba53a24ca416a10499fd6e8e-- From lenglish5@cox.net Mon Jan 17 11:50:14 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 8EE493A6E0A for ; Mon, 17 Jan 2011 11:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_50=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 jLRDx0NWfmKQ for ; Mon, 17 Jan 2011 11:50:12 -0800 (PST) Received: from fed1rmmtao106.cox.net (fed1rmmtao106.cox.net [68.230.241.40]) by core3.amsl.com (Postfix) with ESMTP id BB2023A6DB6 for ; Mon, 17 Jan 2011 11:50:11 -0800 (PST) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao106.cox.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110117195246.FYLH4722.fed1rmmtao106.cox.net@fed1rmimpo01.cox.net> for ; Mon, 17 Jan 2011 14:52:46 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo01.cox.net with bizsmtp id wjsm1f0082l1Ksg03jsmNi; Mon, 17 Jan 2011 14:52:46 -0500 X-VR-Score: 10.00 X-Authority-Analysis: v=1.1 cv=URcWsAvbbTD695UlQDiWLTZeJA7keLulqesm9570ZRU= c=1 sm=1 a=90LM7xyBXb0A:10 a=Wajolswj7cQA:10 a=8nJEP1OIZ-IA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=1IxE_5CaAAAA:8 a=cfHPFXhNAAAA:8 a=TI5cCLEFo9FDVEPq_74A:9 a=FjhmTNI__s7XhZMH4eh_7jSyYjAA:4 a=wPNLvfGTeEIA:10 a=59SicgXKKsoA:10 a=ppG0gJqgHW8A:10 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <4D349E0E.3070101@cox.net> Date: Mon, 17 Jan 2011 12:52:46 -0700 From: Lawson English User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] AW Groupies meeting on mesh asset interop 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, 17 Jan 2011 19:50:14 -0000 The AW Groupies meeting tomorrow will be Aaron Waslh talking (in voice with questions taken in voice and text) about the iED OpenFile Format: http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22 at 9:30 AM Second Life Time IM Saijanai Kuhn for an invite to AW Groupies if you want to participate Lawson (Saijanai Kuhn in Second Life) From morgaine.dinova@googlemail.com Tue Jan 18 05:53: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 D8F243A6F16 for ; Tue, 18 Jan 2011 05:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=0.128, 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 mwX9alQsDupE for ; Tue, 18 Jan 2011 05:53:03 -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 862963A6EED for ; Tue, 18 Jan 2011 05:53:03 -0800 (PST) Received: by qwi2 with SMTP id 2so6234452qwi.31 for ; Tue, 18 Jan 2011 05:55:40 -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=qI0mUF/LlE7UxxsKOqLmRgF10pTNOH5aYh9PN/TJXMw=; b=qkWmiHMJMI/6/74y4HQHD+JaRFynzYuFIMrKTwjGW+fvt58IYeL9Unv5Mf7AF+gkZH tbLo5HUXYV52fAwMGAbe7sUudZEUlZwTomQ11G9378iCoEB27ckKWduGtt3XqJJzwkWw 6iFrMhpTs1SHkE7UyLtvGRlZ/BKvhUSDr5K3c= 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=SUD7r0/pJKKtj3S3XyQd0QK3XGxEf3WudVp68zcE2THD71wShBzwoQ3D5YFHemfoBg yI0bLH44tJjOVvBnAHeowNQerr79ZkfS82VtoEOCNyHe9AJ8hwak7M99/dMS5395il+d 5SfAbI6VnGiE4BnVVHuKbTPQd5+enq5RF0xhg= MIME-Version: 1.0 Received: by 10.229.231.21 with SMTP id jo21mr4858527qcb.119.1295358939340; Tue, 18 Jan 2011 05:55:39 -0800 (PST) Received: by 10.229.225.81 with HTTP; Tue, 18 Jan 2011 05:55:39 -0800 (PST) In-Reply-To: <4D349E0E.3070101@cox.net> References: <4D349E0E.3070101@cox.net> Date: Tue, 18 Jan 2011 13:55:39 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e686cd6c6fa19d049a1f4126 Subject: Re: [vwrap] AW Groupies meeting on mesh asset interop 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, 18 Jan 2011 13:53:04 -0000 --0016e686cd6c6fa19d049a1f4126 Content-Type: text/plain; charset=ISO-8859-1 Thank you for organizing this, Lawson. I feel it's extremely important that we embrace open content formats as a core principle in VWRAP, because content is at the heart of interop. This will create immense synergy between virtual worlds once they start to interoperate with no barriers of content incompatibility. Because of our origins in the Second Life universe, our content types have never been specified explicitly, but merely assumed to be those of Second Life extended with some kind of MIME-tagged extension set. This isn't really good enough for a purported Internet standard. "Extensible" means nothing in practice if we have not addressed how extended types are actually handled by worlds and clients alike. Liaising with groups like iED can get us on the road towards widespread interop of content between worlds, beyond our narrow little prim-based enclave. That would be fantastic. Morgaine. ==================================== On Mon, Jan 17, 2011 at 7:52 PM, Lawson English wrote: > The AW Groupies meeting tomorrow will be Aaron Waslh talking (in voice with > questions taken in voice and text) about the iED OpenFile Format: > http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html > at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22 at > 9:30 AM Second Life Time > IM Saijanai Kuhn for an invite to AW Groupies if you want to participate > > > Lawson (Saijanai Kuhn in Second Life) > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016e686cd6c6fa19d049a1f4126 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thank you for organizing this, Lawson.

I feel it's extremely imp= ortant that we embrace open content formats as a core principle in VWRAP, b= ecause content is at the heart of interop.=A0 This will create immense syne= rgy between virtual worlds once they start to interoperate with no barriers= of content incompatibility.

Because of our origins in the Second Life universe, our content types h= ave never been specified explicitly, but merely assumed to be those of Seco= nd Life extended with some kind of MIME-tagged extension set.=A0 This isn&#= 39;t really good enough for a purported Internet standard.=A0 "Extensi= ble" means nothing in practice if we have not addressed how extended t= ypes are actually handled by worlds and clients alike.

Liaising with groups like iED can get us on the road towards widespread= interop of content between worlds, beyond our narrow little prim-based enc= lave.=A0 That would be fantastic.


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

On Mon,= Jan 17, 2011 at 7:52 PM, Lawson English <lenglish5@cox.net> wrote:
The AW Groupies meeting tomorrow will be Aaron Waslh talking (in voice with= questions taken in voice and text) about the iED OpenFile Format: http://mediagrid.org/news/2010-11_iED_Create_Once_= Experience_Everywhere.html
at http://maps.secondlife.com/secondlife/ThorneBridgeT= own/156/130/22 at 9:30 AM Second Life Time
IM Saijanai =A0Kuhn for an invite to AW Groupies =A0if you want to particip= ate


Lawson (Saijanai Kuhn in Second Life)
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016e686cd6c6fa19d049a1f4126-- From morgaine.dinova@googlemail.com Tue Jan 18 06:39:36 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 D6AA028C117 for ; Tue, 18 Jan 2011 06:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.857 X-Spam-Level: X-Spam-Status: No, score=-2.857 tagged_above=-999 required=5 tests=[AWL=0.119, 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 dogrS659p8mX for ; Tue, 18 Jan 2011 06:39:35 -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 6A66428C0EB for ; Tue, 18 Jan 2011 06:39:35 -0800 (PST) Received: by qwi2 with SMTP id 2so6286830qwi.31 for ; Tue, 18 Jan 2011 06:42:12 -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:content-type; bh=Psj3smBlf9VVqQ7WdrFJMylxpaikb3hW7wdTexFdEss=; b=Pi96HYeDUKT6fJ2b7tHHjqRN0B9LlXiwbtoaHcUqHv74Hjq+cCHuEpctBC1WDTPkC5 j49cFofCknSa1HovuLa1dViB6iD4MZc2CgsowpDAG4jOqcg0wK3D/yJU4YmVNZ0NEJQ4 ZZcBqG38RTWDG9LqZxZEz+xMzqjkTjemuyp+g= 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=kIM2BdJV4BYmhQss7RcCCft+nsAOK9Z05Y9wdo0/rgczSECGNjffq8vzmXendNzCbE k0FHk5xc0dKEm78+9PtpZrca+EJgkqtWhVWnPWNQqQilOxCm2oiyf5J9YEoca6TXVS/3 LSAZFeIp3VmMI1fvnCqBirCv6Py5xfLrwHrEs= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr4922378qcl.157.1295361732391; Tue, 18 Jan 2011 06:42:12 -0800 (PST) Received: by 10.229.225.81 with HTTP; Tue, 18 Jan 2011 06:42:12 -0800 (PST) In-Reply-To: References: <4D349E0E.3070101@cox.net> Date: Tue, 18 Jan 2011 14:42:12 +0000 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00163642748dea32b5049a1fe74e Subject: Re: [vwrap] AW Groupies meeting on mesh asset interop 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, 18 Jan 2011 14:39:36 -0000 --00163642748dea32b5049a1fe74e Content-Type: text/plain; charset=ISO-8859-1 Further on this subject, be sure to watch iED's interesting video at http://www.youtube.com/ImmersiveED#p/u/0/cMhBiu0YJ3s . A key sentence from near the end of the video: "*Here, realXtend is actually getting that crab out of Wonderland. In other words, Wonderland is hosting the crab in its asset repositories, and realXtend is pulling directly from the Wonderland server, the Wonderland content repository, to enable drag'n'drop right there in realXtend.*" Well done, realXtend and OpenWonderland, and of course iED! :-) Clearly all of this is heading beyond mere format compatibility and towards full interoperability between worlds. Our work in VWRAP can help that goal happen. Indeed, if it does not then it may rapidly become irrelevant. Morgaine. ================================ On Tue, Jan 18, 2011 at 1:55 PM, Morgaine wrote: > Thank you for organizing this, Lawson. > > I feel it's extremely important that we embrace open content formats as a > core principle in VWRAP, because content is at the heart of interop. This > will create immense synergy between virtual worlds once they start to > interoperate with no barriers of content incompatibility. > > Because of our origins in the Second Life universe, our content types have > never been specified explicitly, but merely assumed to be those of Second > Life extended with some kind of MIME-tagged extension set. This isn't > really good enough for a purported Internet standard. "Extensible" means > nothing in practice if we have not addressed how extended types are actually > handled by worlds and clients alike. > > Liaising with groups like iED can get us on the road towards widespread > interop of content between worlds, beyond our narrow little prim-based > enclave. That would be fantastic. > > > Morgaine. > > > > > ==================================== > > > On Mon, Jan 17, 2011 at 7:52 PM, Lawson English wrote: > >> The AW Groupies meeting tomorrow will be Aaron Waslh talking (in voice >> with questions taken in voice and text) about the iED OpenFile Format: >> http://mediagrid.org/news/2010-11_iED_Create_Once_Experience_Everywhere.html >> at http://maps.secondlife.com/secondlife/ThorneBridgeTown/156/130/22 at >> 9:30 AM Second Life Time >> IM Saijanai Kuhn for an invite to AW Groupies if you want to participate >> >> >> Lawson (Saijanai Kuhn in Second Life) >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > --00163642748dea32b5049a1fe74e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Further on this subject, be sure to watch iED's interesting video at=A0= http://ww= w.youtube.com/ImmersiveED#p/u/0/cMhBiu0YJ3s .

A key sentence fro= m near the end of the video:

"Here, realXtend is actually = getting that crab out of Wonderland.=A0 In other words, Wonderland is hosti= ng the crab in its asset repositories, and realXtend is pulling directly fr= om the Wonderland server, the Wonderland content repository, to enable drag= 'n'drop right there in realXtend."

Well done, realXtend and OpenWonderland, and of course iED! :-)
Clearly all of this is heading beyond mere format compatibility and t= owards full interoperability between worlds.=A0 Our work in VWRAP can help = that goal happen.=A0 Indeed, if it does not then it may rapidly become irre= levant.


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

On Tue, Jan 18, 2011 at 1:55 PM, Morgaine <morgaine.dinova@= googlemail.com> wrote:
Thank you for org= anizing this, Lawson.

I feel it's extremely important that we em= brace open content formats as a core principle in VWRAP, because content is= at the heart of interop.=A0 This will create immense synergy between virtu= al worlds once they start to interoperate with no barriers of content incom= patibility.

Because of our origins in the Second Life universe, our content types h= ave never been specified explicitly, but merely assumed to be those of Seco= nd Life extended with some kind of MIME-tagged extension set.=A0 This isn&#= 39;t really good enough for a purported Internet standard.=A0 "Extensi= ble" means nothing in practice if we have not addressed how extended t= ypes are actually handled by worlds and clients alike.

Liaising with groups like iED can get us on the road towards widespread= interop of content between worlds, beyond our narrow little prim-based enc= lave.=A0 That would be fantastic.


Morgai= ne.




=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<= br>
On Mon, Jan 17, 2011 at 7:52 PM, Lawson E= nglish <lenglish5@cox.net> wrote:
The AW Groupies meeting tomorrow will be Aaron Waslh talking (in voice with= questions taken in voice and text) about the iED OpenFile Format: http://mediagrid.org/news/2010-11_iED_Create_Once_= Experience_Everywhere.html
at http://maps.secondlife.com/secondlife/ThorneBridgeT= own/156/130/22 at 9:30 AM Second Life Time
IM Saijanai =A0Kuhn for an invite to AW Groupies =A0if you want to particip= ate


Lawson (Saijanai Kuhn in Second Life)
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--00163642748dea32b5049a1fe74e-- From barryleiba.mailing.lists@gmail.com Wed Jan 19 08:02: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 BA8663A701D for ; Wed, 19 Jan 2011 08:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.557, 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 u23NPUM0MSGA for ; Wed, 19 Jan 2011 08:02:10 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AEF4D3A701B for ; Wed, 19 Jan 2011 08:02:10 -0800 (PST) Received: by gwj17 with SMTP id 17so323142gwj.31 for ; Wed, 19 Jan 2011 08:04:50 -0800 (PST) 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=Jz/3jEJgVGYlSRxw0zdrBNe2dPp+0XwESs+ZBpymcbQ=; b=P/lhH53qk0C87SWvTj9eedWuKia1wAmkqGUc+lvKBO33W6ybSTcSTBZ62UGMIN2CRE nKCIT3RZa6c9DtkjJUY9cOCuuOglwVcHL8NmFFOKgoYobokQXEeOYxV1papcw3W2G2lu R69hu/2nsuQarO0auwAyiNWaPh0xlKra5fN3w= 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=cpopQz0JMjDu5mMRXCDM/Xcp/qFKvdGljxbcHIFPIT+Sq9jLRkpFw8pfNXzyY+w7cg aRCbB7f+XpnKCnnbtHL0KwweUvXH1uTsxD49HsItMFoFIJlso6zJ33KsDkTo27ZR4tmm j7d/ojSs1pjrTipc8gZnzXUuQKwNMpTNblOj8= MIME-Version: 1.0 Received: by 10.42.170.200 with SMTP id g8mr1078447icz.85.1295453090420; Wed, 19 Jan 2011 08:04:50 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.42.227.193 with HTTP; Wed, 19 Jan 2011 08:04:50 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Wed, 19 Jan 2011 11:04:50 -0500 X-Google-Sender-Auth: koR81HNrRDMFMg8u7b29fqonVUQ 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: Wed, 19 Jan 2011 16:02:11 -0000 On Sat, Jan 15, 2011 at 7:05 PM, Meadhbh Hamrick wrote: > options 1 & 2 require someone to step up and volunteer to author new docs. > > any takers? > > if no one will step up, then i think option #3 is most appropriate. > > if i read barry's email correctly, euthanizing VWRAP now does not > preclude rechartering in the future if there's renewed interest. Meadhbh is correct. The chairs and ADs need to talk about the recent postings, but my personal sense of it is that there are enough people who want to continue and want to do it by steering in at least a somewhat different direction. That works if and only if people actually step up and do the editing, reviews, and so on. So, yes, if we do continue, the first step will be to have someone (or some set of people; I'd actually be happier with at least two editors) take over the introduction document, lead the discussion of what should be in it, and post a revised version that starts turning the wheel. (And, yes, Meadhbh's last statement is also correct: we could close the current effort and charter something related later. On the other hand, if "later" would be within the next year or so, I'd rather try to continue from where we are.) Barry, sort of as chair, but mostly just talking out of his a[vatar] From morgaine.dinova@googlemail.com Wed Jan 19 11:54: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 6208A3A7060 for ; Wed, 19 Jan 2011 11:54:41 -0800 (PST) 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 d2XDVqRrlKFY for ; Wed, 19 Jan 2011 11:54:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CECFB3A7019 for ; Wed, 19 Jan 2011 11:54:39 -0800 (PST) Received: by vws7 with SMTP id 7so572154vws.31 for ; Wed, 19 Jan 2011 11:57:20 -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=OfbPU0PM9eXkEkuiQvBTmiPDvkrZDsZXfR1MDCHVe0M=; b=UQYfMDaz3fno4FkvuWLrk5Ie6AtrUGpKjpcVqYcXtMMSpHDILymlcFh1lQ3Wwn5R0v IHm4s4/HAvY5ezYMro39vC7HhWbxHuuzVmM4xe1h2FytgoMn3Xm8y3+EvBTS0G97ziec 9mVsbdrZbkiq7GZ3hL0aPXZrT5g1lNTPZ0wFs= 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=umiuX6nYsgOvDGTXYiWqDXxKZUn7dsCdn+OjSmW0dx+tCvRYBwYPYK5/UvRHUiReVH H3wSCQUDuzosRjCnZ+gzkeMHqVDLrxW0Hrv0D4n5tQKyUP1cOUIx7epww05L8PXZljmJ a38CA1Qi64zgontphVSRsOAKQQydE92XErVQM= MIME-Version: 1.0 Received: by 10.229.89.208 with SMTP id f16mr978625qcm.43.1295467040107; Wed, 19 Jan 2011 11:57:20 -0800 (PST) Received: by 10.229.225.81 with HTTP; Wed, 19 Jan 2011 11:57:19 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Wed, 19 Jan 2011 19:57:19 +0000 Message-ID: From: Morgaine To: Barry Leiba Content-Type: multipart/alternative; boundary=0016364eed32be6d81049a386cb8 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, 19 Jan 2011 19:54:41 -0000 --0016364eed32be6d81049a386cb8 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 19, 2011 at 4:04 PM, Barry Leiba wrote: > On the other hand, if "later" would be within the next year or so, I'd > rather try > to continue from where we are.) > That's good to hear Barry, and I agree fully that continuing makes more sense. A change of emphasis that makes interop between worlds a central goal doesn't require a new IETF group, since that goal is the one that most VWRAP contributors have expressed support for all along. There is much more continuity in this change than discontinuity. 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. While progress is slow currently, I have the feeling that it would pick up steam if only we didn't have to continually revisit previous battlegrounds. Incompatible interop goals has a very chilling effect on writing specifications for interop protocols. Morgaine. ========================= On Wed, Jan 19, 2011 at 4:04 PM, Barry Leiba wrote: > On Sat, Jan 15, 2011 at 7:05 PM, Meadhbh Hamrick > wrote: > > options 1 & 2 require someone to step up and volunteer to author new > docs. > > > > any takers? > > > > if no one will step up, then i think option #3 is most appropriate. > > > > if i read barry's email correctly, euthanizing VWRAP now does not > > preclude rechartering in the future if there's renewed interest. > > Meadhbh is correct. The chairs and ADs need to talk about the recent > postings, but my personal sense of it is that there are enough people > who want to continue and want to do it by steering in at least a > somewhat different direction. That works if and only if people > actually step up and do the editing, reviews, and so on. > > So, yes, if we do continue, the first step will be to have someone (or > some set of people; I'd actually be happier with at least two editors) > take over the introduction document, lead the discussion of what > should be in it, and post a revised version that starts turning the > wheel. > > (And, yes, Meadhbh's last statement is also correct: we could close > the current effort and charter something related later. On the other > hand, if "later" would be within the next year or so, I'd rather try > to continue from where we are.) > > Barry, sort of as chair, but mostly just talking out of his a[vatar] > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016364eed32be6d81049a386cb8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 4:04 PM, Barry Leiba <barryleiba@computer.org> = wrote:
On the other hand, if "later" would be within the next year or so= , I'd rather try
to continue from where we are.)


That's good to hear Barry, and I agree fully that = continuing makes more sense.

A change of emphasis that makes interop= between worlds a central goal doesn't require a new IETF group, since = that goal is the one that most VWRAP contributors have expressed support fo= r all along.=A0 There is much more continuity in this change than discontin= uity.

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 bein= g done informally, not as an official draft but as input to a totally new d= raft.=A0 It was not being done as a revision because the previous Intro sim= ply did not meet key requirements for many contributors, as was clear from = the group's very intense discussions of September.

While progress is slow currently, I have the feeling that it would pick= up steam if only we didn't have to continually revisit previous battle= grounds.=A0 Incompatible interop goals has a very chilling effect on writin= g specifications for interop protocols.


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 Wed, Jan 19, 2011 at 4:04 PM, Barry Leiba <barryleiba@computer.org>= wrote:
On Sat, Jan 15, 2011 at 7:05 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
> options 1 & 2 require someone to step up and volunteer to author n= ew docs.
>
> any takers?
>
> if no one will step up, then i think option #3 is most appropriate. >
> if i read barry's email correctly, euthanizing VWRAP now does not<= br> > preclude rechartering in the future if there's renewed interest.
Meadhbh is correct. =A0The chairs and ADs need to talk about the rece= nt
postings, but my personal sense of it is that there are enough people
who want to continue and want to do it by steering in at least a
somewhat different direction. =A0That works if and only if people
actually step up and do the editing, reviews, and so on.

So, yes, if we do continue, the first step will be to have someone (or
some set of people; I'd actually be happier with at least two editors)<= br> take over the introduction document, lead the discussion of what
should be in it, and post a revised version that starts turning the
wheel.

(And, yes, Meadhbh's last statement is also correct: we could close
the current effort and charter something related later. =A0On the other
hand, if "later" would be within the next year or so, I'd rat= her try
to continue from where we are.)

Barry, sort of as chair, but mostly just talking out of his a[vatar]
_________________________________________= ______
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016364eed32be6d81049a386cb8-- From barryleiba@gmail.com Wed Jan 19 12:13: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 F313D3A71BC for ; Wed, 19 Jan 2011 12:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=0.204, 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 vmiU8GcxbHv2 for ; Wed, 19 Jan 2011 12:13:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 2B7123A71BB for ; Wed, 19 Jan 2011 12:13:09 -0800 (PST) Received: by iyi42 with SMTP id 42so1261258iyi.31 for ; Wed, 19 Jan 2011 12:15:50 -0800 (PST) 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 :content-transfer-encoding; bh=I04F3WeSqWDStW0jgEiOK3Ny8wZqgbHAznUQJ2onzCg=; b=DwkaxM6rYDwuQ8FYmketFB4tlQOJ5LIKPe24C+V6yjof8lRbekQGBa6MzgCoPJIdWc R6MAVRUm1hdTM8K/snUhMc2G6bu+/mvE7c6XXc46MrpQpbja+vdY/J2nsY4R8GTgIZou Wvcrkfq97M3dLfkK5YbYJVMJyEMslbALPxKGg= 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 :content-transfer-encoding; b=t5J9FLqjAhSknkH3rsL2PWYXwVi2mcwO7Ydjrimam99JUZ2gwIPm81+8o+dSEfiasI CFqUN6eyRivNUm2/f1fNTu/1dfAPgihl7VeYj5Tth3T5KV56ki3fyXnKtSUAWufKN3Sr p9dwXeEZ3ivRrY/3DoZnfWbfUKSW13apm+X+A= MIME-Version: 1.0 Received: by 10.231.36.5 with SMTP id r5mr1401962ibd.134.1295468149851; Wed, 19 Jan 2011 12:15:49 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.231.208.12 with HTTP; Wed, 19 Jan 2011 12:15:49 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Wed, 19 Jan 2011 15:15:49 -0500 X-Google-Sender-Auth: a8x_cs4T6pO-OszIo578vvDI41o Message-ID: From: Barry Leiba 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: Wed, 19 Jan 2011 20:13:10 -0000 > 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 bein= g > 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 ? That would give people something concrete to work from. Barry From morgaine.dinova@googlemail.com Wed Jan 19 12:58: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 D9D5728C0FB for ; Wed, 19 Jan 2011 12:58:22 -0800 (PST) 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 Uzqb5vCZmUMq for ; Wed, 19 Jan 2011 12:58:21 -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 8877228C0EB for ; Wed, 19 Jan 2011 12:58:21 -0800 (PST) Received: by qyk34 with SMTP id 34so1065593qyk.10 for ; Wed, 19 Jan 2011 13:01:02 -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=/ll3Pj1OhSul456AojfyfG1bokJEDcbafTDBH3WejKU=; b=xxiRFdozae3Js+R6JrZyLIWmSwIMKCjB/V0+7mLSZ7YRAftqgt3TrzxvdBsPPWB2Jj FnkD/cZIWwldeviow4rPey7P9x97St+i6dXAR8FQuPaxb91nAdIWQE1enoeDk17gGN1Q iL5REF4G/vgaAprOcYOPh1uU1eZumJjUrnUJo= 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=L3guIPk/AF6O32gVHarsOmefidrSAR6RoAqPOZzR9UktTWgbetPzqfjOdtC9rfxlzg 3KeLvdARoLHP3SzvRX9W+BcIvaTlukRgN1zItwbrAtGbhpPeHFkeot51yRPanHAO9kQ/ tIe52sptx2/FB7Qxksld/Jxa3k2OpnoTH3lTA= MIME-Version: 1.0 Received: by 10.229.89.208 with SMTP id f16mr1031069qcm.43.1295470861867; Wed, 19 Jan 2011 13:01:01 -0800 (PST) Received: by 10.229.225.81 with HTTP; Wed, 19 Jan 2011 13:01:01 -0800 (PST) In-Reply-To: References: <4D30F6FE.4020805@ics.uci.edu> Date: Wed, 19 Jan 2011 21:01:01 +0000 Message-ID: From: Morgaine To: Barry Leiba Content-Type: multipart/alternative; boundary=0016364eed3289e35b049a395005 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, 19 Jan 2011 20:58:22 -0000 --0016364eed3289e35b049a395005 Content-Type: text/plain; charset=ISO-8859-1 The idea of putting this "pre-draft" on a wiki was not mine (the work was started by two other contributors). I fully support the goal though: to use a medium where lots of people can have input, even if it's just a single paragraph or just a word correction, so that the initial draft doesn't suffer the problem of inertia while massive changes are afoot. It also overcomes the personalization issue that arises when drafts are tagged officially with a particular person's name. Since this is being done as a collaborative effort, perhaps it would be fairer if some impartial party tags this initial draft of the "new" Intro instead. We've suffered somewhat with draft personalization issues in the past. Be that as it may, we have much work ahead of us to make this Intro a document that reflects the group's rough consensus of aspirations on interop, even for an initial draft. We need more people to contribute some typing time. Those who found the current draft lacking in respect of interop, this is your chance for change. :-) Morgaine. =========================== On Wed, Jan 19, 2011 at 8: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. > > Barry > --0016364eed3289e35b049a395005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The idea of putting this "pre-draft" on a wiki was not mine (the = work was started by two other contributors).=A0 I fully support the goal th= ough:=A0 to use a medium where lots of people can have input, even if it= 9;s just a single paragraph or just a word correction, so that the initial = draft doesn't suffer the problem of inertia while massive changes are a= foot.

It also overcomes the personalization issue that arises when drafts are= tagged officially with a particular person's name.=A0 Since this is be= ing done as a collaborative effort, perhaps it would be fairer if some impa= rtial party tags this initial draft of the "new" Intro instead.= =A0 We've suffered somewhat with draft personalization issues in the pa= st.

Be that as it may, we have much work ahead of us to make this Intro a d= ocument that reflects the group's rough consensus of aspirations on int= erop, even for an initial draft.=A0 We need more people to contribute some = typing time.=A0 Those who found the current draft lacking in respect of int= erop, this is your chance for change. :-)


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, Jan 19, 2011 at 8: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.=A0 It was b= eing
> done informally, not as an official draft but as input to a totally ne= w
> draft.=A0 It was not being done as a revision because the previous Int= ro
> simply did not meet key requirements for many contributors, as was cle= ar
> 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.

Barry

--0016364eed3289e35b049a395005-- From stpeter@stpeter.im Thu Jan 20 19:01: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 BFC9A3A68AC for ; Thu, 20 Jan 2011 19:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ufmXKIzSVWaF for ; Thu, 20 Jan 2011 19:01:33 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C93EA3A68A6 for ; Thu, 20 Jan 2011 19:01:33 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C5752400EE for ; Thu, 20 Jan 2011 20:20:02 -0700 (MST) Message-ID: <4D38F7B0.4090506@stpeter.im> Date: Thu, 20 Jan 2011 20:04:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: vwrap@ietf.org References: <4D30F6FE.4020805@ics.uci.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090307070201060306090207" 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, 21 Jan 2011 03:01:34 -0000 This is a cryptographically signed message in MIME format. --------------ms090307070201060306090207 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 On 1/19/11 2:01 PM, Morgaine wrote: > The idea of putting this "pre-draft" on a wiki was not mine (the work > was started by two other contributors). I fully support the goal > though: to use a medium where lots of people can have input, even if > it's just a single paragraph or just a word correction, so that the > initial draft doesn't suffer the problem of inertia while massive > changes are afoot. >=20 > It also overcomes the personalization issue that arises when drafts are= > tagged officially with a particular person's name. Since this is being= > done as a collaborative effort, perhaps it would be fairer if some > impartial party tags this initial draft of the "new" Intro instead.=20 > We've suffered somewhat with draft personalization issues in the past. >=20 > Be that as it may, we have much work ahead of us to make this Intro a > document that reflects the group's rough consensus of aspirations on > interop, even for an initial draft. We need more people to contribute > some typing time. Those who found the current draft lacking in respect= > of interop, this is your chance for change. :-) >=20 >=20 > Morgaine. >=20 >=20 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 > On Wed, Jan 19, 2011 at 8:15 PM, Barry Leiba > wrote: >=20 > > 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 wa= s > 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 wa= s > clear > > from the group's very intense discussions of September. >=20 > Can you see if you can get it into reasonable shape to introduce > publicly, and then submit it as draft-morgaine-vwrap-intro-00 ? Th= at > would give people something concrete to work from. >=20 > Barry >=20 --------------ms090307070201060306090207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy MTAzMDQxNlowIwYJKoZIhvcNAQkEMRYEFAHHxYfJm5nwzCyEQlYGsGsIaaCaMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAyaRB3lAgVoUjrjM76appmr4bs0P0Xpwq9crG2/UgS4bVNQ1OZmqEbpB7x R6KvYeFgHO8ykPI6AsQNsIhQiDABUDFbTkaeIGQJgwXdqcvaJxqb3Q3SfTw2t6dkb3Xj3RCZ UOJ/0yctd6w4bgKMhrDqYFQhmIGWShE9iL2btchesPfd+ezxq9fmMInhuLBbM+C5swkU8eLO QcHgGPn6wrRQsngn7G84byqsB0C8rAqodG8XXUIkDjlhdLYuDtVoaULX//p01S9ACKaf37JX N7TCNlGk0O7UuWqgdGVocBxg5w0ZZ+JB+MwqyJSvrmUJq6GkTodTTwYSzIAnJ2JypPetAAAA AAAA --------------ms090307070201060306090207-- From stpeter@stpeter.im Thu Jan 20 19:10: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 27AAC3A682B for ; Thu, 20 Jan 2011 19:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 00pi2A4p753K for ; Thu, 20 Jan 2011 19:10:50 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 17B873A6826 for ; Thu, 20 Jan 2011 19:10:50 -0800 (PST) Received: from squire.local (dsl-251-175.dynamic-dsl.frii.net [216.17.251.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1EC4E400EE for ; Thu, 20 Jan 2011 20:29:19 -0700 (MST) Message-ID: <4D38F9DC.9090107@stpeter.im> Date: Thu, 20 Jan 2011 20:13:32 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: vwrap@ietf.org References: <4D30F6FE.4020805@ics.uci.edu> In-Reply-To: X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080902060508040104000709" 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, 21 Jan 2011 03:10:51 -0000 This is a cryptographically signed message in MIME format. --------------ms080902060508040104000709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With my area director hat still on... On 1/19/11 12:57 PM, Morgaine wrote: > A change of emphasis that makes interop between worlds a central goal > doesn't require a new IETF group, since that goal is the one that most > VWRAP contributors have expressed support for all along. There is much= > more continuity in this change than discontinuity. Agreed. However, it does require a rechartered IETF group, because our current charter is heavily focused on defining an abstract type system, specifying data formats for objects and avatars, and developing application-layer protocols establishing and moving avatars in a region, identifying and requesting information about entities, etc. The current charter is here: http://tools.ietf.org/wg/vwrap/charters How would folks in this group modify the charter to properly scope the revised effort? Feel free to discuss that topic on this list, and to use the wiki as a sketchboard: http://trac.tools.ietf.org/wg/vwrap/trac/wiki Oh, and did I mention that you can obtain login credentials for the Trac wiki at the following URL? ;-) http://trac.tools.ietf.org/tools/loginmgr/newlogin Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms080902060508040104000709 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEy MTAzMTMzMlowIwYJKoZIhvcNAQkEMRYEFPaHfKzinwUkOs/cFkUWlAeXd091MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBGvJKyUeuU3ImlWMJiGT+jwnrjVchEqmo79/V1LlsAw1+gV6adjOhfUHRG HUUksv6BUyh/Yn6HjmSvFIIVuFrrYY5o2OnDLgfO8W9QjDtrgxTjlj815tO38sW/SqT6B8H5 +nr1AY/gDYCtusCDEGwpy+YxSC0Or2IZYgKmPaSdHVA7R+cUOYQEAeqjlZA3S5sJisA3NLC5 m3eMOgls4wn/DGRhFVrFmZTL7iIhTMCv4SWb2mfzVd/2ZHdxROzfu0hKB6MBURfKy11h+KhQ V0zX/d3kmRLqPN5CkL/d5rzqdXqibVknEGIGnqMf1mp0jstUMHUyR4cXYiHLylAHVT2zAAAA AAAA --------------ms080902060508040104000709-- From lenglish5@cox.net Thu Jan 20 19:20: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 AB9283A67E3 for ; Thu, 20 Jan 2011 19:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.484 X-Spam-Level: X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=1.114, 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 PrL1PNaCIiT6 for ; Thu, 20 Jan 2011 19:20:21 -0800 (PST) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 843823A6830 for ; Thu, 20 Jan 2011 19:20:21 -0800 (PST) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao107.cox.net (InterMail vM.8.01.03.00 201-2260-125-20100507) with ESMTP id <20110121032305.MAZS13015.fed1rmmtao107.cox.net@fed1rmimpo03.cox.net> for ; Thu, 20 Jan 2011 22:23:05 -0500 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id y3P51f00E2l1Ksg043P5Ht; Thu, 20 Jan 2011 22:23:05 -0500 X-VR-Score: -154.00 X-Authority-Analysis: v=1.1 cv=vWqChlSN17ID9vwy2WxNUKipYCNqDp4HbHlXNc8DAM4= c=1 sm=1 a=I88v0MqpzI0A:10 a=Wajolswj7cQA:10 a=lHHFyFaL52RzbKbxZIYZqA==:17 a=mNkT-bCMAAAA:8 a=48vgC7mUAAAA:8 a=8qSefF8wAAAA:8 a=qUat_oFokPxpW_aOJxIA:9 a=iBllyKBM-tJeTGq33XAA:7 a=JAAx4ZXsNGb3yMqX-0red4WbrAQA:4 a=QEXdDO2ut3YA:10 a=_0_MY4KVxfwA:10 a=mHZC5r8sFEQA:10 a=lZB815dzVvQA:10 a=F1owrbY1rayytLqcGpsA:9 a=ic9swk5-XxBZQMUBOocA:7 a=mPsh0gUnmg22HbJOubKAL5xWOCsA:4 a=lHHFyFaL52RzbKbxZIYZqA==:117 X-CM-Score: 0.00 Authentication-Results: cox.net; none Message-ID: <4D38FC19.2010303@cox.net> Date: Thu, 20 Jan 2011 20:23:05 -0700 From: Lawson English User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: vwrap@ietf.org References: <4D30F6FE.4020805@ics.uci.edu> <4D38F7B0.4090506@stpeter.im> In-Reply-To: <4D38F7B0.4090506@stpeter.im> Content-Type: multipart/alternative; boundary="------------080206060608040307060204" Subject: Re: [vwrap] Status and future of the VWRAP working group 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: Fri, 21 Jan 2011 03:20:23 -0000 This is a multi-part message in MIME format. --------------080206060608040307060204 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I personally like the book + wiki + forum approach found here: http://book.seaside.st/book But I'm weird. Rendering of the wiki markup can be output to PDF, latex, HTML or plain text and there's no reason why an IETF RFC output object couldn't be devised as well, to turn the finished product into the old school text RFCs require. Lawson On 1/20/11 8:04 PM, Peter Saint-Andre wrote: > 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 > > On 1/19/11 2:01 PM, Morgaine wrote: >> The idea of putting this "pre-draft" on a wiki was not mine (the work >> was started by two other contributors). I fully support the goal >> though: to use a medium where lots of people can have input, even if >> it's just a single paragraph or just a word correction, so that the >> initial draft doesn't suffer the problem of inertia while massive >> changes are afoot. >> >> It also overcomes the personalization issue that arises when drafts are >> tagged officially with a particular person's name. Since this is being >> done as a collaborative effort, perhaps it would be fairer if some >> impartial party tags this initial draft of the "new" Intro instead. >> We've suffered somewhat with draft personalization issues in the past. >> >> Be that as it may, we have much work ahead of us to make this Intro a >> document that reflects the group's rough consensus of aspirations on >> interop, even for an initial draft. We need more people to contribute >> some typing time. Those who found the current draft lacking in respect >> of interop, this is your chance for change. :-) >> >> >> Morgaine. >> >> >> >> >> =========================== >> >> On Wed, Jan 19, 2011 at 8: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. >> >> Barry >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap --------------080206060608040307060204 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I personally like the book + wiki + forum approach found here: http://book.seaside.st/book


But I'm weird.

Rendering of the wiki markup can be output to PDF, latex, HTML or plain text and there's no reason why an IETF RFC output object couldn't be devised as well, to turn the finished product into the old school text RFCs require.


Lawson



On 1/20/11 8:04 PM, Peter Saint-Andre wrote: 
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

On 1/19/11 2:01 PM, Morgaine wrote:

The idea of putting this "pre-draft" on a wiki was not mine (the work
was started by two other contributors).  I fully support the goal
though:  to use a medium where lots of people can have input, even if
it's just a single paragraph or just a word correction, so that the
initial draft doesn't suffer the problem of inertia while massive
changes are afoot.

It also overcomes the personalization issue that arises when drafts are
tagged officially with a particular person's name.  Since this is being
done as a collaborative effort, perhaps it would be fairer if some
impartial party tags this initial draft of the "new" Intro instead. 
We've suffered somewhat with draft personalization issues in the past.

Be that as it may, we have much work ahead of us to make this Intro a
document that reflects the group's rough consensus of aspirations on
interop, even for an initial draft.  We need more people to contribute
some typing time.  Those who found the current draft lacking in respect
of interop, this is your chance for change. :-)


Morgaine.




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

On Wed, Jan 19, 2011 at 8:15 PM, Barry Leiba <barryleiba@computer.org
<mailto: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.  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.

    Barry



      

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


    

    

  


--------------080206060608040307060204--

From ohmeadhbh@gmail.com  Thu Jan 20 20:07:14 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 42CC83A684C for ; Thu, 20 Jan 2011 20:07:14 -0800 (PST)
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 ujCg3-Tka4zC for ; Thu, 20 Jan 2011 20:07:12 -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 459FC3A6830 for ; Thu, 20 Jan 2011 20:07:12 -0800 (PST)
Received: by qwi2 with SMTP id 2so1429773qwi.31 for ; Thu, 20 Jan 2011 20:09:56 -0800 (PST)
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=qb7Ufd1NixzaBj/3/WXr4Ca4xYbwv627rmzuEG1ovrU=; b=dI3jxWS+sIrwgoTjMD90HDS7B8hTsIVi964iphVE9hDIRL70wy+z0xwY21kZJY7Tds 782VAHrI+F6oIPMH0YMBGAil0i1WPriOHpDHKnwfDwmfcaY/UupNZaLpCy8ryg/KtvD4 vMfi2P4thJTdo3cWMX6fMrtxW2Y+7Wa+hYpKg=
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=DSVqVIsd0Y+OyPNDb/ipm0+HolXIczustDqLD4L1G7GcGnD/mb0ket7shjXVpDEJEr o4sczM5lfGEIV2xzme3nJoonHqZhVnMssQLOm7S1UNeT4DsFlswEuv40i9VzDHuujBct sXuodxsaY9ARKAsa4+kqcgZzfVtQUoVXF8wUY=
Received: by 10.229.91.72 with SMTP id l8mr153733qcm.137.1295582996549; Thu, 20 Jan 2011 20:09:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.202.141 with HTTP; Thu, 20 Jan 2011 20:09:35 -0800 (PST)
In-Reply-To: <4D38F9DC.9090107@stpeter.im>
References:  <4D30F6FE.4020805@ics.uci.edu>           <4D38F9DC.9090107@stpeter.im>
From: Meadhbh Hamrick 
Date: Thu, 20 Jan 2011 20:09:35 -0800
Message-ID: 
To: Peter Saint-Andre 
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: Fri, 21 Jan 2011 04:07:14 -0000

may i ask what our success metric is?

i mean, there's not a lot of material at the wiki morgaine pointed to,
nor has anyone volunteered to implement anything.

i have to figure out whether the DSD drafts are going into this WG or
will go as individual / informational submissions for the purpose of
registering their MIME types (as well as publicly describing the type
system used by sl8.us and various unannounced augmented reality
projects.)

i was able to crank out a reviewed 30 page intro in about four months.
could i ask that since there are no implementers, morgaine et al be
held to a reasonable page count and time frame? say at least 8 good
pages (that pass the general consensus review) in four months that
describe things like:

* terminology : virtual world, avatar, etc.
* "style" of interoperability: it is sufficient to define only object
formats? are we defining wire protocols for components that make up
virtual worlds? are we defining high level "interop between world"
(whatever the hell that means)
* what's in scope of the WG (since the charter was designed to be
intentionally vague and depend on the intro for a more detailed
description of the the group's scope)
* protocol objectives (assuming we're going to define wire protocols)
* protocol "architecture" ( are we going to send everything over UDP?
raw TCP sockets? layered on top of HTTP? XMPP? BEEP? SMTP/MIME? is
anyone left that cares about abstract type systems in this group? )
* use cases : what are we expecting to happen when a user sits down in
front of a user agent?
* deployment patterns : are we requiring a grid? are we going to run
simulator responders at known ports (i.e. - one sim responder per IP
address)?
* trust model : what if i want to have a region in a virtual world
accessable only to trusted entities? what if i want to make sure they
can't take certain virtual goods out of that region?

or... if we know peeps here aren't interested in an abstract type
system, with the chair's permission, i'll take my draft directly to
the rfc editors and ask them nicely to publish it as an informational
RFC / individual submission.

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



On Thu, Jan 20, 2011 at 7:13 PM, Peter Saint-Andre  wro=
te:
> With my area director hat still on...
>
> On 1/19/11 12:57 PM, Morgaine wrote:
>
>> A change of emphasis that makes interop between worlds a central goal
>> doesn't require a new IETF group, since that goal is the one that most
>> VWRAP contributors have expressed support for all along. =A0There is muc=
h
>> more continuity in this change than discontinuity.
>
> Agreed. However, it does require a rechartered IETF group, because our
> current charter is heavily focused on defining an abstract type system,
> specifying data formats for objects and avatars, and developing
> application-layer protocols establishing and moving avatars in a region,
> identifying and requesting information about entities, etc.
>
> The current charter is here:
>
> =A0 =A0http://tools.ietf.org/wg/vwrap/charters
>
> How would folks in this group modify the charter to properly scope the
> revised effort?
>
> Feel free to discuss that topic on this list, and to use the wiki as a
> sketchboard:
>
> =A0 =A0http://trac.tools.ietf.org/wg/vwrap/trac/wiki
>
> Oh, and did I mention that you can obtain login credentials for the Trac
> wiki at the following URL? ;-)
>
> =A0 =A0http://trac.tools.ietf.org/tools/loginmgr/newlogin
>
> Thanks!
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

From fleep513@gmail.com  Thu Jan 20 20:37:39 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 034C73A6830 for ; Thu, 20 Jan 2011 20:37:39 -0800 (PST)
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 TSIvVFdGNJFT for ; Thu, 20 Jan 2011 20:37:37 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C5A373A68A4 for ; Thu, 20 Jan 2011 20:37:36 -0800 (PST)
Received: by ywk9 with SMTP id 9so468278ywk.31 for ; Thu, 20 Jan 2011 20:40:21 -0800 (PST)
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=4gxU02WJs3+mzJQZ15LylqkaCn0ztueQ2plNhXUKe+A=; b=mXgs/XktnEDA1RUjz7DJirA6DtNYOFbbtLqTmmVpVGuUqBFOWkCkdQDOfK2X15d+UX WCKlDDB8IESIs35DCQvZ40rjRRn32vn7Ln2Zml+VafTp+3EapCGOx/OtWjOb8+LFfdeT eXCz76E3fjFkDsJVOx+pnbMJ5CCvemViXKS0o=
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=Mqc8m+Mc/btGjgNvJad0FmfEa5X4cjyNf07WLofvrlkE/kJTXiTCM4O5vanuiUiqSn UvdJbhwMWmhlV7OZFfz+OlGM0AaJfqVujlMNJGvWqD75Chu1AP8Cpf/2rnioSZtTARHl Lqy7afH1gfjxnmgd+c/AEUwzW37eaxMA+iTaI=
MIME-Version: 1.0
Received: by 10.90.28.17 with SMTP id b17mr202089agb.128.1295584821146; Thu, 20 Jan 2011 20:40:21 -0800 (PST)
Received: by 10.91.162.6 with HTTP; Thu, 20 Jan 2011 20:40:21 -0800 (PST)
In-Reply-To: <4D38F7B0.4090506@stpeter.im>
References:  <4D30F6FE.4020805@ics.uci.edu>             <4D38F7B0.4090506@stpeter.im>
Date: Thu, 20 Jan 2011 23:40:21 -0500
Message-ID: 
From: Fleep Tuque 
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016e64808ba0a72d5049a53d989
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, 21 Jan 2011 04:37:39 -0000

--0016e64808ba0a72d5049a53d989
Content-Type: text/plain; charset=ISO-8859-1

Thanks Peter!  I didn't realize IETF offered a wiki for the group's use when
I suggested using the wikispaces platform - so I'll apologize for that.
 This is my first time participating and I'm still learning the ropes.  :)

As someone who's volunteered to help with editing, a wiki certainly makes it
easier to contribute meaningfully and I hope that whoever steps up as
primary authors will be willing to give it a try.

Sincerely,

- 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, Jan 20, 2011 at 10:04 PM, Peter Saint-Andre wrote:

> 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
>
> On 1/19/11 2:01 PM, Morgaine wrote:
> > The idea of putting this "pre-draft" on a wiki was not mine (the work
> > was started by two other contributors).  I fully support the goal
> > though:  to use a medium where lots of people can have input, even if
> > it's just a single paragraph or just a word correction, so that the
> > initial draft doesn't suffer the problem of inertia while massive
> > changes are afoot.
> >
> > It also overcomes the personalization issue that arises when drafts are
> > tagged officially with a particular person's name.  Since this is being
> > done as a collaborative effort, perhaps it would be fairer if some
> > impartial party tags this initial draft of the "new" Intro instead.
> > We've suffered somewhat with draft personalization issues in the past.
> >
> > Be that as it may, we have much work ahead of us to make this Intro a
> > document that reflects the group's rough consensus of aspirations on
> > interop, even for an initial draft.  We need more people to contribute
> > some typing time.  Those who found the current draft lacking in respect
> > of interop, this is your chance for change. :-)
> >
> >
> > Morgaine.
> >
> >
> >
> >
> > ===========================
> >
> > On Wed, Jan 19, 2011 at 8: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.
> >
> >     Barry
> >
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

--0016e64808ba0a72d5049a53d989
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Thanks Peter! =A0I didn't realize IETF offered a wiki for the group'=
;s use when I suggested using the wikispaces platform - so I'll apologi=
ze for that. =A0This is my first time participating and I'm still learn=
ing the ropes. =A0:)


As someone who's volunteered to help with editing, a wik=
i certainly makes it easier to contribute meaningfully and I hope that whoe=
ver steps up as primary authors will be willing to give it a try. =A0



Sincerely,

- Chris/Fleep
=



Chris M. Collins (SL: Fleep Tuque)
=

Project Manager, UC Second Life=A0
Second Life Ambassador, O=
hio Learning Network=A0


UCit Instructional & Research Computing
University of Ci=
ncinnati=A0
406E Zimmer Hall
PO Box 210088
Ci=
ncinnati, OH 45221-0088
(513)556-3018








On Thu, Jan 20, 2011=
 at 10:04 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

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. &quo=
t;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 wa=
nt 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




On 1/19/11 2:01 PM, Morgaine wrote:

> The idea of putting this "pre-draft" on a wiki was not mine =
(the work

> was started by two other contributors). =A0I fully support the goal
> though: =A0to use a medium where lots of people can have input, even i=
f

> it's just a single paragraph or just a word correction, so that th=
e

> initial draft doesn't suffer the problem of inertia while massive<=
br>
> changes are afoot.

>

> It also overcomes the personalization issue that arises when drafts ar=
e

> tagged officially with a particular person's name. =A0Since this i=
s being

> done as a collaborative effort, perhaps it would be fairer if some

> impartial party tags this initial draft of the "new" Intro i=
nstead.

> We've suffered somewhat with draft personalization issues in the p=
ast.

>

> Be that as it may, we have much work ahead of us to make this Intro a<=
br>
> document that reflects the group's rough consensus of aspirations =
on

> interop, even for an initial draft. =A0We need more people to contribu=
te

> some typing time. =A0Those who found the current draft lacking in resp=
ect

> of interop, this is your chance for change. :-)

>

>

> 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, Jan 19, 2011 at 8:15 PM, Barry Leiba <barryleiba@computer.org


> <mailto:barryleiba@computer.org>> wrote:

>

> =A0 =A0 > As for timescales, we already started work on a new Intro=
 in

> =A0 =A0 October and

> =A0 =A0 > November, as I described in my first email in this thread=
. =A0It was

> =A0 =A0 being

> =A0 =A0 > done informally, not as an official draft but as input to=
 a

> =A0 =A0 totally new

> =A0 =A0 > draft. =A0It was not being done as a revision because the=
 previous Intro

> =A0 =A0 > simply did not meet key requirements for many contributor=
s, as was

> =A0 =A0 clear

> =A0 =A0 > from the group's very intense discussions of Septembe=
r.

>

> =A0 =A0 Can you see if you can get it into reasonable shape to introdu=
ce

> =A0 =A0 publicly, and then submit it as draft-morgaine-vwrap-intro-00 =
? =A0That

> =A0 =A0 would give people something concrete to work from.

>

> =A0 =A0 Barry

>





_______________________________________________

vwrap mailing list

vwrap@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/vwrap





--0016e64808ba0a72d5049a53d989--

From morgaine.dinova@googlemail.com  Fri Jan 21 07:09: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 93D133A69FF for ; Fri, 21 Jan 2011 07:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.878
X-Spam-Level: 
X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=0.098,  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 LhQsjv8PVHw2 for ; Fri, 21 Jan 2011 07:09:01 -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 E308A3A6A05 for ; Fri, 21 Jan 2011 07:09:00 -0800 (PST)
Received: by qwi2 with SMTP id 2so1999157qwi.31 for ; Fri, 21 Jan 2011 07:11:46 -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=4CT8DivqRTQpi5Sz8ESa4xc9fVJv6rKQybTo3iqga8A=; b=MCKb0RvjaN/eonbIzLkRZjIia1ej2W030GFsD1N0is3x/WHVoqJoPh+YFalXEjxpmX s+aHWqTefEXyp31Lwy6/gnASH1d9i6hw/SXrLFuk+QN3whV/cSGO0eLwpUcYwSKbJ2J4 lYWDJ/JpHsp1sNf3LR5uS1nhppC4W1EyZjC6M=
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=opLlk48oYPH5diG9wGa20fe6VmAE/TpTxfFPHzatV0FLyNQGLcFgnMVUi9yy/YrLS7 6XvIX0GMrJBD42ywFrW3H/hv31U6zXlZJ4aJSQN8+NZyVLjvSBsGjMPvj6SJtawDfp2B KpfpIblHd+YeLrHisNhJBrMyEQ8074PRWzjM8=
MIME-Version: 1.0
Received: by 10.229.231.21 with SMTP id jo21mr687556qcb.119.1295622706474; Fri, 21 Jan 2011 07:11:46 -0800 (PST)
Received: by 10.229.225.81 with HTTP; Fri, 21 Jan 2011 07:11:46 -0800 (PST)
In-Reply-To: <4D38F7B0.4090506@stpeter.im>
References:  <4D30F6FE.4020805@ics.uci.edu>             <4D38F7B0.4090506@stpeter.im>
Date: Fri, 21 Jan 2011 15:11:46 +0000
Message-ID: 
From: Morgaine 
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016e686cd6c2eaf34049a5cab57
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, 21 Jan 2011 15:09:02 -0000

--0016e686cd6c2eaf34049a5cab57
Content-Type: text/plain; charset=ISO-8859-1

Good advice there, thank you Peter.

I've made myself a login at the IETF wiki and am currently playing with
markup in Trac's sandbox.  It seems very simple indeed, and clearly takes
markup ideas from MediaWiki which is so very widely known.

Where would pre-drafts, outlines, and other auxiliary /  temporary documents
go in the IETF wiki space?  (I haven't found a guidelines or best practices
page on IETF wiki use yet, but will keep looking.)


Morgaine.




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

On Fri, Jan 21, 2011 at 3:04 AM, Peter Saint-Andre wrote:

> 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
>
> On 1/19/11 2:01 PM, Morgaine wrote:
> > The idea of putting this "pre-draft" on a wiki was not mine (the work
> > was started by two other contributors).  I fully support the goal
> > though:  to use a medium where lots of people can have input, even if
> > it's just a single paragraph or just a word correction, so that the
> > initial draft doesn't suffer the problem of inertia while massive
> > changes are afoot.
> >
> > It also overcomes the personalization issue that arises when drafts are
> > tagged officially with a particular person's name.  Since this is being
> > done as a collaborative effort, perhaps it would be fairer if some
> > impartial party tags this initial draft of the "new" Intro instead.
> > We've suffered somewhat with draft personalization issues in the past.
> >
> > Be that as it may, we have much work ahead of us to make this Intro a
> > document that reflects the group's rough consensus of aspirations on
> > interop, even for an initial draft.  We need more people to contribute
> > some typing time.  Those who found the current draft lacking in respect
> > of interop, this is your chance for change. :-)
> >
> >
> > Morgaine.
> >
> >
> >
> >
> > ===========================
> >
> > On Wed, Jan 19, 2011 at 8: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.
> >
> >     Barry
> >
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

--0016e686cd6c2eaf34049a5cab57
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Good advice there, thank you Peter.

I've made myself a login at =
the IETF wiki and am currently playing with markup in Trac's sandbox.=
=A0 It seems very simple indeed, and clearly takes markup ideas from MediaW=
iki which is so very widely known.


Where would pre-drafts, outlines, and other auxiliary /=A0 temporary do=
cuments go in the IETF wiki space?=A0 (I haven't found a guidelines or =
best practices page on IETF wiki use yet, but will keep looking.)


Morgaine.




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

On Fri, Jan 21, 201=
1 at 3:04 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:


With my area dire=
ctor 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. &quo=
t;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 wa=
nt 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




On 1/19/11 2:01 PM, Morgaine wrote:

> The idea of putting this "pre-draft" on a wiki was not mine =
(the work

> was started by two other contributors). =A0I fully support the goal
> though: =A0to use a medium where lots of people can have input, even i=
f

> it's just a single paragraph or just a word correction, so that th=
e

> initial draft doesn't suffer the problem of inertia while massive<=
br>
> changes are afoot.

>

> It also overcomes the personalization issue that arises when drafts ar=
e

> tagged officially with a particular person's name. =A0Since this i=
s being

> done as a collaborative effort, perhaps it would be fairer if some

> impartial party tags this initial draft of the "new" Intro i=
nstead.

> We've suffered somewhat with draft personalization issues in the p=
ast.

>

> Be that as it may, we have much work ahead of us to make this Intro a<=
br>
> document that reflects the group's rough consensus of aspirations =
on

> interop, even for an initial draft. =A0We need more people to contribu=
te

> some typing time. =A0Those who found the current draft lacking in resp=
ect

> of interop, this is your chance for change. :-)

>

>

> 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, Jan 19, 2011 at 8:15 PM, Barry Leiba <barryleiba@computer.org


> <mailto:barryleiba@computer.org>> wrote:

>

> =A0 =A0 > As for timescales, we already started work on a new Intro=
 in

> =A0 =A0 October and

> =A0 =A0 > November, as I described in my first email in this thread=
. =A0It was

> =A0 =A0 being

> =A0 =A0 > done informally, not as an official draft but as input to=
 a

> =A0 =A0 totally new

> =A0 =A0 > draft. =A0It was not being done as a revision because the=
 previous Intro

> =A0 =A0 > simply did not meet key requirements for many contributor=
s, as was

> =A0 =A0 clear

> =A0 =A0 > from the group's very intense discussions of Septembe=
r.

>

> =A0 =A0 Can you see if you can get it into reasonable shape to introdu=
ce

> =A0 =A0 publicly, and then submit it as draft-morgaine-vwrap-intro-00 =
? =A0That

> =A0 =A0 would give people something concrete to work from.

>

> =A0 =A0 Barry

>





_______________________________________________

vwrap mailing list

vwrap@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/vwrap





--0016e686cd6c2eaf34049a5cab57--

From billwindwalker@rocketmail.com  Sat Jan 29 13:25: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 471BE3A680E for ; Sat, 29 Jan 2011 13:25:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level: 
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 e73Gwu+FoDfm for ; Sat, 29 Jan 2011 13:25:09 -0800 (PST)
Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by core3.amsl.com (Postfix) with SMTP id 36E243A67D9 for ; Sat, 29 Jan 2011 13:25:09 -0800 (PST)
Received: from [98.139.91.68] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jan 2011 21:28:16 -0000
Received: from [98.139.91.15] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 29 Jan 2011 21:28:16 -0000
Received: from [127.0.0.1] by omp1015.mail.sp2.yahoo.com with NNFMP; 29 Jan 2011 21:28:16 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 700377.63221.bm@omp1015.mail.sp2.yahoo.com
Received: (qmail 61679 invoked by uid 60001); 29 Jan 2011 21:28:16 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rocketmail.com; s=s1024; t=1296336496; bh=WXYJQCK3NqbdUNCzGJYg1jjmPhawlY1pAaWsGX8gAUk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=hbwlImHDZJb6K5lSe7l18HLTXaXOYf9hbs1m7ircov05wYBd/WagzEZB4rMCfKHA5+YQm6J/jb1q81mUhtrOVh3H0wbQKyrAuH6/Q7HVZYcTWcVmGTOpz/dAi5isz7qo2yzJC6OaRr7GUBFjqn0/o3kE4fOSjuirzKLlbZTgGmY=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rocketmail.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=tcQTCuCkKypYa77o37TdQD3MybisF81pUYRB4/rnMzM6Pf44R0uI5pCUpeLl2/mE+QDhc+UE04IAmJw8ZV1ULPZqKyhRPfe+Z1d8LrkwDe5m0ql0+BWhxPl5ZGToTqHYDqYPf+ElCMbOn8DldW1wooP4Qw/uO9JGWHxTE2ruhTA=;
Message-ID: <191005.53629.qm@web111203.mail.gq1.yahoo.com>
X-YMail-OSG: 7qtxMvEVM1lVveJJEHmgPj8MMHMByCaB9wY.LeLcciPGw2O kbaWlt6gAsu2OxUzAgIxj97Fow6NnEYVMzmNUG3RaM7VcFj2H3n.G4n_HL48 Q15UL2VQEQiO16voCqy0MUKu6ctzQeTP_u4KwIppg0IShfB8tJkmdBf.M_eE GeBsC68jxpCfHe051zE7opfE71ubMT2cqR7BHCEB.7mfG7yLB.c9TTlfofnE 8MRUflOxi_lFPMhV4MIbWeXc8mB11yTGTs.0bNdgx6nJVaCa7LRnuf1NzFp. GpEAYOlRuQFmKmk4iuYl7YosZ1fA3IMem5FB40gWGjRsz3IawRAUfxkga
Received: from [75.13.69.193] by web111203.mail.gq1.yahoo.com via HTTP; Sat, 29 Jan 2011 13:28:16 PST
X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.107.285259
References: <4D349E0E.3070101@cox.net>
Date: Sat, 29 Jan 2011 13:28:16 -0800 (PST)
From: Bill Windwalker 
To: vwrap@ietf.org
In-Reply-To: <4D349E0E.3070101@cox.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-991099167-1296336496=:53629"
Subject: [vwrap]  AW Groupies
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, 29 Jan 2011 21:25:11 -0000

--0-991099167-1296336496=:53629
Content-Type: text/plain; charset=us-ascii

Greetings AW group you did know me as xstorm Radek.
My wife Patty1 and I have been gone from second life for some time not only do 
to poor support but other problems.
We moved to Opensim and now have 16 of our own sims and have found less 
problems.
I have seen some great steps taken at last in sl from what im reading but see a 
larger number of problems the user will be facing.
When people start  to use mesh more it seems there will be more problems with 
people importing other peoples and companys mesh work in  to sl.
plus i feel its just as impotent to keep in mind that Opensim is growing in many 
ways and may even help the  dev work of SL.
yes there is the same copybot problems in opensim so building better standard 
for people running them will take time.
but i feel unless SL finds a way to let some content in and out of SL it will be 
shut off from the rest of  the world in time.
I do know not many ever did wish to hear from me at the meetings but i feel it 
was time to say some thing even if it seems wrong.

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



      
--0-991099167-1296336496=:53629
Content-Type: text/html; charset=us-ascii


Greetings AW group you did know me as xstorm Radek.
My wife Patty1 and I have been gone from second life for some time not only do to poor support but other problems.
We moved to Opensim and now have 16 of our own sims and have found less problems.
I have seen some great steps taken at last in sl from what im reading but see a larger number of problems the user will be facing.
When people start  to use mesh more it seems there will be more problems with people importing other peoples and companys mesh work in  to sl.
plus i feel its just as impotent to keep in mind that Opensim is growing in many ways and may even help the  dev work of SL.
yes there is the same copybot problems in opensim so building better standard for people running them will take time.
but i
 feel unless SL finds a way to let some content in and out of SL it will be shut off from the rest of  the world in time.
I do know not many ever did wish to hear from me at the meetings but i feel it was time to say some thing even if it seems wrong.
_______________________________________________
vwrap mailing list
vwrap@ietf.org
https://www.ietf.org/mailman/listinfo/vwrap





      
--0-991099167-1296336496=:53629--