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

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

This morning I promised a revised version of Parama's proposed introduction,
this time tweaking due to Thomas' comments. Again, the phrase in question begins
with "To be rigorous..."...John

----------------------------------

This document further elaborates on the scope of the RLTC by listing positive
requirements for various aspects (core, standard extension, and governance) of
the RLTC.

While the charter of the RLTC is written in words that are meant to draw upon
terminology and concepts represented in existing bodies of work in the
marketplace, the requirements document is intended to stand alone and uses
colloquially accepted terminology.  Thus, in this document we use the colloquial
words equivalent to the marketplace concept of rights: permissions granted by
one entity to another.

To be rigorous, by 'permissions' we refer to a set of usage rules applicable to,
for example, one or more objects or services; these rules may be used by a
compliant interpreter to control a user's access to and usage of those objects
or services. The 'user' in this case might be a human or a hardware or software
component.

As such, the technical work of the RLTC is *not* directed to

* Develop specific terms that will be used to write expressions that are
pertinent to some domain such as

 * Specific usage permissions and conditions specifically for content and
 * Specific usage permissions and conditions specifically for other types of
resources.

* Develop a language or system that addresses legal rights and processes.
Examples of these rights include, but are not limited to, those legal rights
termed as "fair use rights" and contractual rights.
* Develop expressions of specific policies (such as "every e-book can be copied
once" or "any doctor may review his patients' records").
* Develop a language or system that addresses other functions that may or may
not be necessary in the bilateral communication between componentry. Examples of
these functions include, but are not limited to, messaging, querying, and
negotiation between componentry. As such, the technical work of the RLTC is not
concerned with

 * Defining a means for expressing exercises of permissions.
 * Defining a means for expressing preferences regarding automated exercise of
permissions.
 * Defining a means for expressing the desire to receive permissions.
 * Defining a means for expressing the desire to exercise permissions.

* Define a DRM system standard nor a road map for the creation of a collection
of DRM system standards nor any other component that may be required in a DRM
system such as

 * Encryption, or any other means for limiting the use of a resource and
 * Resource identification and trust model prescription, or any other means for
determining the legal authority to originate permissions.

While the language that is standardized by this committee may be expressive
enough to express policy associated with the aforementioned areas within the
appropriate contexts of the problem addressed, the scope of this committee is
not to solve the bigger problem. The work product of this technical committee
will be one component of a larger ecosystem of componentry and workflows that
will address those issues that are not addressed by this technical committee
itself.


| John S. Erickson, Ph.D.
| Hewlett-Packard Laboratories
| PO Box 1158, Norwich, Vermont USA 05055
| 802-649-1683 (vox) 802-371-9796 (cell) 802-649-1695 (fax)
| john_erickson@hpl.hp.com         AIM/YIM/MSN: olyerickson