Re: [mmox] Permissions (Gareth Nelson)

Jon Watte <jwatte@gmail.com> Tue, 24 February 2009 07: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 C58A03A69FC for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:48:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 vEw3B6aM5A1L for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:48:50 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id E8D913A67D1 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:48:49 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2203706rvb.49 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:49:07 -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=Optl/lgLaMJclNcx5RbIwbEUSoNpVjb2G0gr6MqT6bg=; b=SiC08Tt4mmCIcK3IuCAUeddv4BBs/k2xbNOFkWd/yjk/hz7/qCOL5s6r3gfDQRAdOq FMSz2knjfjbDhDBd5EX9NN9K4ANwVdvW3QkxzNhtgfkE6JEo6n78p58BD0wGqRcBUBRR iNrOUCSqjqg4r4u+laLE1iaG/BPJ+eZ3pTdtw=
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=FoRJ4eEkNDWnEwTfF88pM+pm8Owa6d14cUMzGP9T5dikLedbq9nuWnRpfTwc+r5+yJ hkTEsqa3F++YRSs7jq+bLHRePzqDkWLfcDLcHcIHQ2WNQo9EJUWVSVarP6KtTAOI+Y4G lzZfSyROVwDhxjz9azdwvuVDieCzxDmXR2CLE=
Received: by 10.140.125.19 with SMTP id x19mr2452107rvc.187.1235461747288; Mon, 23 Feb 2009 23:49:07 -0800 (PST)
Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id b39sm7230343rvf.9.2009.02.23.23.49.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 23:49:05 -0800 (PST)
Message-ID: <49A3A66F.2000004@gmail.com>
Date: Mon, 23 Feb 2009 23:49:03 -0800
From: Jon Watte <jwatte@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Gareth Nelson <gareth@litesim.com>
References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com>
In-Reply-To: <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org, William George <wjgeorge@dceo.rutgers.edu>
Subject: Re: [mmox] Permissions (Gareth Nelson)
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: Tue, 24 Feb 2009 07:48:50 -0000

Gareth Nelson wrote:
> Or you could ignore it. Ask your own sense of ethics and your lawyer
> what the right thing to do is.
>   

I believe that we can, and should, enable the metadata that allows 
service providers to provide strong DRM. This means that the acceptable 
DRM scheme/schemes must be identified in the metadata, and a provider 
can then choose not to provide a resource to some peer that has not 
signed on to that DRM scheme. The actual mechanics of how the service 
verifies that the peer is signed on to that same scheme does not need to 
be treated by the standard; that's up to each DRM provider to figure out.

If we do that, then the DRM worlds and the open worlds will be able to 
compete for the favor of the content creators and the users. Creators 
who don't like the open practices of some open provider, will simply 
gravitate towards the protected practices provided by the protected 
providers, and vice versa.

Meanwhile, I think that the set of bits we've identified 
(view/copy/use/transfer/modify/derive) and the semantics for each bit 
(allow-change, deny, allow-once and allow-always) could and should be 
part of a required minimum schema -- i e, the service providers will 
publish what they attempt to enforce, and incompatible semantics means 
that no transfer of assets happen. That's just common sense.

Note that this doesn't require the open grids to do or understand about 
DRM, or even to protect anything, for the benefit of their users. 
Meanwhile, it allows those who want to operate 
protected-but-interoperable grids to do so, for the benefit of their 
creators. Everybody wins.

Sincerely,

jw