[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [rights-requirements] Introduction to the Requirements Document
As discussed, here is the "tweaked" version of Parama's proposed introduction, based upon his email version. The added phrase 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 some object or service, that may used by a compliant interpreter to control a user's access to and usage of the object or service. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC