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

Jesrad <jesrad@gmail.com> Mon, 23 February 2009 16:31 UTC

Return-Path: <jesrad@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 9604F3A6802 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 08:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 KEeUbxP7-Ypx for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 08:31:33 -0800 (PST)
Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 3457F3A6A6E for <mmox@ietf.org>; Mon, 23 Feb 2009 08:31:33 -0800 (PST)
Received: by mail-bw0-f161.google.com with SMTP id 5so4923057bwz.13 for <mmox@ietf.org>; Mon, 23 Feb 2009 08:31:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IeWWuFKovXpHE4e1HZHjjnZ8mTVhsVy2DD2M9apwEGI=; b=xar2lwNB+DVRmFdc0VaF+7fEFkdhqe0i58b07/nYF3Dh+2DXFNhg74kLhxpDn2gVv8 +Qt55oU2SWLEJUpoV1dsjTg1mR2Vf6mNy6qAZwCF8YyjpzaV/L1n7xhEhUaChCvR7+qF a5bkjrAMEHgrDKj4muF2awVVlyx+yGutfYvgg=
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=SLReNmh5ztDweJ3xNreyM7o+T/pHkwbeYuN2Vjd6oAszV4bJ8sFaYNoUZXH3xvDQZ2 OzIptox5RTB1HyLLZoKI4wQJ9gHIkGfU5JEs5NSv/vFV0ss/LKdyk+1ediWQIGKuQaCe Z7CUIpIzfeyuhPCD5fvelXOuN0JmbC/MsNU4A=
MIME-Version: 1.0
Received: by 10.181.155.9 with SMTP id h9mr1573128bko.176.1235406711358; Mon, 23 Feb 2009 08:31:51 -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 17:31:51 +0100
Message-ID: <53cd6c2e0902230831i17978c04i34aaacb12e881032@mail.gmail.com>
From: Jesrad <jesrad@gmail.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 16:31:34 -0000

> DRM implementation may well be the basis for a system to determine trustworthyness. Why not?

Because so far the only successful examples of such a trust scheme
require that the software designer also designs and distributes the
hardware to run it on.

To my knowledge there is but one thing you can consistently and
reliably check about a remote machine, it is that of intelligent
behaviour. That's called a Turing test.

> 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.

I run my business on sound economics, not ideology. I've personnally
expanded Austrian Economics to the field of intellectual property then
made an experiment to test this theoretical advance, found positive
results, then made it a successful business (which does not fall into
any of your three caricatural categories).

But that's completely irrelevant debate anyway, since I'm not
advocating the suppression of copyright for people who want to have
it. My model can coexist with copyright-based models, provided I can
opt my content out of any DRM system. One of the reasons I am
participating in this group is to ensure my business model will not be
hindered by the design of the protocol. I believe this is the same
motive as yours.

> 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.

No. Read again: I have said that streaming this data as a specific
data type seperate from others is a waste of resources if any DRM
mechanism is outside of the protocol anyway. That's different.

Without a DRM system for treating this data, it is purely client-side
and as such it's simple content, so it does not merit a specific data
type/stream for itself, just like we do not have two different TCP
implementations for transporting webpages and emails. This is a
technical reason, and I'm growing tired of having to answer empty
accusations of "ideology", especially so when I've been advocating
exactly the same thing as you have initially: that the MMOX group and
the IETF abstain from including this issue at all in the scope of the
protocol and that it be left entirely to the grid hosts to decide
policy on the subject.

> 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?

I have not said that the data should not be transmitted. I have said
that reserving a special data type and/or strem for it seems like a
waste to me because it will not have any relevance to the protocol
mechanism (it will be treated outside of the MMOX-layer).

Then, I got told that it might have a use at the MMOX-layer after all,
for the purpose of automatic filtering of content for cross-grid asset
exchange. And as I have said then, this is a reasonable enough
justification that I won't mind if MMOX includes it.

On Mon, Feb 23, 2009 at 3: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 commerce 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.
>
>
> ____________________________________________________________
> Click for online loan, fast & no lender fee, approval today
> http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTIpd6J6MwHjlxeSewC9y1UQen8TcPpE1mMoHgbrVwXpT9LkppWCC8/
>