[rights-requirements] Introduction to the Requirements Document

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

As per the action item suggested by Aaron, BobG, Thomas, Martha (and others?) over last week's call, I have attempted to add some introductory text to the requirements document. The purpose is to clarify the scope of the RLTC and the terminology used in the requirements document. Many thanks to Thomas and Hari for their input.

Thanks

--Parama

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

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.

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.