[rights] [rights-requirements] Some thoughts on "Core" requirements

["M. Paramasivam" <parama@microsoft.com>]

From listening to the requirements calls it appears to me that there is some fundamental confusion between the REL’s ability to express a wide variety of policies and tailoring the REL toward a variety of policies of specific interest (e.g., discussions about fair use/copy/backup copy etc.). I believe that the former is what we should use to drive our definition of the core. And I also believe that were it not for the need to express the latter policies, there would be no RLTC. So I am certainly not diminishing the importance of the latter. 

 

One source of this confusion is the use of the word "core" to refer to architecturally central requirements. Somehow there seems to be a general belief that the "core" refers to something of "greater" importance. And that core requirements therefore are requirements that are most important. Perhaps we should use the word "key" to emphasize important requirements such as "must be able to express the needs of the content industry" or "must be able to express fair use" etc. from "core" requirements, which speak to the architectural expressiveness provided by the REL (e.g., "must be able to assign any right to any principal", "must be able to attach different conditions for different rights" etc.). 

 

An analogy I like to use is the "C" programming language. The ability to do I/O is a "key" requirement. However the BNF for "C" does not include the keywords “printf” or “scanf”; these come from external libraries. What "C" provides is "core" substance for different implementations of the language to support this.

 

Note that this is not unique to “C” either. The Java programming language does not incorporate a seemingly fundamental requirement like I/O into the core language either. This is just good language design practice. The core is meant to address expressivity; specific constructs that do not contribute to expressivity live outside the core. No matter how widely needed they are. No matter how widespread their anticipated use is.

 

Now one may believe that rights are somehow different and that they arrive from social consensus etc. But this all speaks to specific policies themselves. What is indisputable is this: Any rights language expression will ultimately be consumed by a machine. Therefore the design of rights languages warrants the same architectural treatment that is considered good practice in language design.

 

Let us play with some examples here. In the core, we may (or we may not, but please bear with me a bit) think about principals, rights, resources, conditions (and possibly other items) in the abstract. A principal being someone to whom the right is conferred over some resource under certain conditions. We decide how such concepts interplay in the core, and that decision will reflect upon every context where such concepts are applicable. 

 

For example, we may decide that it must be possible for the rights language to allow expressions such as “a principal is allowed the right to a certain category of resources under certain conditions”. 

 

Now allowing this kind of expression in a general sense permits a specific expression such as “Alice is allowed to extract ten pages from any book that she paid for, provided she does not use the extracted pages for commercial purposes”. 

 

It also permits the expression “Alice is allowed to view movies from the Sony library provided she’s a member of the Sony club”. 

 

Notice that both these examples conform to our sample core expression. “Alice” is an example of a  principal; “extract” and “view” are examples of rights; “books” and “movies” are both examples of a category of resources; and “a limit of 10 pages”, “book was paid for by Alice”, “not used for commercial purposes”, “member of Sony club” are all examples of conditions.  Needless to say, the number of such examples that conform to our sample core expression is limitless.

 

It is also worth calling out that we in the TC cannot realistically anticipate all usage examples of principals, rights, resources and conditions, and put them in the core. What we can do is provide some way by which people, who wish to use our deliverable, can define their own examples of principals and rights and resources and conditions.

 

I also believe that the TC will identify certain key common usage scenarios and the standard will address those requirements as well but not necessarily in the core.

 

We use the core to decide what kind of expressions must be specifiable in our language in some abstract sense. We then arrive at a common understanding toward what such expressions should mean to a computer. Ultimately that is the meaning that needs to be encoded in a program. The program can then consume the rights expression and make the intended enforcement decisions accordingly.

 

Thanks

--Parama