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

"dyerbrookme@juno.com" <dyerbrookme@juno.com> Mon, 23 February 2009 23:42 UTC

Return-Path: <dyerbrookme@juno.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 F099D28C209 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 15:42:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level:
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 1ThAPQcCodg3 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 15:42:57 -0800 (PST)
Received: from outbound-mail.vgs.untd.com (outbound-mail.vgs.untd.com [64.136.55.15]) by core3.amsl.com (Postfix) with SMTP id 7434C28C228 for <mmox@ietf.org>; Mon, 23 Feb 2009 15:42:57 -0800 (PST)
X-UOL-TAGLINE: true
Received: from outbound-bu1.vgs.untd.com (webmail14.vgs.untd.com [10.181.12.154]) by smtpout06.vgs.untd.com with SMTP id AABE4GPC9AUKZZ32 for <mmox@ietf.org> (sender <dyerbrookme@juno.com>); Mon, 23 Feb 2009 15:42:23 -0800 (PST)
X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucSk4DgBsdYkNT/IJsIGU8sS4m3Yr+Jt6Jg==
Received: (from dyerbrookme@juno.com) by webmail14.vgs.untd.com (jqueuemail) id N95FCB4U; Mon, 23 Feb 2009 15:42:16 PST
Received: from [68.161.198.3] by webmail14.vgs.untd.com with HTTP: Mon, 23 Feb 2009 23:41:32 GMT
X-Originating-IP: [68.161.198.3]
Mime-Version: 1.0
From: "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Date: Mon, 23 Feb 2009 23:41:32 +0000
To: RGehorsam@forterrainc.com
X-Mailer: Webmail Version 4.0
Message-Id: <20090223.184132.16346.0@webmail14.vgs.untd.com>
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Content-Type: text/plain; charset="ISO-8859-1"
X-ContentStamp: 2:2:917333643
X-MAIL-INFO: 2868911c9109694d159c5d159c8505d19c615ca9d1385c5cddf5e9c871dcfc8948c98845c84d155db55d09c988ace925ec898cccf1a1ec1c2c
X-UNTD-Peer-Info: 10.181.12.154|webmail14.vgs.untd.com|outbound-bu1.vgs.untd.com|dyerbrookme@juno.com
Cc: mmox@ietf.org, jwatte@gmail.com, dyerbrookme@juno.com
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113
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 23:42:59 -0000

Once again, just to be clear again: There.com has a central-clearing house for content. That's the point that's relevant here.

The fact that Forterra, which shares a close history with There.com based on the same technology, obviously does not clear its private clients' contents on their private grids shouldn't distract from the point about There.com, where the user does not have that privilege. (http://en.wikipedia.org/wiki/Forterra_Systems_Inc, "There is based on shared technology with Forterra Systems that was initially developed in conjunction with a US Army project.[2] The There service was spun off to Makena Technologies in 2005")

The statement "There/Forterra context" isn't a claim about Forterra not letting its private clients upload content -- I knew that before, and got it again when it was pointed out; I did NOT claim that this company, whose demonstrations I've seen in person at expositions, was somehow clearing its clients' customized content using its software. No. Rather, it's about *how you deal with IP theft* which is either a) central clearance or b) private grid with corporate or government firewall -- solutions that do not involve freedom for the user on a public grid, i.e. open to the public by subscription, and involve a subordinate relationship to a user facing an administrator on a private grid.

None of these correctives and admonishments for alleged "erroneous assumptions" somehow perceived should distract from the point at hand here: There.com has a model for users that involves clearing their content through a central administrator; Forterra's clients have a solution that involves firewalls. Neither should become the sole models for interoperability.

The clearance of content through a central committee in There.com as a way of handling the problem of appropriateness AND the problem of IP control is *one way* to solve the problem of IP protection. It isn't the only one. And it can't work for SL, which already has user content produced spontaneously by the user with the tools, with a regime only of TOS abuse-reporting and DMCA takedowns after the creation. 

That's the point here; the point here isn't somehow to imply that Forterra's customers today somehow clear content through them. That was in fact never said and never implied. In fact what was said that Forterra's evidently customers solve the IP problem *another* way which is through government and corporate firewalls. So unless the project of interoperability is enforcing only two solutions for IP protection -- central clearance OR government/corporate firewalls -- then something still has to be done about c/m/t in the metadata as a permissions system on open grids where the public openly creates.





____________________________________________________________
Grow your small business with email marketing. Click Now.
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEFeRJRL0sMzeN5pbUzb9jWg2LQGMLBWGV9hzwV7QK2vMlskIm788/