Re: [mmox] Permissions

Jon Watte <jwatte@gmail.com> Mon, 23 February 2009 22:48 UTC

Return-Path: <jwatte@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E75C53A69AB for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 14:48:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 0BoNyx9NYg+g for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 14:48:21 -0800 (PST)
Received: from mail-gx0-f174.google.com (mail-gx0-f174.google.com [209.85.217.174]) by core3.amsl.com (Postfix) with ESMTP id D20213A68FE for <mmox@ietf.org>; Mon, 23 Feb 2009 14:48:20 -0800 (PST)
Received: by gxk22 with SMTP id 22so5890350gxk.13 for <mmox@ietf.org>; Mon, 23 Feb 2009 14:48:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=b46+/M/7oBNzoVzDh0zDIoUwY7rnF39ye3R4aWxnjgY=; b=VAfvm80s8vdpHaNOWFFSXf1mgTskTBQ97iJdvLR7qanGZ7MA44M5g7C5D+ztsHquUC juYbgj+50Ao9H1JnW0OJPsw75uc5/k7bZbgo7DOWpZDox14YClX17RhQ3ucVXCExeS28 r5KSXk/GolRd3xfX+9Vd8x84vtoU1STimNADU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=rlD4WbTKDQYDulEmRpUYUD06t6u/Nzwi0UpN2LI/2sR07Y5NcnMvPRNvrJ8szfMh/2 zqf3fEfM+tg3IaFuX7mwYRqyuftX9xzJRqVlbom2LOzLHXCxPwao7ICtR1yIoDNtSz21 qZ0yLnTRZ+YncCJQwnwYhDU4oSRnrRcGRPImA=
Received: by 10.100.207.14 with SMTP id e14mr2365499ang.128.1235429318464; Mon, 23 Feb 2009 14:48:38 -0800 (PST)
Received: from ?192.168.168.111? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c9sm547243ana.53.2009.02.23.14.48.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 14:48:37 -0800 (PST)
Message-ID: <49A327C3.3070903@gmail.com>
Date: Mon, 23 Feb 2009 14:48:35 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Ann Otoole <missannotoole@yahoo.com>
References: <61dbdd7d0902230059u69e87ed3n3a85b905593c11@mail.gmail.com> <53cd6c2e0902230118v12f271a5u2657a358821f4d09@mail.gmail.com> <61dbdd7d0902230131v7d870dc4qb17b14d2b9c8875c@mail.gmail.com> <53cd6c2e0902230210u5de8a5e7o1f589b17d2d3bf97@mail.gmail.com> <61dbdd7d0902230221h66a5deb2w64f551f08c062878@mail.gmail.com> <53cd6c2e0902230227p7d52e84br82b29f16c04c9f70@mail.gmail.com> <61dbdd7d0902230444k359a3576r42f3343ecf5d5d6d@mail.gmail.com> <53cd6c2e0902230532kfcd975akb13e088ae23c4304@mail.gmail.com> <61dbdd7d0902230537n20f86856i8b392a80b1740bc0@mail.gmail.com> <53cd6c2e0902230559g73aa66e3u4026f34b95ec215@mail.gmail.com> <49A2FDB8.7000303@cox.net> <49A31323.8010804@gmail.com> <162490.78744.qm@web59103.mail.re1.yahoo.com>
In-Reply-To: <162490.78744.qm@web59103.mail.re1.yahoo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] Permissions
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 22:48:22 -0000

Ann Otoole wrote:
> "If SL makes it a requirement that at least one SL customer is part of 
> any interoperation scenario involving SL servers, then SL has a 
> revenue stream for each such interoperation scenario."
>
> You forget that there was no requirement established that 
> participation in standards does not require for profit only status 
> sir. Or that sentence of yours was not stated in a sufficiently clear 
> and unambiguous manner. If Kapor/Rosedale wishes to establish interop 
> for non profit activities then Kapor/Rosedale will do so. It is their 
> money.
>

Absolutely! What I'm saying is that, even for people who don't want to 
give away computing time for free, the context of allowing their servers 
to host objects for "owners" who aren't actually customers can still 
make sense. This means that the model is universally applicable to both 
for-profit and for-free service providers.


>
> From the available information I have seen Second Life/Second Life 
> derivitives have the interoperability momentum at the moment. Exactly 
> what public "grid" does Forterra bring to the table anyway? How many 
> simulators is Forterra running in use 24*7?

Forterra does not operate "grids." Forterra licenses technology and 
consulting to organizations who want to operate their own virtual world 
systems, of all different kinds of size and scale (think "dozens" to 
"millions"). We are a privately held company, and do not disclose our 
sales numbers publicly, but I can tell you that the number of OLIVE 
systems in production 24*7 is more than a handful.

Additionally, OLIVE systems have been in use in interoperating virtual 
worlds of various kinds since 2005, which includes displaying avatars 
from other systems and vice versa, so I believe we have a lot of 
beneficial learning to share.

> All it takes to deal with the issue of permissions in general is a 
> commitment to include permissions as a component in the standard, 
> whatever that looks like, and then create a sub committee/list to 
> debate permissions seperately and once consensus is acheived the 
> proposal be brought forth for debate.

It's surprising to me that you seem to try to attack the credibility of 
the company I work for, yet the specific proposals I make on this group 
address exactly the specific requirements you say you want to address, 
in a way that makes them generally acceptable to all kinds of operators 
and all kinds of content creators. If there is some technical problem 
with the proposal I've made, that you believe would not serve the needs 
of some particular kind of content creator or virtual world operator, I 
would like to see that technical deficiency pointed out, so that it can 
be corrected. If not, then I expect you to actually support the specific 
proposal.

Sincerely,

jw