INTERNATIONAL ORGANISATION FOR STANDARDISATION
ORGANISATION INTERNATIONALE DE NORMALISATION
ISO/IEC JTC1/SC29/WG11
CODING OF MOVING PICTURES AND AUDIO

ISO/IEC JTC1/SC29/WG11/N4045
Singapore, March 2001

Title: MPEG-21 Requirements for a Rights Data Dictionary and a Rights Expression 
Language
Source: Requirements 
Status: Draft v0.7

1	INTRODUCTION	4

2.	REQUIREMENTS FOR A RIGHTS DATA DICTIONARY AND A RIGHTS
	EXPRESSION LANGUAGE	6

2.1	Modeling and Principles to support RDD-REL	6
2.1.1	Extensible Model	7
2.1.2	Articulation of Roles	8
2.1.3	Standard Identification Systems	8
2.1.4	Creation Types	8
2.1.5	Support Digital Item Usage/Business Models	8
2.1.6	Interoperability	9
2.1.7	Lifecycle of Digital Items	9
2.1.8	Permission by Contract	9
2.1.9	Definition of Terms	10
2.1.10	Modeling of Dictionary Terms	10
2.1.11	Constraint Terms	10
2.1.12	Narrowing of  Rights	11
2.1.13	Exclusive Rights	11
2.1.14	Exceptions of Rights	11
2.1.15	Accessibility	11
2.1.16	Expressiveness	12
2.1.17	Machine Readable Language	12
2.1.18	Usability	13
2.1.19	Extensibility	13
2.1.20	Customisability	13
2.1.21	Interoperability	14
2.1.22	Identification and Metadata of Rights Expressions	14
2.1.23	Authentication of Rights Expressions	14
2.1.24	Written in Open, Standard Meta-Language	15
2.1.25	Well-Defined Semantics	15
2.1.26	Coordination	15
2.1.27	Efficient Implementation, Test and Evaluation	16
2.1.28	Administrative Information	16
2.2	Digital Item Requirements	16
2.2.1	Digital Item Identification	16
2.2.2	Digital Item Metadata	17
2.2.3	Composite Digital Item	17
2.2.4	Digital Item Collections	18
2.2.5	Digital Item Authentication	18
2.2.6	Digital Item Protection	18
2.2.7	Digital Item Availability	19
2.3	Usage Rights Element Semantics	19
2.3.1	Specification of Usage Rights	19
2.3.2	Categorization of Rights	19
2.3.3	Transport Rights	20
2.3.4	Render Rights	21
2.3.5	Derivative Work Rights	21
2.3.6	File Management Rights	22
2.3.7	Configuration Rights	24
2.3.8	Adding New Rights	24
2.3.9	Changing Rights	25
2.4	Conditions	25
2.4.1	Time Based Usage	25
2.4.2	Count Based Usage	26
2.4.3	Fee Based Usage	27
2.4.4	Access Control Based Usage	28
2.4.5	Territory Based Usage	29
2.4.6	Portion Based Usage	29
2.4.7	Mixed Conditions Based Usage	29
2.4.8	Specification of Conditions Common to Different Rights	29
2.4.9	Changing Conditions	30
2.5	Obligations	30
2.5.1	Specification of Obligations	30
2.5.2	Usage Tracking	30
2.5.3	Watermarking	31
2.5.4	Specification of Obligations Common to Different Rights	31
2.6	Usage and Business Models	32
2.6.1	Support Multiple Usage/Business Models	32
2.6.2	Unlimited usage (Pay an Upfront Fee)	32
2.6.3	Limited usage	32
2.6.4	Preview or Promotional Models	33
2.6.5	Tiered Models	33
2.6.6	Pay Per View or Use	33
2.6.7	Subscription	33
2.6.8	Territory Restricted	34
2.6.9	Component Based Model	34
2.6.10	User Types Based Model	34
2.6.11	Site Licensing	34
2.6.12	Personal Lending	34
2.6.13	Giving	35
2.6.14	Institutional Lending	35
2.6.15	Superdistribution	35
2.6.16	Distributor Copies	35
2.6.17	Personal Copies	36
2.6.18	Nested Revenue Model	36
ANNEX A - MPEG-21 TERMS (INFORMATIVE)	37
ANNEX B - THE TABLE OF RESPONSES TO THE CFR (INFORMATIVE)	37
ANNEX C - THE TABLE FOR CATEGORIZATION OF THE RESPONSES 
	  (INFORMATIVE)	38
ANNEX D - ACRONYMS (INFORMATIVE)	39
ANNEX E - GLOSSARY OF TERMS (INFORMATIVE)	39




1	Introduction

The purpose of this document is to express the requirements within the
context of the MPEG-21 Multimedia Framework for the specification of a
Rights Data Dictionary and a Rights Expression Language. The content of
this document has been created by consolidating the submissions
received in response to the Call for Requirements for a Rights Data
Dictionary and a Rights Expression Language, issued by MPEG (document
number ISO/IEC JTC-1/ SC29/WG11 N3950). It should be regarded as a
'work in progress' to which comments are invited.

At the request of a number of the respondents to the first Call for
Requirements, MPEG has decided to re-issue the Call for Requirements to
allow time for additional responses to be received. See Annex B and C
for a list of the original responses and their categorisation. The
closing date for responses will be 1 June 2001. A special meeting will
be held in London on 7-8 June 2001 to further elaborate the
requirements taking into account these responses, in preparation for
the Call for proposals to be issued at the next MPEG meeting to be held
in Sydney from 16 - 20th July.

MPEG sees a Rights Data Dictionary as a dictionary of key terms which
are required to describe rights of all Users, including intellectual
property rights, that can be unambiguously expressed using a standard
syntactic convention, and which can be applied across all domains in
which rights need to be expressed.  A Rights Expression Language is
seen as a machine- readable language that can declare rights and
permissions using the terms as defined in the Rights Data Dictionary.

The Rights Data Dictionary and Rights Expression Language are intended
to provide flexible, interoperable mechanisms to support transparent
and augmented use of digital resources in publishing, distributing, and
consuming of electronic books, digital movies, digital music,
interactive games, computer software and other creations in digital
form, in a way that protects digital content and honors the rights,
conditions, and fees specified for digital contents. It is also
intended to support specification of access and use controls for
digital content in cases where financial exchange is not part of the
terms of use, and to support exchange of sensitive or private digital
content.

The Rights Data Dictionary and Rights Expression Language are also
intended to provide flexible interoperable mechanisms to ensure
personal data is processed in accordance with individual rights and to
meet the requirement for Users to be able to express their rights and
interests in a way that addresses issues of privacy and use of personal
data.  (Note: Users, in this context, is as defined in the MPEG-21
Technical Report.) A standard Rights Data Dictionary should define an
extensive and unambiguous set of semantics covering the vocabulary of
terms for rights expressions used in  the Rights Expression Language.
A standard Rights Expression Language should be able to support
guaranteed end-to-end interoperability, consistency and reliability
between different systems and services. To do so, it must offer
richness and extensibility in declaring rights, conditions and
obligations, ease and persistence in identifying and associating these
with digital contents, and flexibility in supporting multiple
usage/business models.

For consistency, this document adopts the terminology that is being
used within the MPEG-21 Technical Report to describe the seven
architectural 'Elements' within the Multimedia Framework. Contributors
to this work are therefore encouraged to read the PDTR Study N4040 and
in particular Annex A of that document (and repeated in Annex A of this
document).  Contributors are also encouraged to read the Working Draft
specifications for Digital Item Declaration (N3971, see
www.cselt.it/mpeg) that provides a context for the requirements for the
Rights Data Dictionary and Rights Expression Language.



2 Requirements for a Rights Data Dictionary and a Rights Expression 
Language

This section provides the details for the requirements for the Rights
Data Dictionary and a Rights Expression Language. There has purposely
not been any attempt to categorise the requirements into those for the
Data Dictionary or those for the Expression Language.  Respondents to
the envisaged Call for Proposals will be free to provide their own
interpretation or categorisation of the requirements. Also, no order of
importance has been placed on these requirements.

For brevity, the Rights Data Dictionary and a Rights Expression
Language, shall be referred to with the acronym  "RDD-REL" in the below
requirements.

The requirements are presented below and are grouped into common sets
of requirements.  Each group is prefaced with narrative text to
introduce the set of requirements.

2.1	Modeling and Principles to support RDD-REL

It is important that MPEG adopts a clear and extensible model to
support the creation of a Rights Data Dictionary and a Rights
Expression Language. The majority of the submissions received so far
reference existing work in this area in the <indecs> Project , and the
IFLA work. The principles outlined in these activities are adopted in
this document to provide a background for the description of the
requirements. These principles may eventually be adopted as the basis
of the specification.

Research to date indicates that the model should support the clear
separation and identification of three core entities expressed using
MPEG-21 terminology: Users, Digital Items, and Rights assertions as
shown in the diagram below.

XXXX


This model illustrates the basic relationship among all three entities
within the model.

The Rights Data Dictionary shall define all the semantics of the terms
to be used in the Rights Expression Language. The structure of these
definitions should follow standard data element specification methods.

Within a Rights Data Dictionary model there are various Elements that
need to be supported.  These Elements can then be related to other
classes of Elements. For example, a 'parent' Element can be related to
'child' Elements.

A possible way to express the RDD-REL Element model is as follows:

XXXX
 

The RDD-REL must support the specification of the rights and their
related permissions for the use of Digital Items. These rights and
their related permissions should be specified via high- level Elements
that represent common classes of usage. The RDD-REL will then enable
the more explicit definition of rights and their related permissions
beneath these Elements.

A Right is defined as a privilege that a User may claim (e.g. legally
or morally) that is due to them over a Digital Item. Rights enable
specific permissions (or usages) to these Digital Items.

2.1.1	Extensible Model

Requirement: 
The RDD-REL shall provide an extensible model that clearly separates
the three core entities:
 - Users
 - Digital Items
 - Rights

The three entities must be identifiable and associated together to
support explicit relationships Note:  User and Digital Item are defined
terms (see Glossary in Annex A) In some cases, all three entities may
not need to be related at the same time.  Example:  A specific Rights
Expression is linked both to a specific Digital Item and associated
with a User (eg a rights holder)

2.1.2	Articulation of Roles

Requirement: 
The RDD-REL shall support the articulation of roles undertaken by Users
Note:  Roles maybe sector specific. A mapping between them may also be
useful. The articulation of roles should enable Users to perform
multiple roles as required Example:

 - An identified User may be associated with the role of "Illustrator"
   for an identified Digital Item

2.1.3	Standard Identification Systems

Requirement: 
The RDD-REL shall support an open standard identification systems for
entities in the model.

Note: 
Entities (Users, Digital Items, description schemes, etc) may not
always need to be identified (e.g. for privacy reasons, or because a
schema is implicit) but their identification should not be precluded

Example: 
 - ISO TC46 SC9 identification systems, open standards based on the URI
   standard (RFC2396)

2.1.4	Creation Types

Requirement: 
The RDD-REL shall support the description of rights associated with all
creation types including abstractions, expressions, manifestations and
artifacts (referenced as defined terms)
Note: 
Supporting creations in their various instantiations will enable clearer (and more 
explicit/appropriate) attribution of rights information.
Example: 
?	To support the description of rights in musical works, performances of musical 
works, sound recordings and physical sound carriers.


2.1.5	Support Digital Item Usage/Business Models

Requirement: 
The RDD-REL shall   enable the description of rights, permissions, conditions and 
obligations to support existing usage and business models and shall not to constrain future 
models for the use of Digital Items
Note: 

Example: 
?	An example usage/business model is subscription to online music.

2.1.6	Interoperability

Requirement: 
The RDD-REL shall provide interoperability for the management and protection of rights 
associated with Digital Items across IPMP systems
Note: 
Without such a capability heterogeneous IPMP systems cannot interoperate
Example: 
?	

2.1.7	Lifecycle of Digital Items

Requirement: 
The RDD-REL shall support all operations throughout the entire life cycle of Digital Items 
including creation, publishing, distribution, consumption, and invalidation/disposal.
Note: 
A standard vocabulary and a consistent, ordered and machine-readable language is 
required for describing both the upstream and downstream rights associated with Digital 
Items. 
Management of Rights Descriptions will be more exact by addressing each stage of the 
life cycle of Digital Items and the respective roles of the Users. In this way each User can 
define each life cycle category of rights independently.
Example: 
?	Creation - Copyright information, Neighboring rights information, Information of 
moral rights of author.
?	Publishing - Information about permission of rights and transfer of rights, Royalty 
information.
?	Distribution - Price, Usage rules.


2.1.8	Permission by Contract

Requirement: 
The RDD-REL shall support expression of permission by contract, which is not defined by the 
copyright law. Expression of rights, which are not granted protection under copyright law, but are 
granted protection under other laws, shall also be supported.
Note: 

Example: 
?	In order to take a picture of an ancient artistic work, authorization must be given by the owner of the 
work. Ownership of an ancient artistic work with expired copyright shall be described.
?	For example, civil laws.
2.1.9	Definition of Terms

Requirement: 
The RDD-REL shall support the separation of the semantics from any syntactical 
encodings.
Note: 
The semantics of the RDD-REL terms shall be defined utilising standard data element 
specification methods.
Example: 
?	
?	Terms can be defined with a formal definition, name, comment and usage notes.

2.1.10	Modelling of Dictionary Terms

Requirement: 
The RDD-REL shall allow for common and abstract Elements to be defined. These can 
then be further refined and elaborated into specific Elements.
Note: 
Adopting a Parent/Child model will help in the modeling and understanding of the 
Elements in the Dictionary
Example: 
?	

2.1.11	Constraint Terms

Requirement: 
The RDD-REL shall allow the specification of Constraints applicable to the Usages. At 
least the following Constraint types shall be supported, User, Device, Bounds, Temporal, 
Spatial, and Aspects of the Digital Item
Note: 
Constraints should be modeled in the same way as the Usages.
Example: 
2.1.12	Narrowing of Rights

Requirement: 
The RDD-REL shall support the specification of Narrowing of rights.
Note: 

Example: 
?	A distributor may only have the right to on-sell a smaller number of copies of a 
Digital Item.

2.1.13	Exclusive Rights

Requirement: 
The RDD-REL shall support the specification of Exclusive rights.
Note: 

Example: 
?	A User may be assigned the exclusive rights to distribute a Digital Item in a 
specific country.

2.1.14	Exceptions of Rights

Requirement: 
The RDD-REL  shall support the specification of Exceptions of rights.
Note: 

Example: 
?	For example, the "fair use" exceptions in Copyright.



2.1.15	Accessibility

Requirement: 
The RDD-REL shall support Accessibility issues.
Note: 
The RDD-REL should allow for alternative usage permissions or constraints for Digital 
Items to meet the needs of communities with special needs.
Example: 
?	For example, allow Digital Items to be converted from text to speech.

2.1.16	Expressiveness 
Requirement: 
The RDD-REL shall provide a sufficiently large set of rights terms and expressions for all 
users (including creators, other rights holders and distributors) of Digital Items to express 
their rights on, interests in, and contractual agreements related to the Digital Items 
according to a variety of usage and business models, and for all technology and service 
providers to developing and deploying IPMP solutions, systems and services that 
persistently and reliably manage and protect (whenever required) the Digital Items across 
a wide range of networks, systems and devices through the entire life cycle of the Digital 
Items. 
The RDD-REL should enable 
?	Digital Item rights holders such as owners and distributors to identify content, 
specify rights and their associated conditions and obligations appropriate to 
usage/business models they select; 
?	technology providers such as hardware and software vendors to develop IPMP 
solutions and systems to implement the usage/business models specified by the 
content owners and distributors. 
?	proper protection of Digital Item, and interpretation and enforcement of rights and 
their related permissions during its distribution and usage;
?	service providers to operate a variety of  services such as authentication,  
transaction processing, and usage tracking; and content users to understand and 
exercise their entitled rights, fulfill associated conditions and obligations, and 
access and use contents with a good user experience. 
Note: 
The RDD-REL should benefit all parties to the Digital Item life cycle, including those 
involved in creation, distribution, consumption and disposal of Digital Items. This 
includes, not only publishers and distributors issuing rights expressions to end users, but 
also publishers issuing rights to distributors, distributors issuing rights to distributors, and 
end users transferring rights to end users. 
Example:
?	
2.1.17	Machine Readable Language

Requirement: 
The RDD-REL shall be machine-readable.
Note: 
Machine readability will enable automatic handling (i.e. machine-to-machine) of rights 
expressions. 
Example: 


2.1.18	Usability 
Requirement: 
The RDD-REL shall be useful for all stakeholders involved in the entire DigitalDigital 
Item life cycle, including content publishing, distribution, usage and disposal. 
Note: 
The RDD-REL should not be limited to expressing usage rights only for end-users.
Example: 
Publishers should be able to use the language to specify usage rights and contractual 
information for distributions as well as for end-users. Distributors should be able to use 
the language to specify usage rights they offer as well as grant to end-users. 

2.1.19	Extensibility
Requirement: 
The RDD-REL shall provide extensibility to new features to meet the needs of the digital 
content industry today and as it develops in the future. 
Note: 
This would allow for an initial implementation able to express only a limited set of rights 
terms and expressions. In order to support more complicated usage/business models at a 
later stage, further rights terms and expressions can be added to the language. 
Example: 
?	The extensibility includes adding new rights, conditions and obligations.
Rights established in the future: 
Moral rights of performers, rights for databases that are not granted protection 
under present copyright law, right of making transmittable, rules for private use of 
works.
Rights that vary from country to country:
Droit de suite in France, right of access to the original of a work in Germany.
Rights recognized only by custom or precedent:
Right of privacy & right of publicity, right of name, merchandising right 


2.1.20	Customisability
Requirement: 
The RDD-REL shall be flexible to be tailored into subsets of rights terms and expressions 
to meet different purposes and needs for different vertical applications and markets it 
supports, without issuing different versions of the language for all these individual 
applications and markets. 
Note: 
Being able to customize the language would allow validation of required rights terms and 
expressions and development compact systems that are only for those vertical applications 
and markets.
Example: 
?	For instance, MPEG applications may have a different subset of terminology from 
eBook applications. MPEG applications prefer "Play" Digital Item, while eBook ones 
prefer "View" content. Digital Item structures and formats for different media types 
are most likely different. Fee charging models may also be different.

2.1.21	Interoperability
Requirement: 
The RDD-REL shall be defined in a way that ensures that rights terms and expressions 
from different rights holders and technology providers can be aggregated and processed, 
and that Digital Items whose usage are governed by these rights terms and expressions can 
be used and consumed by their users on content processing applications they have that 
understand the language.
Note: 
The interoperability also ensures that rights are governable and exercisable in the event of 
some IPMP solution and system providers ceasing to actively conduct business or provide 
usage services
Example: 
?	Rights supplied from one Digital Item owner for an MPEG Digital Item should be 
understood and exercisable by all MPEG players that implement the language. These 
rights should also support interoperable IPMP services, such as clearinghouse rights 
authentication, transactions processing and secure storage. 

2.1.22	Identification and Metadata of Rights Expressions
Requirement: 
The RDD-REL shall provide mechanisms to unambiguously and universally identify rights 
expressions written in the language, as well as supply metadata information about these 
rights expressions. 
Note: 
Identification should also include proper version control of the language. This makes it 
easy to manage expressions or documents written in the language. 
Example: 
Proper identification is useful in searching, indexing, registering, archiving, and 
referencing rights expressions. 

Metadata information includes description, time at which a rights document is issued, 
valid time period, issuer, principals that the document is issued to, and distribution points 
where the document is obtained. 

2.1.23	Authentication of Rights Expressions
Requirement: 
The RDD-REL shall offer a mechanism to allow for authentication of expressions or 
documents written in the language.
Note: 
This helps detection of any tampering of rights expressions. This could be useful for 
service providers specializing in issuing and managing rights documents for their 
customers and in detecting inconsistency of the rights descriptions.
Example: 
Authentication could be ensured by providing digital signatures to rights expressions or 
documents. 

2.1.24	Written in Open, Standard Meta-Language
Requirement: 
The RDD-REL shall be defined in open, standard meta-language. 
Note: 
This will enable interoperability, machine readability, easy adoption, and fast development 
and deployment. It will also make it easy to do integration with IPMP-aware systems and 
services.
Example: 
XML and BNF (Backus Naur Form) are examples. 

2.1.25	Well-Defined Semantics
Requirement: 
The RDD-REL shall have useful, concise, unambiguous, and easily understandable 
semantics and predictable effects.
Note: 
This will enable machine readability. This requires that the language be maintained by an 
entity or organization with vast experience and solid research history in the IPMP 
technology. 
Example: 
The semantics will cover structural association of rights, conditions and obligations with 
single Digital Items as well as composite Digital Items and collections of Digital Items, 
logical process for evaluating conditions and fulfill obligations in order to exercise related 
rights, and solid foundation to specifying usage/business models it supports. 

2.1.26	Coordination 
Requirement: 
The RDD-REL shall be specified and documented in a way that meets general 
coordination requirements of industry standards. 
Note: 
This is not a functional requirement, but a necessary prerequisite for the language's 
application to the overall requirements of MPEG.
Example: 
Coordination aspects of a language specification include: correct, unambiguous, complete, 
verifiable, consistent, understandable by all stakeholders, modifiable, version traced, 
history traceable, design independent, annotated, concise, and well organized. 

2.1.27	Efficient Implementation, Test and Evaluation
Requirement: 
The RDD-REL shall support the building, testing and evaluation of surrounding 
programming modules, applications and services to handle all expressions or documents 
written in the language.
Note: 
Building IPMP applications requires the flexibility to access tested and evaluated 
programmatic interfaces designed probably from other software vendors. 
Example: 
Considerations include the size of expressions and resources needed for processing such 
expressions.

2.1.28	Administrative Information

Requirement: 
The RDD-REL shall support information about the Rights expressions   in the form of 
Administrative elements.
Note: 
This is required to support the administration and management of Rights 
Expressions
Example: 
?	Information such as who created the expression, on what date, and how long it is 
valid for.

2.2	Digital Item Requirements



This section specifies requirements for Digital Items with respect to their use in a RDD-REL. 
(Please note that these are not general requirements for Digital Items which is being defined in 
MPEG21.)
2.2.1	Digital Item Identification
Requirement: 
The RDD-REL shall support uniform, flexible and interoperable mechanisms to identify 
Digital Items and their types at a global scope according to international identification 
systems or schemes. (ref MPEG21 Part 3 WD)
Note: 
Each of media or market sectors can manage Digital Item identification at its own 
discretion. This identification information should be consistent with what it is used for, 
e.g., indexing search and retrieval, in Digital Item publication, distribution and 
management systems including. This identification can be applied at the level of an 
'object' that can have many levels of granularity; for example, an object could be an 
individual Digital Item, a composite Digital Item, or a collection of identifiable Digital 
Items. 
Example: 
Existing identification systems include ISAN, ISBN, ISRC, ISSN, URL, URI and DOI. 
Types of contents include textual, audio, video, and still image.

2.2.2	Digital Item Metadata
Requirement: 
The RDD-REL shall provide mechanisms to reference Digital Item metadata as part of the 
language, make reference to external content metadata, and include existing content 
metadata. 
Note: 
The RDD-REL will not be able to enforce that metadata information be present, persistent 
or correct. However, the authentication of rights expressions provided in the language can 
be used to technically prevent the information to be altered or removed.
Example: 
Metadata defines descriptions of Digital Item. It can include information from very low-
level (colors, fonts, shapes, sound characteristics, segmentations in space and time, etc.) to 
very high level (creators, publication dates, title, description, table of content, etc.). 
There are many standard activities aiming at defining Digital Item metadata. Examples are 
RDF, Dublin Core  INDECS, ONIX, and MPEG-7 and some parts of MPEG-4 
description.

2.2.3	Composite Digital Item
Requirement: 
The RDD-REL shall provide mechanisms to specify composite Digital Items as well as 
component parts of the overall Digital Items.
Note: 
Theses mechanisms will also be used to associate possibly rights, conditions and 
obligations to component parts that are different from ones associated with composite 
Digital Items, as the component parts may come from potentially different sources. This is 
essential to support a variety of content usage and business models associated with, for 
example, selling portions of a digital work or collections of portions of a digital work. 
This is also important to be able to prevent composite works from being created without 
proper permission. 
Example: 
An eBook as a digital object may contain images and chapters from other publishers. A 
video program may contain clips or regions from other ones.  A song may possess a 
sound, which is from a different song.

2.2.4	Digital Item Collections
Requirement: 
The RDD-REL shall provide mechanisms to reference collections of Digital Items.
Note: 
This helps, for example, association of a set of rights with a collection of Digital Items, 
which is more efficient than association of the same set of rights with each individual 
Digital Item in the collection.
Example: 
Examples of collections of Digital Items are a collection of eBooks with less than 100 
pages, and a series of episodes from a TV show. 

2.2.5	Digital Item Authentication 
Requirement: 
The RDD-REL shall provide mechanisms to reference authentication schemes. These 
mechanisms help ensure integrity of Digital Items and detect if the Digital Items have 
been altered in an unauthorized manner. 
Note: 
Authentication mechanisms could be specifications of necessary information that is 
needed for other security modules to perform authenticity verification. Digital Item 
authentication allows users to determine that Digital Items they've obtained are authentic 
and distinguish between legitimate and illegitimate Digital Items. 
Example: 
Including digital signatures of Digital Items from their publishers or distributors is a way 
to ensure Digital Item authenticity.

2.2.6	Digital Item Protection
Requirement: 
The RDD-REL shall support mechanisms to indicate types and levels of protection of 
Digital Items that rights expressions are associated with. These mechanisms shall help 
ensure confidentiality of Digital Items, preventing unauthorized access and use, and 
assisting authorized access and use without adversely affecting the user experience.
Note: 
Digital Item protection is an essential, integral part of IPMP. As Digital Item protection 
comes at a cost and there is always a cost/benefit trade-off, well-defined types and levels 
of protection make sense to fill different protection needs. Some Digital Item may well be 
unprotected for promotional purposes, for example, the first chapter of the book. It is also 
possible that a same Digital Item is protected by several stakeholders at different stages of 
the Digital Item life cycle. 
Example: 
Types and protections could be specified as different sets of necessary parameters for 
protection algorithms and protocols. Examples of these parameters include algorithm 
name, key size, encoding method, and keys.

2.2.7	Digital Item Availability
Requirement: 
The RDD-REL shall support standard mechanisms to indicate where Digital Items are 
available for retrieval or access.
Note: 
This helps Digital Item retrieval or access in events like Digital Items are not available, 
corrupted, and not authentic.  
Example: 
Content availability can be specified by URLs of contents or distribution points of the 
contents. 


2.3	Usage Rights Element Semantics
2.3.1	Specification of Usage Rights
Requirement: 
Usage Rights expressed in the RDD-REL shall cover all essential types and modes of 
operations and activities that may happen to Digital Items during their life cycles. This 
shall include at least the following usage rights: access, view, play, print, copy, edit, loan, 
and delete.
Note: 
An operation or activity may be performed or conducted by an individual or between a 
group of individuals. 
Example: 


2.3.2	Categorization of Rights
Requirement: 
The RDD-REL shall organize rights into categories according to commonalities of types 
and modes of operations and activities the rights cover. 
Note: 
Such a categorization may be based the Digital Item life cycle, and updated as more 
digital rights are considered.
Example: 
Logically, rights can be categorized into render (for Digital Item use), transport (for 
Digital Item delivery and transfer), derivative work (for Digital Item manipulation), file 
management (for Digital Item search and storage) and configuration (for Digital Item 
installation). Render rights govern the printing and display of a work, or more generally, 
the transmission of a work through a transducer to an external medium. Render rights 
include the export right, which can be used to make copies of a work in the clear (i.e., 
from protected to unprotected). Transport rights govern the movement of a work from one 
repository to another.  Derivative work rights govern the reuse of a work in creating new 
works. File management rights govern such things as making and restoring backup copies.  
Finally, configuration rights refer to the installation of software in repositories.

2.3.3	Transport Rights
Requirement: 
The RDD-REL shall provide mechanisms to express transport rights in order to 
?	distinguish between rights for moving works among repositories and rights that 
increase the total number of copies of a digital work.
?	describe controlled loaning of works, both personal loans and also institutional or 
library loans.
?	support a range of distribution models, including both licensed distributor models 
and consumer-based distribution (also known as super distribution).
?	enable publishers to specify how the rights change on new copies of works.
?	control what rights move to the loaner copy when a copy of a work is loaned out 
and also what rights stay behind.
Note: 
Transport rights govern the creation and movement of persistent copies of a work under 
the control of trusted repositories. The interpretation of these rights is similar to familiar 
operations on physical works: copying an audiotape, transferring (or giving someone) a 
book, or loaning a compact disc.  XE "Rights Class:Transport"   XE "Transport rights" 
Example: 
A COPY right is the right to make a new digital copy of a work. (PRINT rights, described 
later, govern the making of hard copies.) The COPY right is invoked whenever a new 
digital copy is made.
 XE "Copy right"  XE "rights:Copy right" 
A TRANSFER right is the right to transfer the digital work from one repository to 
another. A TRANSFER right does not increase the number of copies of a work because 
the transfer transaction between two trusted systems removes the digital work from the 
sending repository when the copy has been created and verified on the receiving 
repository.
 XE "Transfer right"  XE "rights:Transfer right" 
A LOAN right is the right to loan a copy of the work for a period of time. A LOAN right 
creates a "loaner" copy of a work on a receiving repository. Typically, during the time that 
a work is loaned, the original copy of the work cannot be rendered. However, if there is 
more than one copy of the work on the original repository, then the original repository can 
still exercise all rights on copies that are not loaned out. 

2.3.4	Render Rights
Requirement: 
The RDD-REL shall provide mechanisms to express render rights in order to
?	distinguish between rights for making ephemeral copies such as display images 
and rights for making long-lasting copies such as printouts.
?	provide a means of distinguishing different kinds of viewers, players and printers 
for digital works such as ones that add distinguishing codes. For example, a 
publisher may want to limit printing of a digital work to certain kinds of printers 
that are capable of embedding specific kinds of watermarks.
?	provide a controlled means for creating unencumbered digital copies outside of a 
trusted system.
Note: 
Render rights govern the creation of representations of a digital work outside of the 
control of trusted systems.
Example: 
There are three kinds of render rights: PLAY, PRINT, and EXPORT. 

PLAY rights refer to ways of making a transient or ephemeral copy of a work available 
for use. For example, a page of a book may be displayed on a screen or music may be 
played out a speaker. The image on the screen or the sound coming out of the speaker is a 
transient copy. The PLAY right is also used to refer to invocation of a computer program, 
such as when someone plays a video game. The renderings produced when a PLAY right 
is exercised are ephemeral.
 XE "Play right"  XE "rights:Play right" 
PRINT rights refer to making more permanent rendered copies of a work outside of the 
control of a repository. In contrast to the Play right, once a work is printed, the printed 
copy can be viewed without requiring that the "PRINTER" be used the entire time. The 
typical case is printing something on paper at a printer. The Print right also refers to 
making rendered copies on other external media, such as bitmap images on removable 
disks or audio on magnetic tapes. For example, a repository may provide rights to "print" 
encrypted backup copies of a digital work. Unauthorized use of such copies is inhibited 
because such copies of the work are generally encrypted. 
 XE "Print right"  XE "rights:Print right" 
An EXPORT right makes a digital source copy outside of trusted system control. 
Typically, this would be a file in a format suitable for unencumbered viewing, printing, or 
editing. Thus, this right can be used to make a digital copy that is not encrypted or 
otherwise protected. An EXPORT right might be exercised, for example, to release an 
older work after it has passed out of copyright. XE "Export right"  XE "rights:Export 
right"  XE "Loan right"  XE "rights:Loan right" 

2.3.5	Derivative Work Rights
Requirement: 
The RDD-REL shall provide mechanisms to express derivative work rights in order to
?	make it possible for the rights owner to pre-arrange fees and conditions governing 
subsequent use of the material in derivative works.  
?	make it possible for the rights owner to pre-determine whether communication for 
notification or authorization is required before a derivative work right can be 
exercised.
?	ensure that all information about authorship, identity, Digital Items, and rights is 
controlled or preserved in the derivative work.
?	arrange that the collection of fees for use of derivative works is automatic and can 
depend on the number of copies of the derivative work that are actually made.
?	enable a rights owner to determine whether derivative works can incorporate 
selected portions of a work, or whether the original work must be incorporated in 
total.
?	provide a framework that can eventually enable a rights owner to determine what 
kinds of changes are permitted in the derivative work, if any.
Note: 
We distinguish three kinds of derivative work rights: EXTRACT, EDIT, and EMBED.

The EXTRACT right allows removing a portion of a digital work, creating a new work. A 
rights owner can divide a total digital work up into different sub-works, each with its own 
work specification. In this way, the rights owner can decide whether a work can be reused 
as a whole or in parts, and also can associate different rights and conditions with different 
parts of a digital work. EMBED differs from EMBED in that it does not grant the right to 
modify a work, except by removing parts of it.  
 XE "Extract right"  XE "rights:Extract right"  XE "editor specification" 
EDIT grants the right to modify a work. EDIT is like EXTRACT in that it creates a new 
work. It differs from EXTRACT in that it is used to make changes to a work. A rights 
owner can control what kinds of changes can be made to a digital work by specifying a 
kind of editor. For example, a particular digital audio music editor may allow someone to 
change the pitch or key of a piece of music, but not add notes.  If the optional editor 
specification is not given, then any editing program can be used. Otherwise, only the 
specified editing system can be used. 
 XE "Edit right" 
EMBED grants the right to include a work as part of a composite work. EMBED puts a 
copy of a digital work inside a composite work. If the optional editor specification is not 
given, then any editing system can be used. Otherwise, only the specified editor can be 
used. XE "Embed right"  XE "rights:Embed right"  XE "Loan right"  XE "rights:Loan 
right" 
Example 


2.3.6	File Management Rights
Requirement: 
The RDD-REL shall provide mechanisms to express file management rights in order to
?	provide a simple and consistent means to specify and control access to digital 
works across different repositories and different kinds of repositories.
?	provide a lightweight and convenient means for organizing collections of digital 
works in a repository.
?	integrate specifications for controlling how collections of works can be used with 
specifications about how individual works can be used.
?	provide facilities that manage the risk of system or media failure or distribution of 
rogue works.

The following 'file management rights' shall be supported: 
?	Folder, 
?	Directory, 
?	Delete, 
?	Verify, 
?	Backup, 
?	Restore.
Note: 
File management rights govern access to directory and file information when two 
repositories are connected. File management rights control how directory information of 
one repository can be accessed from another. They also control the making and restoring 
of backup copies. 
Example: 
We distinguish six kinds of file management rights: Folder, Directory, Delete, Verify, 
Backup, and Restore.

When a repository has many digital works, it is often convenient to organize them into 
named hierarchical sets called folders. This approach is basic to many popular file 
systems, such as WindowsT, MacOST, and UNIXT. In repositories built on 
conventional computer file systems, these hierarchical sets generally correspond to file 
system folders and directories. For consistency across brands of repositories, the same 
rights markup language that applies to digital works is also used for folders.  

Folder rights govern the creation and naming of subfolders, and the right to reconfigure 
the folders by moving files and folders among folders. These rights are exercised by 
commands at a repository user interface. The right to exercise all of these operations is 
governed by the single "folder" right.  XE "Folder rights"  XE "rights:Folder right"  

Directory rights govern the delivery of information about what works are contained within 
folders.  XE "Directory rights"  XE "rights:Directory right" A directory listing may be 
requested of any folder in a repository, allowing either the local or a remote repository to 
get information about the works, their parts, and other folders contained in it. The ability 
to get information about a folder, a work, or its parts may be withheld in such directory 
listings by simply requiring a license to exercise the right.

Delete rights govern the operation of deleting a copy of a digital work. The generally 
expected practice is to grant any copy owner the right to delete the work. The right to 
delete needs to be controlled in applications where many people can log into a repository 
and where deleting a file could be done accidentally or in malicious mischief. To prevent 
the unwanted and unauthorized deletion of digital works that are accessed remotely, it is 
typical for a Delete right to include various conditions, such as the requirement of a digital 
license to exercise the right.  
 XE "Delete right"  XE "rights:Delete right" 
Verify rights are used to authorize checking of the authenticity of a work. There are 
several different kinds of checking that can be performed. The simplest checks verify that 
the work is properly encrypted. Other checks involve the use of 1-way hash functions and 
other keys that can detect tampering with a work.  Other checks can consider hot-lists of 
rogue works maintained by the trusted system. Reference copies of a work may be 
available on the network. Local copies can be carefully compared with reference copies to 
verify their authenticity.

Backup grants the right to make copies of a work for the purpose of guarding against the 
loss of the original due to accident or catastrophic media or equipment failure. The backup 
operation creates an encrypted copy of a digital work, which is in a form where it cannot 
be rendered without first exercising a restore operation. 
 XE "Backup right"  XE "rights:Backup right" 
A restore operation converts an encrypted backup copy into a usable copy in a controlled 
manner. Restore rights typically elaborate various fees and conditions that balance the 
interests of the copy owner with the interests of the publisher. XE "Restore right"  XE 
"rights:Restore right"  XE "Loan right"  XE "rights:Loan right" 


2.3.7	Configuration Rights
Requirement: 
The RDD-REL shall provide mechanisms to express configuration rights in order to 
?	provide a means to load software that insures that it is certified, has not been 
tampered with, and is compatible with the repository.
?	arrange that a user installing and uninstalling repository software in the field has 
security on the same order as when software is installed in a secure facility.
The standard shall support Install and Uninstall configuration rights.
Note: 
Configuration rights govern the adding and removing of system software from highly 
secure repositories.  These rights are not relevant on platforms where the loading of 
software is not controllable. Because general purpose computers have other means for 
loading and deleting software, configuration rights are most relevant to dedicated, high 
security repositories. Typically, the control offered by configuration rights on secure 
repositories is most useful when adding software for a new player or editor.    XE "Rights 
Class: Configuration" 
Example: 
There are two kinds of configuration rights: Install and Uninstall. 

An Install operation makes software runnable on a repository. Just copying a program to a 
repository does not make it runnable. The installation operation checks that software is 
certified, that it has not been tampered with, and that it is compatible with the repository. 
If these conditions are satisfied, the install operation links the software into the secure 
software procedures of the repository. XE "Install right"  XE "rights:Install right" 

The Uninstall operation removes software from the running system. Uninstall does not 
delete the file corresponding to the program. It merely disables it from running, restoring 
it to the state before it was installed.

2.3.8	Adding New Rights
Requirement: 
The RDD-REL shall provide mechanisms to introduce new rights that are specific to 
media types, vertical applications and Digital Item usage and business models. 
Note: 
These mechanisms shall allow adding new rights without resulting in new versions of the 
language. In many cases,
Example: 
In many situations, a same kind of right will have different names in different vertical 
applications. For instance, "play" a song versus "view" an ebook, and "tape" a song versus 
"print" an ebook. 

Examples of media type or vertical application specific rights include forward, pause, 
rewind, stop, modify (raise/lower) quality when play multimedia Digital Items. 

2.3.9	Changing Rights
Requirement: 
The RDD-REL shall provide mechanisms to express:
?	how rights expressions (including conditions and obligations) can be changed over 
time; and  
?	how rights expressions (including conditions and obligations) can be changed or 
modified in other rights expressions derived from them. Rights change should be 
under control of the original rightsholder or a designated agent and would include 
the ability to designate authorized parties for alteration and referral of or to 
information contained in a rights expression.
Note: 
This is because Digital Item usage business models can be dynamically changing and 
rights will be passed from one to another in the distribution and usage value chain. It 
should be possible for a rights holder to change a rights expression associated with a work 
after the rights expression has been issued. 
Example: 
A publisher may decide, after an ebook has been offered without a print right, to offer the 
print right for a higher price, or to make the ebook free after a period of time. 

2.4	Conditions
2.4.1	Time Based Usage
Requirement: 
 XE "Time specification" The RDD-REL shall provide mechanisms to specify time 
periods over which rights are granted in order to:
?	express time limits that govern when rights become available and when they cease 
to be available.  
?	express the categories of time blocks that are useful for governing commercial and 
non-commercial use of digital works.  
?	describe contiguous periods of time, periods of time that do not start until a work is 
first used, accumulative amounts of time that need not be contiguous, and 
recurring time intervals that a work can be used repeatedly in a regular fashion.
?	provide unambiguous specifications suitable for international commerce and use 
across time zones.

The RDD-REL shall support the following time specifications:
?	Fixed intervals 
?	Sliding intervals 
?	Metered intervals
Note: 
There are at least three kinds of intervals in time specifications: fixed intervals, sliding 
intervals, and metered intervals.
If no time condition is specified, an associated right or rights are assumed to be 
exercisable all the time. It is understood that enforcing time conditions depends on trusted 
clocks on either client, sever or both systems. To accurately account for sliding or metered 
time, an incremental log of the amount of time used so far must be kept in a trusted 
manner. 
Example: 
In their most complete form, fixed intervals start at a fixed time and ends at a fixed time. 
In variations, a fixed interval specification can specify only a starting time or only an 
ending time. Examples are "from January 1, 2000 until December 31, 2000", and "until 
December 31, 2001". 
Sliding intervals specify a consecutive period of time. The period starts when the right is 
first exercised.  Examples are "30 days" and "5 minutes". XE "sliding interval 
specifications" 

Metered intervals represent accumulative periods of time. The metering clock runs 
whenever the right is being exercised, and stops when the user stops using it. Examples 
are "3 metered hours" and "5 metered days".  XE "metered interval specification" 

Sliding intervals and metered intervals can be optionally augmented with recurring 
intervals within which the sliding and metered intervals will occur. Examples are "30 days 
every year", "3 metered hours every week" and "5 metered days every month, starting on 
the 3rd day of every month".  XE "fixed interval specifications" 
 

2.4.2	Count Based Usage
Requirement: 
 XE "Time specification" The RDD-REL shall provide mechanisms to specify the number 
of times a right can be exercised   in order to:
?	express limits that govern how many times rights can be exercised with no time 
constraints (i.e., the life time).  
?	express limits that govern how many times rights can be exercised within recurring 
(sliding and metered) time intervals.   
Note: 
If no count information is specified, rights can be exercised an infinite number of times.
Example: 
An ebook can be printed "3 times", a song can be played "5 times, and a software program 
can be run "30 times".

2.4.3	Fee Based Usage
Requirement: 
The RDD-REL shall provide mechanisms to specify fees which are paid to specific 
accounts in order to:
?	express the kinds of charges to exercise a right that are commercially useful for all 
kinds of digital works.
?	express variations on per-use fees and metered-use fees, including payments per 
time unit, minimum and maximum fees over a period, and fixed fees for unlimited 
use in a fixed time period.
?	support percentage-based revenue models where the recipient of the surcharge has 
no prior knowledge of the details of pricing.
?	accommodate approaches based on both credit accounts and debit accounts.
?	support transactions on trusted systems where the consumer is not on-line.
?	express fees in most national currencies and also in publisher-supplied non-
currency units (digital tickets).
?	express payments from a consumer to a publisher as well as incentives from a 
publisher to a consumer.
?	support payment to multiple parties that are entitled to receive the payment.
?	express predetermined and scheduled changes in price.
?	express bundled prices for using combinations of rights.
Note: 
A fee specification describes the financial transaction required to exercise a right. To 
honor these fees, trusted systems need to communicate regularly with financial clearing 
houses. They also need to have reliable and tamper-proof means of recording and 
reporting billing data. 
Example: 
?	There are many kinds of fee schemes. They can include a ticket specification or a 
monetary specification. 

?	If a ticket specification is given, then the transaction requires that a particular kind of 
digital ticket be processed ("punched") by a digital ticket agent accessible to the 
repository. 

?	Examples of monetary specifications are "a dollar per play" (per-user fee),  "fifty cents 
an hour" (metered fee), "fifty cents an hour, counted on minutes" (metered fee with a 
counting incremental), "fifty cents an hour, with minimum charge $2 and maximum 
charge $15 per month" (metered fee with minimum and maximum charges), 

?	Other examples include Best-Price, Call-For-Price and Markup Fee. Best-Price is a fee 
that can be dynamic and is determined when the account is settled. It is used to 
accommodate special deals, rebates, and pricing that depends on information that is 
not available to the trusted repository at the time the usage right is exercised, but 
without communicating with a dealer before the purchase is authorized. An example is 
to charge $5 to play the work, but will get a rebate if the price has gone down. XE "fee 
specification:best-price"  XE "best-price specification" 

?	Call-For-Price is similar to Best-Price in that it is intended to accommodate cases 
where prices are dynamic. However, unlike Best-Price, communication with a dealer 
to determine the price is required before the purchase is authorized; the transaction 
cannot be completed if the trusted repository is unable to communicate with the dealer. 
 XE "fee specification:call-for-price"   XE "call-for-price specification" 

?	Markup fees are fees that are computed as a percentage of other fees. For example, a 
distributor may want to add a flat ten percent overhead for selling copies of a digital 
work, or a government may want to tax sales of a digital works.

?	Every time a Digital Item is printed, pay User A $.10 and User B $.05. XE "markup 
fee" 

2.4.4	Access Control Based Usage
Requirement: 
The RDD-REL shall provide mechanisms to specify access control policies for users with 
proper credentials, identifiable systems and target devices in order to:
?	specify access control policies based on digital identities or certificates 
?	specify access control policies based on defined roles of users, systems and 
devices. 
?	specify access control policies based on possession of valid digital credentials 
(e.g., certificates, receipts or tickets), which contain predetermined conditions 
under which rights can be exercised.
?	Specify access control policies based on certified levels of security arrangement of 
repositories.
?	specify different access control policies for different rights on a work.
?	specify different access control policies for individual repositories, when 
exercising a right involves two or more repositories. 
Note: 
Using security levels to control access is practical approach to addressing that a publisher 
wants a system that is "at least this secure". The criteria for describing security provisions 
should admit the use of multiple dimensions, such as phyla security, communications 
security, defenses against viruses, method for identity testing, and so on.
Example: 
A company using digital documents to coordinate distributed work teams may want to 
limit distribution to certain employees in order to protect corporate or trade secrets. 

A publisher of an electronic journal may want to assure that copies of a work are only 
available to subscribers or subscribing institutions. 

A public school may want to limit access by students to documents that are age 
appropriate or which reflect certain community values. 

A movie studio may want to ensure that their movies be played only on devices that have 
security levels 4.   

2.4.5	Territory Based Usage
Requirement: 
The RDD-REL shall support industry standard mechanisms to reference territory 
information in order to
?	support limiting rights to certain physical regions, areas and locations.
?	support to restricting rights to certain digital domains, (sub-)networks and systems.
Note: 

Example: 
A document can only be used within a company's intranet. A software program can only 
sold to the North American region.

2.4.6	Portion Based Usage
Requirement: 
The RDD-REL shall provide mechanisms to specify information about portions of Digital 
Items in order to support limiting rights to these certain portions.
Note: 
The portion based usage is useful to support models of Digital Item preview and fair use. 
Example:
The first chapter of an eBook can be viewed for free, while reading the rest of the eBook 
requires a fee. A total of 100 Kbytes of a work can be extracted and posted to the 
clipboard. 

2.4.7	Mixed Conditions Based Usage
Requirement: 
The RDD-REL shall provide mechanisms to express any combinations of the basic 
conditions (as long as the combinations makes sense).
Note: 

Example: 
A document can be read by certain employees (access control) on systems connected by a 
company intranet (territory) within a month (time) or on any systems but only once 
(count).  

2.4.8	Specification of Conditions Common to Different Rights
Requirement: 
The RDD-REL shall provide mechanisms to bundle conditions and reference the bundle 
as a single entity.  XE "time specification:in bundles" 
Note: 
The RDD-REL usage should resolve situations like, a same type of conditions are 
specified as common ones to a set of rights as well as to some individual rights within the 
set.
Example: 
In order to read, edit and print a document, the user must be a company's employee. A 
software program can be installed and executed for 30 days before May 1, 1998. 

2.4.9	Changing Conditions
Requirement: 
The RDD-REL shall provide mechanisms to express:
?	how conditions can be changed over time in response to various events; and  
?	how conditions can be changed or modified in other rights expressions derived 
from them. Rights change should be under control of the original rightsholder or a 
designated agent.
Note: 
This is useful for distributors and retailers to change pricing information.
Example: 
A publisher may decide, after an ebook has been offered for a year, to lower its price. A 
government agency may de-classify some documents after 15 years.

2.5	Obligations
Obligations are conditions that must be satisfied in order to exercise granted rights.
2.5.1	Specification of Obligations
Requirement: 
The RDD-REL shall provide mechanisms to express a set of commonly understood 
obligations in order to support building and deploying IPMP solutions, systems and 
services. 

 
Example: 
Usage tracking and reporting, Digital Item watermarking, and fee payment.
2.5.2	Usage Tracking
Requirement:
The RDD-REL shall provide mechanisms to express how Digital Item usage should be 
tracked in order to 
?	record usage history for granting rights in future time. 
?	identify one or more tracking agencies and systems for keeping tracking 
information.
?	express what information needed (and need not) to be tracked.
?	specify how often tracking has to happen. 
?	specify what granulates tracking is based on.
?	support generation of reports for survey and business purposes. 
Note: 
Tracking has to be implemented in accordance with privacy rules. A usage history may be 
anonymous.
Example: 
An online server tracks how long a document has been viewed every 5 minutes and how 
many copied it has been printed every time a copy is printed.

2.5.3	Watermarking
Requirement: 
The RDD-REL shall provide mechanisms to specify Digital Item watermarking 
information in order to 
?	specify what information is to be embedded in a watermark.
?	embed into watermarks information known when a work is published (e.g. title and 
author) as well as information known only when a work is rendered (e.g. user 
name or printer name).
?	specify the types of watermarks that are consistent with Digital Item media types.
Note: 
Different kinds of watermarks are suitable for different kinds of works and media. For 
example, different techniques are used for watermarking music, movies, books, and high 
resolution photographs. For example, watermarks for music can embed data in the digital 
signal that are inaudible to the human ear when the music is played. The digital 
representations for different kinds of work -- e.g. for music, video, and text -- are varied 
and constantly evolving.
Example: 
A Print right is associated with watermarking information. The information specifies a 
particular kind of trusted printer, so the type of watermarking is determined by the type of 
trusted printer. The information to be embedded in the watermark includes an initial string 
in which the title, author, and a copyright notice are given. The next part of the 
information for the watermark includes the user's id, the location of his institution, the 
name and location of the printer, and the time that the work was printed.

2.5.4	Specification of Obligations Common to Different Rights
Requirement: 
The RDD-REL shall provide mechanisms to bundle obligations and reference the bundle 
as a single entity  XE "time specification:in bundles" 
Note: 
The RDD-REL should resolve situations like, a same type of obligations are specified as 
common ones to a set of rights as well as to some individual rights within the set.
Example: 
Watermarking and tracking obligations apply to a set of one Play right and two Print 
rights. 

2.6	Usage and Business Models
A usage and business model is a commonly understood and practiced way in which Digital 
Items can be accessed, used and priced during their entire life cycle.

They are specified by multiple sets of rights and their associated conditions and obligations. 
Usage business models may not only express rights of Users to consume Digital Item, but also 
their rights to distribute, loan, and sell the Digital Item as well as transfer rights.

2.6.1	Support Multiple Usage/Business Models
Requirement: 
The RDD-REL shall support flexible expression of different usage/business models, 
which may change over time, markets and geography. These business
Note: 
Note: Some usage/business models are envisaged to involve 'super distribution', in which 
Digital Item and rights to interact with it are passed along from one user to another. 
Example: 
From the view point of a person who has possession of Digital Items, usage/business 
models include "sell", "loan", "transfer", "return", "free preview", "super distribution", 
"subscription", "pay per use" or "pay per view", "pay by component", "site licensing", 
"giving" or "gifting"

2.6.2	Unlimited usage (Pay an Upfront Fee)
Requirement: 
The RED-REL shall support specifying a price for unlimited usage, both in terms of 
conditions and obligations, and in terms of a predetermined set of rights such as copy and 
print.
Note: 
This is a pay an upfront flat fee model. 
Example: 
Pay $25.99 for an eBook that the user can copy, print, view, and extract with no further 
conditions. 

2.6.3	Limited usage 
Requirement: 
The RDD-REL shall support the specifying a price for limited usage, both in terms of 
time, and in terms of other rights such as copy and print. 
Note: 
The price can be extended to include other conditions.
Example: 
Pay $5.99 for an eBook that the user can print 5 copies, and view for 1 year.

2.6.4	Preview or Promotional Models
Requirement: 
The RDD-REL shall support  free preview of some portion of Digital Items.
Note: 
Digital Items may still be controlled with IPMP systems (for their integrity) but available 
at no cost to consumers. This model may be used in combination with other 
usage/business models for promotional contents to build incentive based models. 
Example: 
Offer excerpts or one chapter free. Free use for the first hour. 

2.6.5	Tiered Models
Requirement: 
The RDD-REL shall support specifying conditions (such as different pricing levels) based 
on the quantity of a work requested, the length of time to use a work, or the quality of 
different versions of a same work offered.
Example: 
Pay $10 for each copy up to 10 copies, and $8 for each copy over 10 copies. 

Pay a rate of $1 per day for playing a DVD movie for less than 5 days, and a rate of $.75 
per day for more than 5 days. 

Pay $2 for an image of low resolution, and $5 for the same image of high resolution.

2.6.6	Pay Per View or Use
Requirement: 
The RDD-REL shall support specifying a simple fee charged every time that a right is 
exercised.
Note: 
Pay per view/use could be for both online and offline viewing/usage.
Example: 
Each printed copy costs $2. Each time of play a movie costs $2. 

2.6.7	Subscription
Requirement: 
The RDD-REL shall support specifying subscription-based pricing. 
Note: 
An issue about subscription is how to determine whether a user is a subscriber or not, and 
if yes for how long. The determination could be taken place online or offline.  
Example: 
For example, a user may initially select metered usage (described below). After a certain 
amount of time (which may also be specified in the RSL), the user should then have the 
option of changing to a subscription-based pricing.

2.6.8	Territory Restricted 
Requirement: 
The RDD-REL shall support specifying territory information to enable regional pricing, 
and to offer publishers control over where Digital Item can be purchased.
Example: 
Pay $5 for use in the U.S., and $7 elsewhere.

2.6.9	Component Based Model
Requirement: 
The RDD-REL shall support specifying different rights, conditions and obligations to 
individual components of a composite work, as well as to the entire composite work.
Example: 
Charge $.20 for using an image in a Web page, and $1 for the entire page.

2.6.10	User Types Based Model
Requirement: 
The RDD-REL shall support user-based pricing levels for different individual users or for 
different groups of users. 
Example: 
Pay $5 if the user is a member of a club, and $7 otherwise.

2.6.11	Site Licensing 
Requirement: 
The RDD-REL shall support Digital Item access and use under a site license.
Note: 
Site licensing may be combined with other business models such as the tiered model.
Example: 
Free use if under a site license, and $2 otherwise.

2.6.12	Personal Lending 
Requirement: 
The RDD-REL shall support specifyimg transferring, temporarily or permanently, Digital 
Item and the rights, conditions and obligations associated with them from one party to 
another. 
Note: 
Once a work is lent to someone else, the original user does not have access to the work 
until it is returned. Lending may not require that the work actually transfer to the new 
user.
Example: 
One can lend a DVD movie to his/her friends during the period of renting.

2.6.13	Giving 
Requirement: 
The RDD-REL shall support giving Digital Items away to another User.
Note: 
Giving is very similar to personal lending, except that there is no recourse.
Example: 
Paying $10 upfront, one can have the right to give the work away to anyone. 

2.6.14	Institutional Lending 
Requirement: 
The RDD-REL shall support specifying time-based lending and lending of multiple copies 
subject to a pre-defined condition. 
Note: 
Institutional lending enables library and corporate business models.
Example: 
Lend an eBook to a faculty member for up to a semester, and to a student for up to one 
month.
2.6.15	Superdistribution 
Requirement: 
The RDD-REL shall support superdistribution of Digital Items in terms of associating 
same or different sets of rights, conditions, and obligations for the superdistributed Digital 
Items.
Note: 
Original users retain rights granted to them, and new users are required to acquire rights 
granted to them.  
Example: 
Information on where rights are offered can be used to refer new users of a Digital Item to 
acquire rights for themselves. In order to issue different sets of rights, use different 
usage/business models for new users. 

2.6.16	Distributor Copies 
Requirement: 
The RDD-REL shall support specifying a maximum number of copies that a distributor 
can make of a work for further transmission or sale. 
Note: 
This avoids making unnecessary, duplicated copies for distributors.  
Example: 
A distributor can sell up to 40,000 copies of a work within a year.

2.6.17	Personal Copies 
Requirement: 
The RDD-REL shall support specifying how many copies of a work that one can make for 
personal use. 
Example: 
A user is allowed to make 3 copies for his/her family use.

2.6.18	Nested Revenue Model
Requirement: 
The RDD-REL shall support specifying payments for Digital Item usage in terms of 
percentages of pervious transactions. 
Note: 
This is useful when where the recipient of the surcharge has no prior knowledge of the 
details of pricing in previous transactions.
Example: 
Pay to B 2% of how much is paid to A. 


 


 ANNEX A - MPEG-21 Terms (Informative)

Term
Definition or synonymous term(s)
Anchor
An Anchor associates Descriptors with a fragment of a media resource and provides an 
externally identifiable target for links from a location within a media resource.
Container
A potentially hierarchical structure that allows Digital Items to be grouped.
Digital Item
A Digital Item is a structured digital object with a standard representation, 
identification and meta-data within the MPEG-21 framework. This entity is also the 
fundamental unit of distribution and transaction within this framework

End User
 A User taking the role of consumer, i.e. being at the end of a value or delivery chain 
(a human consumer, an agent operating on behalf of a human consumer, etc.). Note: 
"User" refers to all participants in the value or delivery chain. 
IPMP
Intellectual Property Management & Protection
Privacy
Privacy is the ability of a User to control access to that particular User's private 
information
Resource
A resource is an individually identifiable asset such as a video or audio clip, an image, 
or a textual asset. A resource may also potentially be a physical object.
Trust
Is synonymous with predictability, e.g. a trusted device is one which exhibits 
predictable behaviour
User
User of a system. This includes all members of the value chain (e.g., creator, rights 
holders, distributors and consumers of Digital Items)

ANNEX B - The table of responses to the CfR (Informative)


Responding Party
Contact/Author 
Name(s)
Name of Response
MPEG number, or 
name of files in 
m7051.zip
SMPTE DC28.4 Study 
Group on Conditional 
Access for Digital Cinema
Chuck Harrison
SMPTE Digital Cinema Study 
Group DC28.4 on Encryption and 
Conditional Access, Interim Report, 
Version 1.3, October 29, 2000 (see 
SMPTE mail.txt for which 
sections apply to CfR, ed.)
SMPTE DC28.4 
28_4v1_3.pdf
SMPTE mail.txt
IPR Systems
Renato Iannella
Open Rights Language 
Requirements
m6974
The International DOI 
Foundation and EDItEUR
Norman Paskin
Response from the International 
DOI Foundation and EDItEUR to 
MPEG-21 Call for Requirements for 
a Rights Data Dictionary: The 
<indecs>(tm) Framework
The <indecs> metadata framework: 
Principles, model and data > 
dictionary
010222MPEG RDD 
(DOI).do
WP1a-006-2.0 
Metadata framework 
EC version 10 Aug 00 
(DOI).doc

Record Industry 
Association of America 
(RIAA) and the 
International Federation of 
the Phonographic Industry 
(IFPI
Bruce Block 
(RIAA) and Paul 
Jessop (IFPI)
Response to the Call for 
Requirements for a Rights Data 
Dictionary and a Rights Expression 
Language
m6993
Reuters
David Parrott
Notification of Reuters intention to 
respond to CFR
Reuters notification.txt
ContentGuard
Brad Gandee,  
Xin Wang
Requirements for Rights Expression 
Language
m7002
The National Association of 
Theatre Owners (NATO)
John Fithian, 
Michael 
Karagosian
Letter from NATO regarding 
SMPTE Digital Cinema Study 
Group DC28.4 on Encryption and 
Conditional Access, Interim Report, 
Version 1.3 (submission 1 in this 
list, ed.)
NATO letter to SMPTE 
23 Feb 01.pdf
DENTSU
Takahito Iida
Requirements for a rights data 
dictionary and a rights expression 
language: Identification of All 
Users, Flexibility of Permission to 
protect of authors rights and respect 
for their usage rules, Relational 
Management of Rights Expression 
Language and Rights Data
m7036
Artspages International AS
Dagfinn Bach
MPEG-21  -  Input from Artspages 
International AS
Artspages mail.txt
ARTSPAGES MPEG-
21 First Input.doc
OsloDeclaration2001Fi
nalversion.doc 
CISAC (Confédération 
Internationale des Sociétés 
d'Auteurs et Compositeurs) 
and BIEM (Bureau 
International des Sociétés 
Gérant les Droits 
d'enregistrement et de 
Reproduction Mécanique)
Eric Baptiste 
(CISAC) and 
Ronald Mooij 
(BIEM)
Response to the Call for 
Requirements for a Rights Data 
Dictionary and a Rights Expression 
Language
m7047
Nine Tiles
Kate Grant
Requirements for a Rights Data 
Dictionary and a Rights Expression 
Language from the perspective of 
the Surveillance Industry
m7008
Electronics and 
Telecommunications 
Research Institute (ETRI)
Wook Joong Kim, 
Seok Jong Won, 
Jin Soo Choi, Jin 
Woo Hong, Jin 
Woong Kim, 
Chieteuk Ahn
A response to the CfR for a Rights 
Data Dictionary: Requirements for 
Indirect Creation
m7006 (found in 
registry)
Content ID Forum (cIDf)
Hiroshi Fujii 
(NTT), Shigeru 
Ueda (Sharp), 
Toshio Yanagihara 
(Lawyer), 
Hideki Sakamoto 
(NTT), Junichi 
Kishigami (NTT), 
Hiroshi Yasuda 
(Univ. of Tokyo)
Requirements for a rights data 
dictionary and a rights expression 
language: Flexibility in rights 
expression, Identification of rights 
description, and Structure of a rights 
dictionary and expression.
M6979 (found in 
registry)
TV-Anytime Forum
I. Sezan (TVA 
Liaison)
TV-Anytime Rights Management 
and Protection Requirements 
m7007
 


ANNEX C - The table for categorization of the responses (Informative)


Responding Party 
Request 
Extension
RDD  Reqs 
Only
REL Reqs 
Only
RDD & REL 
Reqs
Explicit 
Reqs
Implicit 
Reqs
SMPTE DC28.4 Study 
Group on Conditional 
Access for Digital 
Cinema





Y
IPR Systems (M6974)



Y
Y

The International DOI 
Foundation and 
EDItEUR
Y
Y



Y
RIAA and IFPI (M6993)
Y





Reuters
Y





ContentGuard (M7002)


Y

Y

The National Association 
of Theatre Owners 
(NATO)
Y

Y

Y

DENTSU (M7036)
Y

Y

Y

Artspages International 
AS



Y
Y

CISAC and BIEM 
(M7047)
Y





CIDF (M6979)
Y


Y
Y

TVAnytime (M7007)



Y

Y
ETRI (M7006)



Y
Y

Nine Tiles (M7008)



Y
Y




ANNEX D - Acronyms (Informative)

Abbreviation
Explanation
AES
Advanced Encryption Standard. See http://csrc.nist.gov/encryption/aes/ 
API
Application Program Interface. 
CA
Certificate Authority
CfP
Call for Proposals
CfR
Call for Requirements
DOI
Digital Object Identifier. See http://www.doi.org 
DRM
Digital Rights Management. Used interchangeably with IPMP.
FIPS
Federal Information Processing Standard
INDECS
Interoperability of Data in E-Commerce Systems. See http://www.indecs.org
IP
Intellectual Property
IPMP
Intellectual Property Management and Protection
ISAN
International Standard Audiovisual Number.
ISBN
International Standard Numbering System. 
ISRC
International Standard Recording Code. 
ISO
International Standardization Organization
ISSN
International Standard Serial Number.
MPEG
Moving Picture Experts Group
NIST
National Institute of Standards and Technology
ONIX
Online Information exchange. See http://www.editeur.org/ 
RDF
Resource Description Framework. See http://www.w3.org/RDF/ 
URI
Uniform Resource Identifiers. See http://www.w3.org/Addressing/ 
URL
Uniform Resource Locator. This may be in DNS form, or a pointer within an MPEG-
4 stream name scope
XML
eXtensible Markup Language (XML) is a subset of SGML (ISO standard). 
Commonly viewed as the successor to HTML, it provides a base schema for different 
specialized languages to be developed, typically for web-specific applications.







ANNEX E - Glossary of Terms (Informative)

Please note that these terms were extracted from one of the original CfR submissions and does not represent an 
official MPEG glossary of terms.


Access control:  A mechanism for limiting use of a digital content, resource or service to authorized users.

Authentication: The process of reliably ensuring the identity of participants in a digital communication session. 
Participants can be both people and technology components, for example, software programs. Authentication is an 
important element of establishing trust in the digital world.

Authorization: A process for granting permissions to access or use a digital content, resource or service. 

Business/Usage model: A commonly understood and practiced way that contents can be access, used and priced 
during the entire life cycle of content. It may be specified by multiple sets of rights and their associated conditions 
and obligations. Business and Usage models are not just only expressing rights for individuals to consume content, 
but also for expressing rights for individuals to distribute, loan, and sell the content.

Certificate: See Digital certificate.

Certificate Authority: A trusted third party who issues and manages digital certificates. Certificate authorities may 
also verify that digital certificates belong to their proper owner.

Confidentiality: The property that sensitive information is not disclosed to unauthorized individuals, entities, or 
processes.

Condition: Something that must exist or be fulfilled before a right can be exercised or granted. 

Configuration right: A category of rights that govern the adding and removing of system software from highly 
secure repositories.  

Constraint: See Condition.

Consumer: Ay person or entity who purchases and/or accesses digital content. Also see End user.

Content: See Digital content. 

Content life cycle: The entire time period of content existence. It includes all phases across the content distribution 
and consumption value chain, like content creation, manipulation, search, access, storage, delivery, use and 
disposal. 

Content Management: The mechanisms, processes, protocols and systems that enable creation, manipulation, 
search, access, storage, delivery, use and disposal of content across the content distribution and consumption value 
chain.

Content User: A person or entity that wants to access and use contents. It can be any party in the content life cycle, 
not just the end user. See End user. 

Copyright: The exclusive legal right granted to an author, composer, playwright, publisher, or distributor to 
exclusive publication, production, sale, or distribution of a literary, musical, dramatic, or artistic work. 

Cryptography: A branch of mathematics that deals with approaches for turning clear text into encrypted text and 
back. See Encryption, Digital signature.

Derivative work right:  A category of rights that govern the reuse of a digital work, in whole or part, to create a new 
composite work. 

Digital certificate: A set of data that unambiguously identifies an entity, contains the entity's public key, is digitally 
signed by a trusted party, binding the public key to the entity.

Digital Object: A sequence of bits that incorporates unique numbering, metadata, and digital content. A digital 
object is the lowest level transactional unit in a digital publishing environment. A content can be described as a 
collection of one or more digital objects. Digital objects can be arranged in a hierarchy, where some digital objects 
are the "children" of "parent" objects. Child objects may inherit some of the attribute of their parent object.

Digital Right: See Right.

Digital Rights Management: The technological, legal and/or social mechanisms, processes and regulations used to 
protect the copyrights in digital content.

Digital signature: A non-forgeable transformation of data that allows proof of the source (with non-repudiation) 
and verification of the integrity of that data. Digital signatures are usually created using a public-key algorithm.

Digital Watermark: See Watermark.

Distributor: Any person or entity who provides digital contents directly to consumers or another distributor.

Digital content: The primary information or data intended to be conveyed by a digital object. It is valuable for 
distribution and consumption. Digital content excludes metadata that describes various attributes of the digital 
object. See Metadata.

Encryption: The process of scrambling the unprotected information (sometimes called clear text or plain text) to 
produce protected information, or cipher text. 

End user: Any person or entity that consumes a digital content. 

File management right:  A category of rights that govern access to directory and file information when two 
repositories are connected. File management rights control how directory information of one repository can be 
accessed from another. They also control the making and restoring of backup copies. 

Granted right: A right that has been transferred from its owner or distributor to someone else.  

Identification: A piece of data or process that enables recognition of a digital representation of a person or entity.

Integrity: The property that sensitive data has not been modified or deleted in an unauthorized and undetected 
manner.

Intellectual property: Something owned or possessed that is a product of the human mind (for example, works 
protected under copyright law and inventions protected by patent law).

Intellectual property management and protection: MPEG term of Digital rights 
management.

Intent: A user's desire to access or use a digital content. 

Interoperability: The condition achieved when two or more technical systems can exchange information directly in 
a way that is satisfactory for the users of the systems.
In IPMP systems, this typically involves content file formats and IPMP components, but may include other 
functions such as financial clearing. 

Key: A string of bits, characters, or words used, along with a cryptographic algorithm to scramble or unscramble a 
message. 

Metadata: Metadata is data about data. Metadata can describe such elements as the creator (e.g., author bio) and the 
content (e.g., number of pages, chapter titles). 

Object: An entity that encapsulates content, properties, attributes and functions to perform a given task or define a 
specific process. 

Obligation: A course of action that a person or entity is bound to perform when exercising a granted digital 
right. Examples include usage tracking and content watermarking.  

Offered right: A right that is made available by its owner or distributor for granting or transferring to someone else.  

Originator: any person or entity who originates digital content either through personal creation or by hiring another 
person to originate such content. For convenience, in this document, originators are also referred to as authors.

Publisher: Any person or entity who accepts contents from authors, aids in the editing process, creates and 
distributes metadata and produces finished, publication-ready contents.

Render right: A category of rights that govern the creation of representations of a digital work outside of the control 
of trusted systems.

Repository: A system that can hold digital contents. Examples of a repository include personal systems, on-line 
storefront systems, library systems, and archive systems.

Right: A privilege that someone may claim legally or that is morally due to them, which makes them entitled to 
make copies of, distribute, or perform all or part of a published or recorded work for a certain extended period of 
time. See Copyright, Granted right, Offered right, Usage right. 

Rights document: A digital file form of a rights expression. See Rights expression. 

Rights expression: A digital string, file or document written in a rights expression language to describe rights, 
conditions and obligations associated with a digital content or a component of a digital content. 

Rights expression language (REL): Within a IPMP system, the statements and grammar that can be used to describe 
rights, conditions and obligations associated with a digital content or a component of a digital content.

Rights holder: Any person or entity who owns or has been licensed the intellectual property rights for the digital 
content. Examples include authors, consumers, creators, rights management service providers, media distributors, 
performers, producers, publishers, retailers, telecom companies and trusted third parties. 

Rights specification: See Rights expression.

Rights specification language: See Rights expression language.

Service provider: Any person or entity who provides a service that enables or provides one or more activities in the 
digital content publication, distribution, management and consumption.

Superdistribution: Publishing usage/business model in which multiple parties of the content value chain are able to 
distribute content with rights and compensation controlled by prior agreement and enforced by IPMP systems. In a 
typical example, consumers of digital content can pass that content on to associates who must then pay the rights 
holder(s) to acquire access to the content.

Technology provider: Any person or entity who provides either software or hardware that enables the secure 
distribution of digital content and protects the intellectual property rights of the rights holder. Examples include 
hardware vendors and software vendors.

Transport right:  A category of rights that govern the creation and movement of persistent copies of a work under 
the control of trusted repositories. 

Trust Infrastructure: The technology and processes used to make system components trustworthy. Trusted system 
components are known with confidence to perform a range of functions in a specified way. For example, a trusted 
reading device may only allow an ebook to be printed if the ebook's rights specification allows printing.

Trusted third party: An intermediary or additional party to a transaction who has been granted authority by one or 
more of the other parties to the transaction to perform certain functions such as certification, registration, 
encryption, security, credit card clearance, rights clearance, transaction reporting, etc.

Trusted system: A system whose behaviors can be expected. In IPMP, trusted systems XE "trusted:system"  (or 
repositories) are systems that can hold digital contents and which can be trusted to honor the rights, conditions, and 
fees specified for digital contents. In document commerce, trusted systems are for authoring, playing, and selling 
digital works. See Repository.

Usage model: See Business Model

Usage right: A right that someone is entitled to access, duplicate, modify, distribute, consume and dispose all or 
part of a content. See Copyright, Granted right, Offered right, Right.

User: An individual or a process (subject), operating on behalf of the individual, accessing a cryptographic module 
in order to obtain cryptographic services.

Work: A digital property or content. See Content. 

Watermark: A cryptographic technique for protecting digital content by placing a pattern of bits in the content in 
way that is invisible to the consumer, but can be read by special programs. A wide variety of information, including 
owner's identity and consumer's identity, can be contained in the digital watermark. A digital watermark doesn't 
encrypt the digital content, but it does make it possible for the source of the content to be determined.

XML: A standard for markup of data and text. XML (eXtensible Markup Language) provides a simpler, yet more 
powerful capability than its predecessor, HTML (HyperText Markup Language).

  www.indecs.org
  www.ifla.org
  http://dublincore.org/
48

43