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/ >
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] the arguments are sidelining people... Kajikawa Jeremy
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Gareth Nelson
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jon Watte
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Kajikawa Jeremy
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Kajikawa Jeremy