Re: [rights-requirements] Introduction to the Requirements Document

[John Erickson <john_erickson@hplb.hpl.hp.com>]

Thomas wrote:

> ...Where it says "object or service" we should include
> the plural case as well.  For instance, one "rule" could
> be applicable to *several* objects or services...

JSE: Yup, that's fine.

> ...Also, I'm not sure "object" and "service" are broad
> enough to capture all kinds of resources.  What about a
> computer game "special move", would this be classified as
> an "object"?  Maybe the fix for both of these is as simple
> as adding a "for example" in the sentence, so it'd read
> something like "by 'permissions' we refer to, for example,
> a set of usage rules...".  Does that work?...

JSE: Yup, I think that inserting "for example" where you suggest is probably
good. Revised version to follow...

> ...The words "usage rules" don't really clarify much for me.
> They seem to be as overloaded in interpretation as the word
> "rights".  In particular circles, "usage rules" means one
> thing, but in other circles it means other things.  In colloquial
> usage, it doesn't really mean anything.  You know, I go to a
> party and someone asks what I do and (sadly :-) I start talking
> about "usage rules" and they are all clueless.  But they do
> have a pretty good grasp at "permissions".  So, personally, I
> have a hard time seeing how describing "permissions" as "usage
> rules" helps any -- in fact it adds confusion for me...

JSE: This is a legitimate concern. My reasoning was to try to be more specific
regarding "permissions." Since starting with the DRM stuff in '94, one thing
I've come to expect is that there will differences between what a copyright
person and a coder think of as a "permission." The fact is, within the scope of
this TC we mean something more specific than a textual expression of "legal"
capability --- we mean an expression whose interpretation will lead to a
deterministic control of use on some target component.

I wrote the following to Hari and Parama yesterday, which may or may not be of
use...

"...In the abstract (therefore ignoring encryption) we can think of a "control
set" (the rules) and a "virtual machine" charged with interpreting the control
set. Loosely, one might first think of this VM as the "DRM Client," but under
closer examination its clear that this isn't accurate; the rule-enforcing VM
must be (located) where the uses are implemented, which in most worlds is
(buried) within the application. This will remain true until we migrate to a
content-centric view (or, arguably, an object-oreinted view) of the content
universe, in which applications abdictate the job of content handling (and rules
enforcement) to protected local repositories that present uniform interfaces to
applications. Until then, "DRM clients" can at most validate rules, and perhaps
do other useful things like authenticating components, etc.

"The language doesn't (or shouldn't) need speak to anything more specific than
this abstract view. The reality is that rules are written, rules are
interpreted, rules are enforced; all of this is done to control access to object
behaviors. An actual implementation of a "VM" might be split --- for example, an
XrML expression might be "interpreted" external to an application, with the
actual "control" achieved through some other proprietary (perhaps binary)
syntax, or the XrML might be "compiled" to some binary and transmitted, with a
similar result --- but it is all with the same logical result: The rules are
meant to control use of the object in a deterministic way..."

> ...That said, I only offer this up for discussion.  If I'm the
> only one that this doesn't help, I'm willing to just accept
> that the definition of "usage rules" is what I understand "permissions"
> to be so that we can move forward.  But I do ask that people first
> validate that they really think they are helping by introducing
> this concept of "usage rules" or if we just end up being overly-
> exact when "permissions" was already exact as far as everyone was
> concerned?  Or, more to the point, I think the proposed addition
> would be great if someone actually misunderstands "permissions",
> so my question is "is that the case?"

JSE: Regarding potential misunderstandings, I suggest that (at least) in this
case being more exact would be useful --- as we have discussed in our
Requirements meetings. For example, consider a future case in which a particular
community, interested in "rights management," is looking for a "rights language"
to use as a basis for a protocol for handling "upstream" rights transactions.
They say "hey, what's this 'rights expression language' from OASIS?"

Instead of being confused, they read the (proposed) Introduction and see that it
is about expressing grants of permission, and those 'permissions' are usage
rules enforced by rendering engines, creativity tools, web service components,
games, etc. This is not what they want --- they are instead interested in rights
transactions in the abstract (more of an e-contracting protocol). So they move
on.

John