Re: [mmox] Permissions (Gareth Nelson)

Gareth Nelson <gareth@litesim.com> Tue, 24 February 2009 07:59 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 9103A3A69E9 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:59:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.86
X-Spam-Level:
X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.117, 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 5a1MMseJyHKf for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 23:59:30 -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 CD2D53A67D1 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:59:27 -0800 (PST)
Received: by po-out-1718.google.com with SMTP id b23so7552709poe.4 for <mmox@ietf.org>; Mon, 23 Feb 2009 23:59:45 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.62.9 with SMTP id p9mr2460670rvk.80.1235462385372; Mon, 23 Feb 2009 23:59:45 -0800 (PST)
In-Reply-To: <49A3A66F.2000004@gmail.com>
References: <27a487810902231225l6698b519rdc6f1d53ba215024@mail.gmail.com> <61dbdd7d0902232240v7be93f0dpd6310ecd7db0902a@mail.gmail.com> <49A3A66F.2000004@gmail.com>
Date: Tue, 24 Feb 2009 07:59:45 +0000
Message-ID: <61dbdd7d0902232359u13ae8a0bqfee5e64ff8366699@mail.gmail.com>
From: Gareth Nelson <gareth@litesim.com>
To: Jon Watte <jwatte@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
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:59:31 -0000

"Strong DRM" of the kind that involves silly schemes such as sending
the content in an encrypted form AND the encryption key should not be
part of any standard. "Machine-readable licenses" are a reasonable
thing, and this can all be lumped into a field in the metadata.

On Tue, Feb 24, 2009 at 7:49 AM, Jon Watte <jwatte@gmail.com> wrote:
> 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
>
>