Re: [mmox] mmox Digest, Vol 1, Issue 111

Gareth Nelson <gareth@litesim.com> Mon, 23 February 2009 15:58 UTC

Return-Path: <gareth@litesim.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 985773A6932 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 07:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 TireFYgACCUR for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 07:58:51 -0800 (PST)
Received: from po-out-1718.google.com (po-out-1718.google.com [72.14.252.154]) by core3.amsl.com (Postfix) with ESMTP id AC7983A67CC for <mmox@ietf.org>; Mon, 23 Feb 2009 07:58:51 -0800 (PST)
Received: by po-out-1718.google.com with SMTP id b23so6733073poe.4 for <mmox@ietf.org>; Mon, 23 Feb 2009 07:59:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.28.2 with SMTP id f2mr2090724rvj.217.1235404748255; Mon, 23 Feb 2009 07:59:08 -0800 (PST)
In-Reply-To: <20090223.093658.9303.0@webmail05.vgs.untd.com>
References: <20090223.093658.9303.0@webmail05.vgs.untd.com>
Date: Mon, 23 Feb 2009 15:59:08 +0000
Message-ID: <61dbdd7d0902230759p304526deq8af398e10ea9c4b0@mail.gmail.com>
From: Gareth Nelson <gareth@litesim.com>
To: "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mmox@ietf.org
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111
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 15:58:52 -0000

For someone talking about choice so much you seem very preconcerned
with mandating what choices VW providers make. Nothing wrong with
putting a field in the asset metadata for permissions stuff, but it
definitely should NOT be a mandatory part of the standard.

On Mon, Feb 23, 2009 at 2:36 PM, dyerbrookme@juno.com
<dyerbrookme@juno.com> wrote:
>>Trustworthiness of a given grid is better left to the full
> appreciation of the grid caretaker because there is no way to make an
> automatic validation of the DRM implementation in some distant machine
> (but that's really the most basic reason of all), so the entire debate
> about what constitutes a trusted grid or not WRT copyright is out of
> scope.
>
> Well, there's lots of things you can't reach out and confirm on a remote machine, but hey, interoperability isn't an extension of the Wild West, is it? It should be a regime of standards, not un-standards. If there wasn't the allergy to DRM in advance as something evil music companies impose on people who want to rip music for a variety of their gadgets or friends, then there might be more breadth of perception about this matter and the need for *diversity and choice*.
>
> DRM implementation may well be the basis for a system to determine trustworthyness. Why not? Nothing but ideology to stop you there.
>
>>I actually wrote that mandating the implementation of DRM on top of
> any permission/copyright metadata transmission mechanism would severly
> reduce the number of grid systems that comply with the protocol.
>
> No, you said not to stream the permission at all, that it would take up resources, that it shouldn't be streamed if you can't mandate DRM within the streaming process. Why not let that be up to the participating grids that want to mandate DRM? Why preclude that option from them at the dawn of interoperability among virtual worlds? Again, no reason, but an ideological one.
>
>>I earn significant money from making full-perm content in Second Life,
> so these assertions sound empty to me. I'm also a fiercely
> individualistic capitalist (of the jusnaturalist kind), but you do not
> have to believe me.
>
> Again, this is an *ideology* and a belief about *a* type of commerce but isn't a scientific fact for all types of commerce just because they are e-commerce. E-commerce doesn't become opensource e-collectivism just because you say so. The e-commerce in interoperable virtuals worlds shouldn't be hobbled in advance because of some ardent ideological belief in Kevin Kelly's "8 Generatives" as the only option for digital content. Someone "making their living off full-perm items" is a) making a living off "obfuscation," i.e. the script or code or item is so complex, that it needs to have consulting services sold on top of it, even if it is "free and open source" or b) making a living from customization which is very much of a niche market and cannot be conceived as a solution for all commerce or c) putting out a tip jar. CC is basically the putting out of a tip jar at best, and a collectivist induced share at worst. It's not a robust permissions regime with copyright enabled for co
>  mmerce on the basis of original continent, which should definitely be a choice in advance for the metaverse, not precluded, and not merely added on as a module.
>
>
> ____________________________________________________________
> Need cash? Click to get a cash advance.
> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTFRKCJy0PLklxCTx1v0QHf147OxPFPhZM7jLy0Btr8dokukPABky8/
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>